HDFS-15911 : Provide blocks moved count in Balancer iteration result

branch-3.1 backport PR of #2794

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
13m  8s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ branch-3.1 Compile Tests _

-1 :x:
mvninstall
4m 39s
root in branch-3.1 failed.

-1 :x:
compile
0m 29s
hadoop-hdfs in branch-3.1 failed.

-0 :warning:
checkstyle
0m 18s
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 13s
hadoop-hdfs in branch-3.1 failed.

-1 :x:
shadedclient
1m 20s
branch has errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 22s
hadoop-hdfs in branch-3.1 failed.

+0 :ok:
spotbugs
1m 56s
Used deprecated FindBugs config; considering switching to SpotBugs.

-1 :x:
findbugs
0m 13s
hadoop-hdfs in branch-3.1 failed.

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 12s
hadoop-hdfs in the patch failed.

-1 :x:
compile
0m 12s
hadoop-hdfs in the patch failed.

-1 :x:
javac
0m 12s
hadoop-hdfs in the patch failed.

-0 :warning:
checkstyle
0m 10s
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 12s
hadoop-hdfs in the patch failed.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

-1 :x:
shadedclient
0m 50s
patch has errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 12s
hadoop-hdfs in the patch failed.

-1 :x:
findbugs
0m 13s
hadoop-hdfs in the patch failed.

_ Other Tests _

-1 :x:
unit
0m 13s
hadoop-hdfs in the patch failed.

+1 :green_heart:
asflicense
0m 31s
The patch does not generate ASF License warnings.

25m 56s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2799

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux bbbfed1f0615 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.1 / c9c471e

Default Java
Oracle Corporation-9-internal+0-2016-04-14-195246.buildd.src

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/branch-mvninstall-root.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/branch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/buildtool-branch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/branch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

javac
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/buildtool-patch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/patch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/testReport/

Max. process+thread count
150 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/1/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
18m 29s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ branch-3.1 Compile Tests _

-1 :x:
mvninstall
4m 41s
root in branch-3.1 failed.

-1 :x:
compile
0m 29s
hadoop-hdfs in branch-3.1 failed.

-0 :warning:
checkstyle
0m 17s
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 12s
hadoop-hdfs in branch-3.1 failed.

-1 :x:
shadedclient
1m 17s
branch has errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 21s
hadoop-hdfs in branch-3.1 failed.

+0 :ok:
spotbugs
1m 52s
Used deprecated FindBugs config; considering switching to SpotBugs.

-1 :x:
findbugs
0m 13s
hadoop-hdfs in branch-3.1 failed.

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 12s
hadoop-hdfs in the patch failed.

-1 :x:
compile
0m 12s
hadoop-hdfs in the patch failed.

-1 :x:
javac
0m 12s
hadoop-hdfs in the patch failed.

-0 :warning:
checkstyle
0m 10s
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 12s
hadoop-hdfs in the patch failed.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

-1 :x:
shadedclient
0m 49s
patch has errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 13s
hadoop-hdfs in the patch failed.

-1 :x:
findbugs
0m 13s
hadoop-hdfs in the patch failed.

_ Other Tests _

-1 :x:
unit
0m 12s
hadoop-hdfs in the patch failed.

+1 :green_heart:
asflicense
0m 29s
The patch does not generate ASF License warnings.

31m 15s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2799

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 33a9860df7b5 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.1 / c9c471e

Default Java
Oracle Corporation-9-internal+0-2016-04-14-195246.buildd.src

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/branch-mvninstall-root.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/branch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/buildtool-branch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/branch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

javac
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/buildtool-patch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/patch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/testReport/

Max. process+thread count
150 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/2/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
22m  8s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ branch-3.1 Compile Tests _

-1 :x:
mvninstall
4m 44s
root in branch-3.1 failed.

-1 :x:
compile
0m 29s
hadoop-hdfs in branch-3.1 failed.

-0 :warning:
checkstyle
0m 14s
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 10s
hadoop-hdfs in branch-3.1 failed.

-1 :x:
shadedclient
1m 15s
branch has errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 18s
hadoop-hdfs in branch-3.1 failed.

+0 :ok:
spotbugs
1m 45s
Used deprecated FindBugs config; considering switching to SpotBugs.

-1 :x:
findbugs
0m 10s
hadoop-hdfs in branch-3.1 failed.

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 11s
hadoop-hdfs in the patch failed.

-1 :x:
compile
0m 10s
hadoop-hdfs in the patch failed.

-1 :x:
javac
0m 10s
hadoop-hdfs in the patch failed.

-0 :warning:
checkstyle
0m  8s
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 10s
hadoop-hdfs in the patch failed.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

-1 :x:
shadedclient
0m 55s
patch has errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 12s
hadoop-hdfs in the patch failed.

-1 :x:
findbugs
0m 10s
hadoop-hdfs in the patch failed.

_ Other Tests _

-1 :x:
unit
0m 12s
hadoop-hdfs in the patch failed.

+1 :green_heart:
asflicense
0m 30s
The patch does not generate ASF License warnings.

34m 50s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2799

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 754b90d93b18 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.1 / c9c471e

Default Java
Oracle Corporation-9-internal+0-2016-04-14-195246.buildd.src

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/branch-mvninstall-root.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/branch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/buildtool-branch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/branch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

javac
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/buildtool-patch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/patch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/testReport/

Max. process+thread count
126 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/3/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Build failure doesn't seem related to PR changes for branch-3.1

Jenkins fails with unrelated problems. Maybe you can rebase and trigger the Jenkins again. Thanks,

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 43s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ branch-3.1 Compile Tests _

-1 :x:
mvninstall
4m 39s
root in branch-3.1 failed.

-1 :x:
compile
0m 31s
hadoop-hdfs in branch-3.1 failed.

-0 :warning:
checkstyle
0m 18s
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 13s
hadoop-hdfs in branch-3.1 failed.

-1 :x:
shadedclient
1m 22s
branch has errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 21s
hadoop-hdfs in branch-3.1 failed.

+0 :ok:
spotbugs
1m 58s
Used deprecated FindBugs config; considering switching to SpotBugs.

-1 :x:
findbugs
0m 14s
hadoop-hdfs in branch-3.1 failed.

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 12s
hadoop-hdfs in the patch failed.

-1 :x:
compile
0m 13s
hadoop-hdfs in the patch failed.

-1 :x:
javac
0m 13s
hadoop-hdfs in the patch failed.

-0 :warning:
checkstyle
0m 11s
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 12s
hadoop-hdfs in the patch failed.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

-1 :x:
shadedclient
0m 49s
patch has errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 13s
hadoop-hdfs in the patch failed.

-1 :x:
findbugs
0m 14s
hadoop-hdfs in the patch failed.

_ Other Tests _

-1 :x:
unit
0m 14s
hadoop-hdfs in the patch failed.

+1 :green_heart:
asflicense
0m 30s
The patch does not generate ASF License warnings.

13m 21s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2799

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 9bbc2caea67b 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.1 / 34e507c

Default Java
Oracle Corporation-9-internal+0-2016-04-14-195246.buildd.src

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/branch-mvninstall-root.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/branch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/buildtool-branch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/branch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

javac
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs.txt

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/buildtool-patch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/patch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/testReport/

Max. process+thread count
150 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/4/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
11m 18s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ branch-3.1 Compile Tests _

+1 :green_heart:
mvninstall
27m 53s
branch-3.1 passed

+1 :green_heart:
compile
1m  7s
branch-3.1 passed

+1 :green_heart:
checkstyle
0m 50s
branch-3.1 passed

+1 :green_heart:
mvnsite
1m 11s
branch-3.1 passed

+1 :green_heart:
shadedclient
14m 21s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
1m  0s
branch-3.1 passed

+0 :ok:
spotbugs
2m 50s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
2m 48s
branch-3.1 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 10s
the patch passed

+1 :green_heart:
compile
0m 59s
the patch passed

+1 :green_heart:
javac
0m 59s
the patch passed

+1 :green_heart:
checkstyle
0m 49s
hadoop-hdfs-project/hadoop-hdfs: The patch generated 0 new + 229 unchanged - 4 fixed = 229 total (was 233)

+1 :green_heart:
mvnsite
1m  6s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
13m  9s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 52s
the patch passed

+1 :green_heart:
findbugs
2m 51s
the patch passed

_ Other Tests _

-1 :x:
unit
169m 46s
hadoop-hdfs in the patch failed.

+1 :green_heart:
asflicense
0m 42s
The patch does not generate ASF License warnings.

253m  2s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.blockmanagement.TestUnderReplicatedBlocks

hadoop.fs.TestHdfsNativeCodeLoader

hadoop.hdfs.server.namenode.TestEditLogRace

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2799

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 40fa88644a2b 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.1 / 332c2a6

Default Java
Private Build-1.8.0_282-8u282-b08-0ubuntu1~16.04-b08

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/5/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/5/testReport/

Max. process+thread count
2919 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2799/5/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


Include other runner on coop runs

No idea if the api even allows for this. Would be neat to see.

Yes and no. Technically autosubmit puts the other runner's username as the run comment, which I can read, but if a run was submitted manually, or done before autosubmit, then the comment could be different or just have no comment at all.

I'll keep this up for now if I have an idea on how to implement this well but don't think there's a good way to filter only runs that have a username-only comment.


Adopt a CODE_OF_CONDUCT across dotcom

james-dow created the following on Apr 25:
As a contributor I need a code of conduct to know how to engage within the dotcom community appropriately and report a problem if needed
A code of conduct defines standards for how to engage in a community. It signals an inclusive environment that respects all contributions. It also outlines procedures for addressing problems between members of your project's community.
Resources for reference

GitHub Help: Adding a code of conduct to your project
Opensource Guide: Code of conduct

Acceptance criteria

[x] CODE_OF_CONDUCT.md file exists for v18 within .github folder.
[x] CODE_OF_CONDUCT.md file exists for v18-starter-kit within .github folder.
[x] CODE_OF_CONDUCT.md file exists for v19a within .github folder.
[x] CODE_OF_CONDUCT.md file exists for patterns within .github folder.
[x] CODE_OF_CONDUCT.md file exists for digital-design within .github folder.
[x] CODE_OF_CONDUCT.md file exists for carbon-integration-poc within .github folder.
[x] CODE_OF_CONDUCT.md file exists for northstar-external-website within .github folder.
[x] CODE_OF_CONDUCT.md file exists for IBM/carbon-addons-dotcom within .github folder.

Original issue: https://github.ibm.com/webstandards/digital-design/issues/750

On Apr 25, james-dow commented:
Carbon gave us a CODE_OF_CONDUCT.md file when we created IBM/carbon-addons-dotcom. It might be best to use that as a starting point, and iterate from there as needed.


numtab keys are not grabbed

My keyboard layout is: it_IT.
In insert mode numeric all keys from numpad are ignored.
In normal mode too:
for example this vimrc configuration is affected:
nmap  <Leader><k1>    <Leader>1
[<Leader>1] is working
[<Leader><k1>] not

Oops, didn't realize the keypad keys need to be prefixed with a k. Does #96 fix?

Problem fixed! I applied your patch from the numpad branch. Now the numpad works great.


Create TOSCA Compliance within Cloud Foundry

My new proposal for TOSCA Compliance.

I'm not sure but it looks like the other proposals are in the Markdown format. Converting this PR to markdown would increase the readability.

Maybe you could add some links to additional information on TOSCA, for people who are new to it and would like to know more (like myself :smile:).

Hi Ruben, following are the few links for TOSCA. Thanks.
http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html
http://www.slideshare.net/YaronParasol/tosca-explained

Hey @deepak-vij, thanks for getting this PR going.
Before pulling in this PR, could you add a bit more details to it to clarify how you see BOSH concepts (stemcells, releases, CPIs, deployments) being described with TOSCA with some markup examples.

@deepak-vij thanks for the links

Hi Dmitriy, following is a bit more background on how BOSH constructs such as “Stemcell”, “Release”, “Deployment”, & “CPI” may map into corresponding TOSCA concepts. This is very high level preliminary analysis in order to provide you a brief overview of what all it entails as far as TOSCA mapping with BOSH orchestration environment. As a follow work, we may have to do in-depth analysis for exactly determining the level-of-effort for this effort.
The way the whole process works is by defining the cloud application orchestration plan – also called Blueprint. The main part of the plan is written in a declarative YAML DSL (Domain Specific Language). This DSL follows the concepts of OASIS TOSCA specifications. Blueprint consists of “Topologies”. A Topology is a graph of application components and their relationships described in YAML. One can think about it as application components being the vertices of the graph and the relationships being the edges of the graph. Each component is described by a YAML object denoted as a YAML list entry. Components can be of 3 levels:

Infrastructure - Components provided by the IaaS layer (e.g. VM, virtual network, virtual load balancer or storage volume) or by non-cloud physical or virtualized layer (e.g. Host and storage volume)
Platform/Middleware - Components that serve as the application containers (such as web-servers, application servers, message servers and database servers)
Application modules - The different application artifacts that needs to be deployed and configured on top of the middleware (such as application binaries, application configuration files, database schemas etc.)

TOSCA Overview
Firstly, here is a high level overview of TOSCA (Topology and Orchestration Specification for Cloud Applications). TOSCA is an open standard from OASIS that aims to enhance portability and management of cloud applications and services. In practical terms, a TOSCA service template (or application blueprint) is a document written in YAML that adheres to the syntax defined by the TOSCA specification. The template is submitted to a TOSCA-compliant orchestration engine (for example Cloudify TOSCA Orchestration Engine from GigaSpaces) and, as a result, the application gets deployed and configured on the cloud provider of choice.

TOSCA uses the following concepts for the Topology parts:

Components are called nodes
Components relationships are called relationships

Topologies are defined using the blueprint YAML file. Below is a sample TOSCA blueprint from VMWare TOSCA-vCloud-plugin that contains a virtual machine that is connected to a network and has a public IP address. The blueprint also defines that a web server (ngnix) should be installed on the virtual machine and that ports 22 and 80 should be accessible from outside.
This simple blueprint illustrates two important concepts in TOSCA orchestration:

Infrastructure Provisioning: a VM is instantiated on a virtual datacenter from a template and network resources are configured according to the template
Software configuration: in this case, a web server gets installed and started on the VM created previously

Baseline blueprint information is customized/configured using the input values passed inside an input YAML file (see below).
TOSCA workflows orchestrate the different management operations offered by the nodes to fulfill their task. For example, Cloudify TOSCA implementation comes with two built-in workflows called “install” and “uninstall”.
BOSH & TOSCA Mapping

Release: This information will be defined using blueprint YAML definitions by leveraging various nodes and relationships as prescribed by TOSCA.
Deployment: Deployment in BOSH consists of all the actual parameter values (deployment knobs) at the time of actual deployment. As described earlier that baseline TOSCA blueprint information is customized/configured using the input values passed inside an input YAML file.
Stemcell: As we all know that a stemcell is a VM template containing an OS image such as standard Ubuntu distribution etc. Additionally, a BOSH agent is also embedded in the template so that BOSH can take control of VMs cloned from the stemcell. TOSCA topology constructs such as nodes and relationships can used to define the whole stemcell definition process.
CPI: BOSH Cloud-Provider-Interface is essentially IaaS specific interface for deploying CloudFoundry application environment within the native IaaS infrastructure. In the TOSCA, each IaaS specific CPI would be implemented as a plugin module (such as CF-OpenStack-plugin, CF-AWS-plugin, CF-Baremetal-plugin etc.).

vCloud-blueprint.yaml
node_templates:
example_server:
    type: cloudify.vcloud.nodes.Server
    properties:
        server:
            name: { get_input: server_name }
            catalog: { get_input: catalog }
            template: { get_input: template }
            hardware:
                cpu: 3
                memory: 2048
            guest_customization:
                computer_name: { get_input: server_name }
                public_keys:
                    - { get_property: [ssh_keypair, public_key] }
        install_agent: false
        management_network: { get_input: network_name }
        vcloud_config: { get_property: [vcloud_configuration, vcloud_config] }
    relationships:
        - target: example_port
          type: cloudify.vcloud.server_connected_to_port
        - target: example_public_ip
          type: cloudify.vcloud.server_connected_to_public_nat

example_port:
    type: cloudify.vcloud.nodes.Port
    properties:
        port:
            network: { get_input: network_name }
            ip_allocation_mode: pool
            primary_interface: true

example_public_ip:
    type: cloudify.vcloud.nodes.PublicNAT
    properties:
        nat:
            edge_gateway: { get_input: gateway_name }
            public_ip: { get_input: public_ip }
        rules:
            - type: SNAT
            - type: DNAT
              protocol: tcp
              original_port: 22
              translated_port: 22
            - type: DNAT
              protocol: tcp
              original_port: 80
              translated_port: 80

nginx_service:
    type: cloudify.nodes.ApplicationServer
    interfaces:
        cloudify.interfaces.lifecycle:
            start:
                implementation: fabric.fabric_plugin.tasks.run_commands
                inputs:
                  commands:
                    - sudo apt-get update
                    - sudo apt-get install -y nginx
                    - sudo service nginx start
                  fabric_env:
                    host_string: { get_input: public_ip }
                    host: { get_input: public_ip }
                    user: { get_property: [ssh_keypair, public_key, user] }
                    key_filename: { get_property: [ssh_keypair, private_key_path] }
                    disable_known_hosts: True
    relationships:
      - type: cloudify.relationships.contained_in
        target: example_server

input.yaml
vcloud_username<EMAIL_ADDRESS>vcloud_password: 'mysecretpassord'
vcloud_instance: d7a623de-1183-46a9-9b02-9043ca68f881
vcloud_vdc: VDC1
vcloud_url: iam.vchs.vmware.com
vcloud_api_version: '5.7'
vcloud_service_type: ondemand
catalog: 'Public Catalog'
template: 'Ubuntu Server 12.04 LTS (amd64 20150127)'
network_name: default-routed-network
gateway_name: gateway
server_name: hellow
public_ip: <IP_ADDRESS>
ssh_user: ubuntu
ssh_private_key_path: ~/.ssh/id_rsa_manager
ssh_public_key: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFlYX8JkGVKtCUmSi4NStzT+qCqRuFaqP6gzxly7atmfGTXGymOwf56mP9j1vM4a5OLSwTS/xQb9RrHPWZmohqApvaIyM9MQTF1EkoPtb39/tLDyWiAS/czXMGx2VWCqRAfZhdoUn1pd14hyfCUDqDv0Guo3Z/VF5dqHVSB0dHgjNeAYCsWXQhtm+GBxBUxohGaPNzO6wQZvhOnJT2KaVDDlZa3SsK1s+Lx0YDW3s2AkB759dRi71m/kFQBBcXSo2lqg6hRDCgbO6xtVcw/fi3IGsOVTXeZW2dwDq3B10AZZcrsQJAGrIXtVDw2LPnf0hISQkVV43ZNE4Aa5OEPQ5T manager'

going to close this one for now. dont see a lot of interest from other on this topic.


Change link for Requests

Description
https://github.com/terasolunaorg/guideline will be private.
Possible Solutions
Top page.
Change https://github.com/terasolunaorg/terasolunaorg.github.com/issues from https://github.com/terasolunaorg/guideline/issues.
Do #63 earlier than this issue!!
Affects Version/s

all version (top page)

Fix Version/s

[x] ja (master)
[x] en (master)

Final Solution
(To be written later by project member)
Issue Links

#63

@hirakuriy Thanks for your work.


update dependencies so that make init will work; exclude ropeproject …

…folder in gitignore
Had to add these changes to get make init to work, it complained about dependency versions being wrong when I ran that process.

Coverage remained the same at 93.477% when pulling a1a491d7e7bde24ead87d8b6920602308e7d9f21 on chrisevett:master into f052757259d5dec48cdfdaa34a6a7a20f22a186e on spulec:master.

Coverage remained the same at 93.477% when pulling a1a491d7e7bde24ead87d8b6920602308e7d9f21 on chrisevett:master into f052757259d5dec48cdfdaa34a6a7a20f22a186e on spulec:master.

Coverage remained the same at 93.477% when pulling a1a491d7e7bde24ead87d8b6920602308e7d9f21 on chrisevett:master into f052757259d5dec48cdfdaa34a6a7a20f22a186e on spulec:master.


C++ grpcio 1.38.x - Double free crash in grpc_byte_buffer_destroy

What version of gRPC and what language are you using?
grpc 1.38, C++
What operating system (Linux, Windows,...) and version?
Linux 5.4.17-2136.3<IP_ADDRESS>.el7uek.x86_64 #2 SMP Tue Feb 8 11:14:26 PST 2022 x86_64 x86_64 x86_64 GNU/Linux
What runtime / compiler are you using (e.g. python version or version of gcc)
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44.0.3)
What did you do?
Setup:
I have a setup of grpc client and server where the client is a "go" client and the server is a C++ Async Server.
A gnmi client and server based application is running on top of the grpc infra to communicate with each other.
Steps:

Continuously stream a high number of messages (gnmi response packets) in short time over the grpc completion queue using the following Write API:
ServerAsyncReaderWriter.Write(T message,  Tag) // Tag is an object inserted in completion queue.

While the streaming is ongoing and client is receiving successfully, disconnect the client in the middle of these streaming message reception.

The grpc crash in grpc_byte_buffer_destroy is observed.  This crash does not happen when client is disconnected at the time of quiet period (no messaging between client and server)

I am able to reproduce this consistently using the above steps.

What did you expect to see?
I expected a clean exit of grpc connection with the client without any crash.
What did you see instead?
I am seeing a double free related crash.
#0  __GI_raise (sig=sig@entry=6) at /usr/src/debug/glibc/2.31+gitAUTOINC+f84949f1c4-r0/git/sysdeps/unix/sysv/linux/raise.c:50
#1  0x0000007f7ff25dd4 in __GI_abort () at /usr/src/debug/glibc/2.31+gitAUTOINC+f84949f1c4-r0/git/stdlib/abort.c:79
#2  0x0000007f7ff702b4 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f8002b3b8 "%s\n")
at /usr/src/debug/glibc/2.31+gitAUTOINC+f84949f1c4-r0/git/sysdeps/posix/libc_fatal.c:155
#3  0x0000007f7ff7751c in malloc_printerr (str=str@entry=0x7f80026720 "free(): double free detected in tcache 2")
at /usr/src/debug/glibc/2.31+gitAUTOINC+f84949f1c4-r0/git/malloc/malloc.c:5347
#4  0x0000007f7ff7908c in _int_free (av=0x7f8004ba28 <main_arena>, p=0xe10b350, have_lock=0)
at /usr/src/debug/glibc/2.31+gitAUTOINC+f84949f1c4-r0/git/malloc/malloc.c:4201
#5  0x0000007f7f1736b4 in grpc_byte_buffer_destroy (bb=0xe10b360) at /usr/src/debug/grpc/1.42.0-r0/git/src/core/lib/surface/byte_buffer.cc:83
#6  0x0000007f80a53d00 in grpc::ByteBuffer::Clear (this=0x7f6001d930) at /usr/include/grpcpp/impl/codegen/byte_buffer.h:123
#7  grpc::internal::CallOpSendMessage::FinishOp (status=0x7f76ffc237, this=0x7f6001d920) at /usr/include/grpcpp/impl/codegen/call_op_set.h:328
#8  grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal::CallOpSendMessage, grpc::internal::CallOpServerSendStatus, grpc::internal::CallNoOp<4>, grpc::internal::CallNoOp<5>, grpc::internal::CallNoOp<6> >::FinalizeResult (this=0x7f6001d8f0, tag=0x7f76ffc238,
status=0x7f76ffc237) at /usr/include/grpcpp/impl/codegen/call_op_set.h:920
#9  0x0000007f7f2e85c4 in grpc::CompletionQueue::AsyncNextInternal (this=this@entry=0x7f6000fbf0, tag=tag@entry=0x7f76ffc238,
ok=ok@entry=0x7f76ffc237, deadline=...) at /usr/src/debug/grpc/1.42.0-r0/git/src/cpp/common/completion_queue_cc.cc:158
#10 0x0000007f80a5ed58 in grpc::CompletionQueue::Next (ok=0x7f76ffc237, tag=0x7f76ffc238, this=0x7f6000fbf0)
at /usr/include/grpcpp/impl/codegen/completion_queue.h:178
Traces beyond frame 10 containes proprietary implementation details. Let me know if you want more info.
Anything else we should know about your project/environment?
When a client is disconnected, the completion queue ->next returns a false status, like below:
m_cq->Next(&tag, &ok);
The "ok" contains false, so we go ahead and cancel the tag:
static_cast<ICompletionManager*>(tag)->cancel();
Can this cancelling from our end cause this crash? Are we supposed to do this cleanup? Anything else we should have done?
Please advise ...

Hello @yashykt did you get a chance to look into this issue? If you are not the right person to work on this issue, please un-assign yourself, so that it comes to notice to the forum. This is a very critical issue and impacting our solution deployment.
Thanks

@nicolasnoble @yashykt Can you please respond? I filed this issue around 2 weeks before.

Some more data to ponder in the backtrace ...
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at /usr/src/debug/glibc/2.30-r0/git/sysdeps/unix/sysv/linux/raise.c:50
#1  0x0000003b2a825548 in __GI_abort () at /usr/src/debug/glibc/2.30-r0/git/stdlib/abort.c:79
#2  0x0000003b2a87c618 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x3b2a983c52 "%s\n") at /usr/src/debug/glibc/2.30-r0/git/sysdeps/posix/libc_fatal.c:181
#3  0x0000003b2a88379a in malloc_printerr (str=str@entry=0x3b2a985e20 "free(): double free detected in tcache 2") at /usr/src/debug/glibc/2.30-r0/git/malloc/malloc.c:5332
#4  0x0000003b2a88555d in _int_free (av=0x7fcbe0000020, p=0x7fcbe00302d0, have_lock=0) at /usr/src/debug/glibc/2.30-r0/git/malloc/malloc.c:4201
#5  0x00007fcbff0274da in grpc_byte_buffer_destroy () at /usr/src/debug/grpc/1.24.1-r0/git/src/core/lib/surface/byte_buffer.cc:83
#6  0x00007fcc002240e8 in grpc::ByteBuffer::Clear (this=0x7fcbe00534f8) at /usr/include/grpcpp/impl/codegen/byte_buffer.h:135
#7  grpc::internal::CallOpSendMessage::SetFinishInterceptionHookPoint (interceptor_methods=0x7fcbe00535f0, this=0x7fcbe00534e8) at /usr/include/grpcpp/impl/codegen/call_op_set.h:362
#8  grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal::CallOpSendMessage, grpc::internal::CallOpServerSendStatus, grpc::internal::CallNoOp<4>, grpc::internal::CallNoOp<5>, grpc::internal::CallNoOp<6> >::RunInterceptorsPostRecv (this=0x7fcbe00534b8) at /usr/include/grpcpp/impl/codegen/call_op_set.h:978
#9  grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal::CallOpSendMessage, grpc::internal::CallOpServerSendStatus, grpc::internal::CallNoOp<4>, grpc::internal::CallNoOp<5>, grpc::internal::CallNoOp<6> >::FinalizeResult (this=0x7fcbe00534b8, tag=0x7fcbef7bc818, status=0x7fcbef7bc817) at /usr/include/grpcpp/impl/codegen/call_op_set.h:896
#10 0x00007fcbff1fc343 in grpc_impl::CompletionQueue::AsyncNextInternal (this=this@entry=0x7fcbe000bd60, tag=tag@entry=0x7fcbef7bc818, ok=ok@entry=0x7fcbef7bc817, deadline=...)
at /usr/src/debug/grpc/1.24.1-r0/git/src/cpp/common/completion_queue_cc.cc:59
#11 0x00007fcc0022cd63 in grpc_impl::CompletionQueue::Next (ok=0x7fcbef7bc817, tag=0x7fcbef7bc818, this=0x7fcbe000bd60) at /usr/include/grpcpp/impl/codegen/completion_queue_impl.h:177
(gdb) frame 6
#6  0x00007fcc002240e8 in grpc::ByteBuffer::Clear (this=0x7fcbe00534f8) at /usr/include/grpcpp/impl/codegen/byte_buffer.h:135
135	in /usr/include/grpcpp/impl/codegen/byte_buffer.h
(gdb) p * this->buffer_
$3 = {
reserved = 0x7fcbe004d660,
type = (unknown:<PHONE_NUMBER>),
data = {
reserved = {
reserved = {0x7fcb00000000, 0x7fcbe0030320, 0x7fcbe0030320, 0x0, 0x8, 0x0, 0x7fcbe0024970, 0x165}
},
raw = {
compression = GRPC_COMPRESS_NONE,
slice_buffer = {
base_slices = 0x7fcbe0030320,
slices = 0x7fcbe0030320,
count = 0,
capacity = 8,
length = 0,
inlined = {{
refcount = 0x7fcbe0024970,
data = {
refcounted = {
length = 357,
bytes = 0x7fcbe00249a8 "\n\342\002\b\300\337\357\224\351\331\367\345\026\022>\022\005Ciena\032\035\n\033ciena-sys-tmet:system-state\032\026\n\024logical-core-percent"\033\n\021\022\005Ciena\032\b\n\006cpu-id\032\006\n\004"13""\034\n\023\022\005Ciena\032\n\n\bcpu-idle\032\005\065\232%\277B"!\n\030\022\005Ciena\032\017\n\rcpu-interrupt\032\005\065"
},
inlined = {
length = 101 'e',
bytes = "\001\000\000\000\000\000\000\250I\002\340\313\177\000\000\330\b\000\340\313\177\000"
}
}
}, {
refcount = 0x77206465636e7973,
data = {
refcounted = {
length =<PHONE_NUMBER>15808,
bytes = 0x8 <error: Cannot access memory at address 0x8>
},
inlined = {
length = 224 '\340',
bytes = "\376\001\340\313\177\000\000\b\000\000\000\000\000\000\000X\377\001\340\313\177\000"
}
}
}, {
refcount = 0x7fcbe00245a8,
data = {
---Type  to continue, or q  to quit---
refcounted = {
length =<PHONE_NUMBER>15472,
bytes = 0x4 <error: Cannot access memory at address 0x4>
},
inlined = {
length = 144 '\220',
bytes = "\375\001\340\313\177\000\000\004\000\000\000\000\000\000\000\b\376\001\340\313\177\000"
}
}
}, {
refcount = 0x7fcbe00245a8,
data = {
refcounted = {
length = 8,
bytes = 0x7fcbe002b610 "\\352\352a"
},
inlined = {
length = 8 '\b',
bytes = "\000\000\000\000\000\000\000\020\266\002\340\313\177\000\000\000\000\000\000\000\000\000"
}
}
}, {
refcount = 0x0,
data = {
refcounted = {
length = 129,
bytes = 0x7fcbe0025eb0 "\b_\002\340\313\177"
},
inlined = {
length = 129 '\201',
bytes = "\000\000\000\000\000\000\000\260^\002\340\313\177\000\000\b\000\000\000\000\000\000"
}
}
}, {
refcount = 0x7fcbe0025f28,
data = {
refcounted = {
length =<PHONE_NUMBER>33960,
bytes = 0x7fcbe0025e20 "x^\002\340\313\177"
},
inlined = {
length = 200 '\310',
bytes = "E\002\340\313\177\000\000 ^\002\340\313\177\000\000\b\000\000\000\000\000\000"
---Type  to continue, or q  to quit---
}
}
}, {
refcount = 0x7fcbe0025e98,
data = {
refcounted = {
length =<PHONE_NUMBER>33960,
bytes = 0x120 <error: Cannot access memory at address 0x120>
},
inlined = {
length = 200 '\310',
bytes = "E\002\340\313\177\000\000 \001\000\000\000\000\000\000\064\000\000\000\000\000\000"
}
}
}, {
refcount = 0x7fcbe0027dd0,
data = {
refcounted = {
length = 6,
bytes = 0x336f746f7270 <error: Cannot access memory at address 0x336f746f7270>
},
inlined = {
length = 6 '\006',
bytes = "\000\000\000\000\000\000\000proto3\000\000\000\000\000\000\000\000\000"
}
}
}}
}
}
}
}
(gdb)
(gdb) frame 5
#5  0x00007fcbff0274da in grpc_byte_buffer_destroy () at /usr/src/debug/grpc/1.24.1-r0/git/src/core/lib/surface/byte_buffer.cc:83
83	  gpr_free(bb);
(gdb) l
78	  switch (bb->type) {
79	    case GRPC_BB_RAW:
80	      grpc_slice_buffer_destroy_internal(&bb->data.raw.slice_buffer);
81	      break;
82	  }
83	  gpr_free(bb);
84	}
85
86	size_t grpc_byte_buffer_length(grpc_byte_buffer* bb) {
87	  switch (bb->type) {
(gdb) frame 6
#6  0x00007fcc002240e8 in grpc::ByteBuffer::Clear (this=0x7fcbe00534f8) at /usr/include/grpcpp/impl/codegen/byte_buffer.h:135
135	/usr/include/grpcpp/impl/codegen/byte_buffer.h: No such file or directory.
(gdb) p  this->buffer_->data->raw->slice_buffer->slices[0]
$31 = {
refcount = 0x7fcbe0024970,
data = {
refcounted = {
length = 357,
bytes = 0x7fcbe00249a8 "\n\342\002\b\300\337\357\224\351\331\367\345\026\022>\022\005Ciena\032\035\n\033ciena-sys-tmet:system-state\032\026\n\024logical-core-percent"\033\n\021\022\005Ciena\032\b\n\006cpu-id\032\006\n\004"13""\034\n\023\022\005Ciena\032\n\n\bcpu-idle\032\005\065\232%\277B"!\n\030\022\005Ciena\032\017\n\rcpu-interrupt\032\005\065"
},
inlined = {
length = 101 'e',
bytes = "\001\000\000\000\000\000\000\250I\002\340\313\177\000\000\330\b\000\340\313\177\000"
}
}
}
(gdb) p  this->buffer_->data->raw->slice_buffer->slices[1]
$32 = {
refcount = 0x77206465636e7973,
data = {
refcounted = {
length =<PHONE_NUMBER>15808,
bytes = 0x8 <error: Cannot access memory at address 0x8>
},
inlined = {
length = 224 '\340',
bytes = "\376\001\340\313\177\000\000\b\000\000\000\000\000\000\000X\377\001\340\313\177\000"
}
}
}
(gdb) p  this->buffer_->data->raw->slice_buffer->slices[0].refcount
$33 = (grpc_slice_refcount ) 0x7fcbe0024970
(gdb) p * this->buffer_->data->raw->slice_buffer->slices[0].refcount
$34 = {
ref_ = 0x0,
ref_type_ = -536868656,
sub_refcount_ = 0x7fcbe0024970,
dest_fn_ = 0x7fcbff022d30 <(anonymous namespace)::MallocRefCount::Destroy(void)>,
destroy_fn_arg_ = 0x7fcbe0024970
}
(gdb)
@yashykt if you need more info of a specific frame or data structure, let me know.
I see the data structure this->buffer_->data->raw->slice_buffer->slices[0] has a valid memory and contents, so freeing this part should be a valid operation.  What is the double free pointing to?

@nicolasnoble Can you please take a look ? You had worked on this issue earlier when you advised upgrading the grpc stack.
Reference - https://github.com/grpc/grpc/issues/23270

Sorry for the late response! I don't have an obvious answer to why this might be happening.
The "ok" contains false, so we go ahead and cancel the tag:

static_cast<ICompletionManager*>(tag)->cancel();

Can this cancelling from our end cause this crash? Are we supposed to do this cleanup? Anything else we should have done?

Please advise ...

Can you talk more about this? What does "cancel()" do?

Hello, @yashykt Thanks for taking a look. The cancel() function will delete (call C++ destructor) the tag. However, with the stack trace we have, it appears that we are crashing while reading the next tag from the completion queue with AsyncNextInternal() call. The cancel() API is called after the next() call and once ok returns false.  But as the next() call is an async call, it may be possible we end up calling cancel first. But this is only my hypothesis.
Please also note, the stack version we have is 1.38 and not 1.42. There was some confusion. I am correcting the headline of this bug.  There are 6 FinishOp() calls within FinalizeResult() and the crash happens on the second call.
From a previous discussion with @nicolasnoble, this crash was anticipated due to not assigning nullptr to buffer_ in all the places where grpc_byte_buffer_destroy () was called.
The second backtrace is from 1.24.x stack in which we reported the issue first time to @nicolasnoble and he suggested to upgrade to the new stack. Here, the frame after FinalizeResult() is pointing to RunInterceptorsPostRecv() instead of FinishOp().
But SetFinishInterceptionHookPoint() also invoke Clear() eventually.
Let me know if you want more details on any frame with 1.38.x stack to assist you further.

Would you be able to share your code please?

@yashykt
I will not be able to share my code due to some legal binding on the source code.  As I am able to reproduce this problem 100% all the time, I enabled GRPC_TRACE "all" with GRPC_VERBOSITY as "info" and collected the logs a little bit before, after and at the time of crash.  If you want me to tak
grpc_crash_info.txt
e any "debug" logs of any specific TRACE option, let me know. Logs attached. The crash time was "Mon Mar 28 07:27:40 UTC 2022"

The reason I wanted to look at the code was that I was suspecting API misuse and wanted to make sure that wasn't the case. For example, freeing up some structure while gRPC still needs it. The cancel() API that you previously alluded to seemed suspect.
I've got a few other ideas to help debug -

If sharing your exact code is not possible, would you be able to create a smaller reproduction?
Since this is a double free, enabling asan (AddressSanitizer) would help find the cause quickly.
Alternatively, I can help provide pointers on how to debug this. What I would do is - add a log line here https://github.com/grpc/grpc/blob/dec86eefe4ffc108ad051a71cb5b896592de7335/src/core/lib/surface/byte_buffer.cc#L77 which would print out the stacktrace and the contents of bb.

Hello @yashykt,  I tried to investigate your suspicion over the cancel() operation.  Apparently, I found a problem as well.  It seems we were not able to fully understand the working of the completion queue before.
As I told you before, the "ok" returned false, when the grpc client got disconnected.  We did cancel and deleted the tag.  On the next read operation on the completion queue , we got the same tag pointer for which the completion queue returned false in "ok".  When "ok" returned false, the tag was in the "Enqueued" state and it was supposed to move to "Write" had it succeeded to read from the completion queue in the absence of disconnect.  So, in the next attempt after reading the next tag which was also the same tag, we followed the state machine and tried to write on the grpc queue with the invalid tag (because it was deleted).
This was further strengthened looking at the ASAN report. Please see below:
SUMMARY: AddressSanitizer: 371 byte(s) leaked in 4 allocation(s).
==252==ERROR: AddressSanitizer: heap-use-after-free on address 0x61f0000112d8 at pc 0x7f169e6e1ce6 bp 0x7f169787dff0 sp 0x7f169787dfe8
READ of size 1 at 0x61f0000112d8 thread T9 (tmet-svc-regist)
#0 0x7f169e6e1ce5  (/usr/lib/libtmetd.so.0+0x299ce5)
#1 0x3c6743c1b2 in grpc::CompletionQueue::AsyncNextInternal(void**, bool*, gpr_timespec) (/usr/lib/libgrpc++.so.1.38+0x3c6743c1b2)
#2 0x7f169e73d78a  (/usr/lib/libtmetd.so.0+0x2f578a)
#3 0x7f169e730b58 in ciena::tmet::grpc::ServerContext::run() (/usr/lib/libtmetd.so.0+0x2e8b58)
#4 0x40b98e  (/usr/bin/cn-node-tmet+0x40b98e)
#5 0x7f169dfdf4a9  (/usr/lib/libcncore.so.0+0x1624a9)
#6 0x3c5e612e93  (/usr/lib/libczmq.so.4+0x3c5e612e93)
#7 0x3c5c608ea3  (/lib/libpthread.so.0+0x3c5c608ea3)
#8 0x3c5c4f8dce in __clone (/lib/libc.so.6+0x3c5c4f8dce)
0x61f0000112d8 is located 2136 bytes inside of 2992-byte region [0x61f000010a80,0x61f000011630)
freed by thread T9 (tmet-svc-regist) here:
#0 0x3c61709f97 in operator delete(void*) (/usr/lib/libasan.so.5+0x3c61709f97)
#1 0x7f169e6c660a in std::_Sp_counted_ptr_inplace<ciena::tmet::grpc::SubscriptionSession, std::allocatorciena::tmet::grpc::SubscriptionSession, (__gnu_cxx::_Lock_policy)2>::_M_destroy(
#2 0x7f169e6d3e77  (/usr/lib/libtmetd.so.0+0x28be77)
#3 0x7f169e73dd06  (/usr/lib/libtmetd.so.0+0x2f5d06)
#4 0x7f169e730b58 in ciena::tmet::grpc::ServerContext::run() (/usr/lib/libtmetd.so.0+0x2e8b58)
#5 0x40b98e  (/usr/bin/cn-node-tmet+0x40b98e)
#6 0x7f169dfdf4a9  (/usr/lib/libcncore.so.0+0x1624a9)
#7 0x7ffe000000bd  ()
previously allocated by thread T9 (tmet-svc-regist) here:
#0 0x3c6170919f in operator new(unsigned long) (/usr/lib/libasan.so.5+0x3c6170919f)
#1 0x7f169e6bd459 in ciena::tmet::grpc::SessionManager::SessionManager(gnmi::gNMI::WithAsyncMethod_Capabilities<gnmi::gNMI::WithAsyncMethod_Get<gnmi::gNMI::WithAsyncMethod_Set<gnmi::gNMI
#2 0x7f169e75944e  (/usr/lib/libtmetd.so.0+0x31144e)
#3 0x7f169e74d551  (/usr/lib/libtmetd.so.0+0x305551)
#4 0x7f169e73e156  (/usr/lib/libtmetd.so.0+0x2f6156)
#5 0x7f169e730b58 in ciena::tmet::grpc::ServerContext::run() (/usr/lib/libtmetd.so.0+0x2e8b58)
#6 0x40b98e  (/usr/bin/cn-node-tmet+0x40b98e)
#7 0x7f169dfdf4a9  (/usr/lib/libcncore.so.0+0x1624a9)
#8 0x7ffe000000bd  ()
Thread T9 (tmet-svc-regist) created by T0 (core-reactor) here:
#0 0x3c616399b2 in __interceptor_pthread_create (/usr/lib/libasan.so.5+0x3c616399b2)
#1 0x3c5e6131ac in zactor_new (/usr/lib/libczmq.so.4+0x3c5e6131ac)
SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib/libtmetd.so.0+0x299ce5)
Shadow bytes around the buggy address:
0x0c3e7fffa200: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e7fffa210: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e7fffa220: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e7fffa230: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e7fffa240: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c3e7fffa250: fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd
0x0c3e7fffa260: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e7fffa270: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e7fffa280: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e7fffa290: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e7fffa2a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable:           00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone:       fa
Freed heap region:       fd
Stack left redzone:      f1
Stack mid redzone:       f2
Stack right redzone:     f3
Stack after return:      f5
Stack use after scope:   f8
Global redzone:          f9
Global init order:       f6
Poisoned by user:        f7
Container overflow:      fc
Array cookie:            ac
Intra object redzone:    bb
ASan internal:           fe
Left alloca redzone:     ca
Right alloca redzone:    cb
Shadow gap:              cc
I removed the cancellation (delete) part and let the tag follow its state machine on next read of the completion queue. So, now were were writing with a valid tag (not yet deleted). The Write did not get stuck and did not result in any crash.  This would have also also allowed the grpc server to write on the other live grpc client channels.
I think the issue is resolved now. Many Thanks for asking valid questions as that led to the proper investigation.


Translations update from Weblate

Translations update from Weblate for Haroohie Site/String Constants.
It also includes following components:

Haroohie Site/content/chokuretsu/serial-loops/docs/5.sound/: 2.voice

Haroohie Site/content/author/: william

Haroohie Site/content/author/: xzonn

Haroohie Site/content/chokuretsu/serial-loops/docs/: 6.misc

Haroohie Site/content/chokuretsu/guide/: sidebar

Haroohie Site/content/blog/: 11.2024-02-29-chokuretsu-rom-hacking-returns

Haroohie Site/content/blog/: 8.2023-09-11-september-2023-progress-update

Haroohie Site/content/blog/: 7.2023-06-25-serial-loops-0-2-is-out-now

Haroohie Site/content/chokuretsu/serial-loops/docs/4.graphics/: 2.sprites

Haroohie Site/content/chokuretsu/serial-loops/docs/3.scenario/: 3.maps

Haroohie Site/content/chokuretsu/serial-loops/docs/1.introduction/: 1.installation

Haroohie Site/content/chokuretsu/serial-loops/docs/: 2.scripts

Haroohie Site/content/chokuretsu/serial-loops/docs/3.scenario/: 2.group-selections

Haroohie Site/content/: chokuretsu

Haroohie Site/content/chokuretsu/: patch

Haroohie Site/content/chokuretsu/serial-loops/docs/: 4.graphics

Haroohie Site/content/chokuretsu/serial-loops/docs/: 5.sound

Haroohie Site/content/chokuretsu/serial-loops/docs/6.misc/: 4.ui-text

Haroohie Site/content/: index

Haroohie Site/content/author/: jonko

Haroohie Site/content/chokuretsu/patch/: sidebar

Haroohie Site/content/blog/: 5.2023-03-10-chokuretsu-compression-archive-followup

Haroohie Site/content/chokuretsu/serial-loops/docs/3.scenario/: 4.puzzles

Haroohie Site/content/chokuretsu/serial-loops/docs/: 1.introduction

Haroohie Site/content/blog/: 15.2024-11-01-rom-hacking-to-translate-dbk

Haroohie Site/content/chokuretsu/guide/: 1.buying-the-game

Haroohie Site/content/chokuretsu/: guide

Haroohie Site/content/blog/: 13.2024-08-03-chokuretsu-chinese-chartable

Haroohie Site/content/blog/: 10.2024-01-24-rom-hacking-panel

Haroohie Site/content/blog/: 1.2022-10-17-welcome-why

Haroohie Site/content/author/: pigo

Haroohie Site/content/author/: fuyuko-ayumu

Haroohie Site/content/chokuretsu/serial-loops/docs/4.graphics/: 5.system-textures

Haroohie Site/content/chokuretsu/serial-loops/docs/2.scripts/: 1.commands

Haroohie Site/content/chokuretsu/serial-loops/docs/2.scripts/: 2.chibis-and-choices

Haroohie Site/content/chokuretsu/serial-loops/: sidebar

Haroohie Site/content/chokuretsu/serial-loops/docs/3.scenario/: 1.game-flow

Haroohie Site/content/blog/: 3.2022-11-02-chokuretsu-archives

Haroohie Site/content/blog/: 9.2023-10-31-episode-3-now-available

Haroohie Site/content/blog/: 2.2022-10-19-chokuretsu-compression

Haroohie Site/content/blog/: 4.2023-02-28-episode-2-now-available

Haroohie Site/content/chokuretsu/serial-loops/docs/6.misc/: 2.topics

Haroohie Site/content/chokuretsu/serial-loops/docs/4.graphics/: 1.backgrounds

Haroohie Site/content/chokuretsu/guide/: 2.dumping-the-rom

Haroohie Site/content/: blog

Haroohie Site/content/chokuretsu/serial-loops/docs/2.scripts/: 3.investigation-phase

Haroohie Site/content/chokuretsu/serial-loops/docs/1.introduction/: 3.project-workflow

Haroohie Site/content/chokuretsu/serial-loops/docs/1.introduction/: 2.getting-started

Haroohie Site/content/chokuretsu/serial-loops/docs/: 3.scenario

Haroohie Site/content/chokuretsu/serial-loops/: docs

Haroohie Site/content/chokuretsu/: credits

Haroohie Site/content/chokuretsu/serial-loops/docs/4.graphics/: 4.places

Haroohie Site/content/chokuretsu/: serial-loops

Haroohie Site/content/blog/: 14.2024-08-10-rom-hacking-panel-2024

Haroohie Site/content/blog/: 12.2024-03-13-chokuretsu-event-files

Haroohie Site/content/chokuretsu/guide/: 4.playing-the-game

Haroohie Site/content/chokuretsu/guide/: 3.patching-the-rom

Haroohie Site/content/chokuretsu/serial-loops/docs/6.misc/: 3.applying-hacks

Haroohie Site/content/chokuretsu/serial-loops/docs/6.misc/: 1.characters

Haroohie Site/content/chokuretsu/serial-loops/docs/4.graphics/: 3.chibis

Haroohie Site/content/chokuretsu/serial-loops/docs/5.sound/: 1.bgm

Haroohie Site/content/blog/: 6.2023-04-15-serial-loops-0-1-now-available

Current translation status:

Yes, this is briefly going to make four blog posts appear on the site. It's necessary because I forgot I had to do that manually. 🤪


Error handling and CSS

Fix errors with ai bot possibly implementing backend to work with API key
continue work with forum making better css
stopping errors and  ensuring proper text is sent in API calls, more error handling
making ai bot and forum more visually appealing


Passing data back from the PresentationController

Hello,
Briefly: I have a ViewController A and a MZFormSheetPresentationController B (TableView), and I want to pass data back from B -> A.
I already tried to use several methods like protocol, delegate, unwind segue etc, but it seems that there is no effect.
As I am new to Swift and iOS, I'm not sure if it's because I didn't find the right method. Thank you very much for helping.
More details: On my ViewController A, there is a button which present a MZFormSheetPresentationController B, just as in the example given:

@IBAction func withWhoPop(sender: UIButton) {
    let navigationController = self.storyboard!.instantiateViewControllerWithIdentifier("Navigation") as! UINavigationController
    let formSheetController = MZFormSheetPresentationViewController(contentViewController: navigationController)
   formSheetController.presentationController?.shouldDismissOnBackgroundViewTap = true
    formSheetController.presentationController?.contentViewSize = CGSizeMake(300, 500)
    self.presentViewController(formSheetController, animated: true, completion: nil)
}

B is a TableView, and each row corresponds to a group.
Each row has: a label (name of the group), and a button (which leads to a distinct tableView C. C contains the elements of the corresponding group).
Once the used has selected a row in B, I want to pass the name of the row back to A, and replace the label of the button on A by this name.
Thank you very much for your reading time, and I would be grateful if you could give me some indication. I tried for several days and don't see what I can do now.

Sorry, may I ask if it is closed because my question is not relevant...?
Thanks

You have to implement standard delegate, or block pattern with callback, MZFormSheetPrenestationController is only for presentation rest you have to do by yourself and there is no difference with behaviour between this and standard one. I would recomment you to ask a question on stackoverflow

Thank you very much for your kind confirmation, I will try again.


Disabling bounce effect on every div

Fix for https://github.com/ionic-team/ionic/issues/11844#issuecomment-392202815
Fix originally proposed by @daansystems

Thanks but this isn’t a solution to that problem and removing bouncing is not something we want. See my comment in that other issue for the rea problem and a possible solution

Oh yeah you're right, I didn't think this through. Okay I'll finish my project and then look for the right condition to add. I think detecting if the DisallowOverscroll parameter is set to true as a condition would be better, right ?

this solution did not work for me. :(

@cristianfloresee
Did you make sure the file was not getting overwritten ?
Did you modify the file un the plugin folder or in the platforms/ios folder ?
I'm pretty sure the solution is the answer of one of these questions ;-)


Memory usage when training on videos

Hi,
I'm trying out this model through Napari on calcium imaging videos.
The videos are loaded as TIFF, and the training is done on CPU as I'm still figuring out the TF version issue.
I tried with both the default (SYX) or expected (TYX) axes, it seems that patches are generated for each frame of the video.
Output is :
Generated patches: (512, 64, 64, 1)

Repeated a bunch of times, presumably one per frame, then :
Train patches: (615424, 64, 64, 1)
Val patches: (615424, 64, 64, 1)

This results in 90+ Gb of memory usage, which increases even further after the first epoch is finished and crashes with an OOM error on my machine (128 Gb of RAM).
Is this the expected behavior on videos, or is there a better way of handling things ?
I ended up extracting the first frame of a video and training on it, with decent results for a first attempt.
On an unrelated note, I found that loading proprietary file formats through third party plugins sometimes return frames as xarrays instead of numpy arrays, which apparently is what is expected from this plugin.
I'm not familiar with napari guidelines, is it up to IO plugins to align with a specific array type or up to processing plugins to be compatible with different arrays ?
Thanks !

Hi there,
Really sorry for the lack of answer, it was a busy summer and we are working hard to provide a new plugin version backed up by a new library.
Obviously something is going wrong, as you already have patched data (64, 64) and it should just take the 512 patches as is, and just apply augmentations (x8 factor). The plugin simply calls the functions from n2v, so I'd assume the error is there.
I will try to look into it.

On an unrelated note, I found that loading proprietary file formats through third party plugins sometimes return frames as xarrays instead of numpy arrays, which apparently is what is expected from this plugin.
I'm not familiar with napari guidelines, is it up to IO plugins to align with a specific array type or up to processing plugins to be compatible with different arrays ?

As far as I know there is no guideline, it is up to the plugins (including IO) to do what they want.
Do you get an error if the xarray is passed to the plugin now? I'd expect xarrays to be seamlessly processed by functions expecting a numpy array. But I don't have much experience with xarrays.
As I said, I am sorry things are super slow on this front, I am the only one to maintain the plugin and there is not much time for me to spend on this. On the bright side, I am currently switching the back end of the plugin to CAREamics (https://careamics.github.io/0.1/), which has an entire team to support it. So once we have successfully released the new napari plugin, there will be several people able to help (and with a mandate to do so)!


Export to SVG flipped the paths, polygons, etc. Is there a reason?

Hi! Great work Porting SvgNest! I found that when exporting the figures (1.svg to 18.svg) nested, they're flipped upside down... Attached image! Thanks!!

My workaround : added in the SvgParser.cs -> Export(polygons, sheets) line:
sb.AppendLine($"<path fill="{fill}"  stroke="black" transform="scale(1, -1) translate(0, -{height})" d ="");
where {height} is the Sheet.HeightCalculated value. This change flips every path vertically.

Hi, there is no specific reason for flipped parts in SVG export.  SVG export was temporary, before DXF was implemented.


MINOR: fix flaky KRaft-related tests

In SharedServer, fix some cases where a volatile variable could change to null while we were using
it, during shutdown. This is mainly a junit test issue, although it could also cause ugly error
messages during shutdown when running the server in a production context.
Fix a race in KafkaEventQueueTest.testSize.

Cherry-picking this to 3.5.


az monitor diagnostic-settings create unable to provide resource id

Describe the bug
When I run the az monitor diagnostic-settings create -n "name" --resource /subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.KeyVault/vaults/{name}
(I copied the resource from the portal)
I get the error:
ERROR: usage error: --resource ID | --resource NAME --resource-group NAME --resource-type TYPE [--resource-parent PARENT] [--resource-namespace NAMESPACE]
It does work when I use the resource name together with the group name and resource type, but I want to use the ID.
I also want to add a workspace in a different resource group, this is why I want to use the resource ID.
btw: providing the workspace with the workspace resource id also doesn't work.
Related command
az monitor diagnostic-settings create
Errors
ERROR: usage error: --resource ID | --resource NAME --resource-group NAME --resource-type TYPE [--resource-parent PARENT] [--resource-namespace NAMESPACE]
Issue script & Debug output
DEBUG: cli.azure.cli.core.azclierror: Traceback (most recent call last):
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 233, in invoke
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 663, in execute
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 726, in _run_jobs_serially
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 697, in _run_job
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/aaz/_command.py", line 149, in call
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/monitor/aaz/latest/monitor/diagnostic_settings/_create.py", line 33, in _handler
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/monitor/aaz/latest/monitor/diagnostic_settings/_create.py", line 176, in _execute_operations
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/monitor/operations/diagnostics_settings.py", line 95, in pre_operations
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/monitor/operations/diagnostics_settings.py", line 67, in update_resource_parameters
knack.util.CLIError: usage error: --resource ID | --resource NAME --resource-group NAME --resource-type TYPE [--resource-parent PARENT] [--resource-namespace NAMESPACE]
ERROR: cli.azure.cli.core.azclierror: usage error: --resource ID | --resource NAME --resource-group NAME --resource-type TYPE [--resource-parent PARENT] [--resource-namespace NAMESPACE]
ERROR: az_command_data_logger: usage error: --resource ID | --resource NAME --resource-group NAME --resource-type TYPE [--resource-parent PARENT] [--resource-namespace NAMESPACE]
DEBUG: cli.knack.cli: Event: Cli.PostExecute [<function AzCliLogging.deinit_cmd_metadata_logging at 0x0405C658>]
INFO: az_command_data_logger: exit code: 1
INFO: cli.main: Command ran in 0.627 seconds (init: 0.254, invoke: 0.373)
INFO: telemetry.main: Begin splitting cli events and extra events, total events: 1
INFO: telemetry.client: Accumulated 0 events. Flush the clients.
INFO: telemetry.main: Finish splitting cli events and extra events, cli events: 1
INFO: telemetry.save: Save telemetry record of length 3540 in cache
WARNING: telemetry.check: Negative: The C:\Users\xxxxxx.azure\telemetry.txt was modified at 2023-07-06 12:27:26.650172, which in less than 600.000000 s
Expected behavior
That the command can find the resource when the resource id is provided.
Environment Summary
azure-cli                         2.50.0
core                              2.50.0
telemetry                          1.0.8
Dependencies:
msal                              1.22.0
azure-mgmt-resource             23.1.0b2
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\xxxxxxxx.azure\cliextensions'
Python (Windows) 3.10.10 (tags/v3.10.10:aad5f6a, Feb  7 2023, 17:05:00) [MSC v.1929 32 bit (Intel)]
Additional context
No response

Thank you for opening this issue, we will look into it.


fix small typo

@dstine Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@pivotal-issuemaster this is a trivial fix

@pivotal-issuemaster this is an Obvious Fix


Added markdown

(first git contribution. Sorry if I did it wrong.) I did NOT use the build script or test it. Added everything by hand.
In mime.type
I uncommented the #text/markdown line & added 'md' as the extension
I added 'md' as an extension to the text/plain line
In mime.type.php
I added 'text/markdown' entry to the php array w/ 'md' as its only extension
I added 'md' as an extension to the 'text/plain' entry
I added 'md' entry to the php array w/ 'text/markdown' and 'text/plain' as it's types

Coverage remained the same at 100.0% when pulling 7e1e4fb1b675d0b7da1f7235129870f778964964 on ReedOverflow:add-markdown into bafaa2c603dd070736bf8a37ea2daf5654d226f2 on ralouphie:develop.

Coverage remained the same at 100.0% when pulling 7e1e4fb1b675d0b7da1f7235129870f778964964 on ReedOverflow:add-markdown into bafaa2c603dd070736bf8a37ea2daf5654d226f2 on ralouphie:develop.


fallback if user.name is null

Github user profiles may not have a user name (can be null), but they always have a login name. Login name should be used as default or at least as a fallback method.

Thanks @styxlab


[$50] We should not allow increasing Working Days more than fit Resource Booking

To implement this we have to create a reusable method which would return maximum allowed daysWorked for the WorkPeriod inside Resource Booking.

The logic how we calculate daysWorked is described here https://github.com/topcoder-platform/taas-apis/wiki/Work-Periods-(WP)-Automation-and-Constraints#resourcebooking-is-created
Also, we implemented a similar logic sever-side which may be used for reference https://github.com/topcoder-platform/taas-apis/blob/dev/src/common/helper.js#L1776-L1810 (note, that on server this method calculates all work periods for the ResourceBookings, but we need just to get the maximum allowed daysWorked for one Work Period)
After having this method we should not allow to increase the Working Days more than possible value for each Work Period.

Tooltips:

we already cannot decrease the number of working days to be less than daysPaid
we have to explain to the user why they cannot decrease or increase the working days number by showing the reason in Tooltip
to do so we have to show tooltip with the reason when the user hover mouse on the - or + buttons (only when they cannot press them):

Cannot decrease "Working Days" to less than day already paid: ${daysPaid}
Cannot increase "Working Days" because the end date of the Resource Booking is ${RB.endDate}

Additionally disabled decrease button when the current value is 0 because we cannot make it less. We don't show tooltip in such case, because the reason for disabling button is clear.

@maxceem I am able to see some '+' and '-' are slightly bolder than others.

Other than above, functionality wise everything is working fine.

@sandhiyakavi I believe the issue with bolder - and + is a different existent issue and it's not connected with the functionality we implemented in this issue. Can we track it separately? Also, could you, please, mention your browser and operation system, I believe it only happens on some OS and browser, as it doesn't happen to me.

Paid via https://www.topcoder.com/challenges/022e449b-b58c-4153-a07e-218d2a4c8801

Verified on Prod Env with @nkumar-topcoder


Audio Output

@triniwiz How can we change the audio output from the earpiece speaker to the main speaker. ?

webrtc.speakerEnabled(true)

@triniwiz  I tried using this.webrtc.speakerEnabled(true); but it's not working in iOS.

https://github.com/triniwiz/nativescript-webrtc/blob/master/src/webrtc.ios.ts#L435 is the code used guessing some error could be throwing but i'm not logging it you can try throwing in a log there

Logging below error NSErrorWrapper: Must call lockForConfiguration before calling this method.

Thanks for the update will publish a new fix soon

This fix did not resolve the issue for me (on iPhone XS / iOS 12), so I wrote this piece of code that fixed it:
``NSNotificationCenter.defaultCenter.addObserverForNameObjectQueueUsingBlock(
AVAudioSessionRouteChangeNotification,
null,
NSOperationQueue.mainQueue,
(notification: NSNotification) => {
            const interuptionDict = notification.userInfo;
            const routeChangeReason = interuptionDict.valueForKey(AVAudioSessionRouteChangeReasonKey);

            if (routeChangeReason == AVAudioSessionRouteChangeReason.CategoryChange) {

                const audioSession = AVAudioSession.sharedInstance();

                try {
                    const success = audioSession.overrideOutputAudioPortError(
                        AVAudioSessionPortOverride.Speaker
                    );

                    if (success == false) {
                        console.log('Could not overrideOutputAudioPortError.');
                    }
                } catch (error) {
                    console.log('Could not overrideOutputAudioPortError:', error);
                }
            }
        });

    const audioSession = ios.getter(
        RTCAudioSession,
        RTCAudioSession.sharedInstance
    );

    try {
        audioSession.setCategoryWithOptionsError(
            AVAudioSessionCategoryPlayAndRecord,
            AVAudioSessionCategoryOptions.DefaultToSpeaker
        );
    } catch (e) {
        console.log('MINSAMTALE: Could not toggle speaker:', e);
    }``


[formrecognizer] Expose new features on document analysis methods

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-formrecognizer


Clicking 'close' on the mod manager is still passed through to game UI

A click on the Close button closes the mod manager and is then passed through to the game.

ESC to close is passed as well

Fixed in ModApi


Fix Proposal Warnings Not Displaying

Proposal warnings are not displaying on the proposal details views.
They should have something similar to this:

Once we get them displaying we should make sure the copy is appropriate

These are displaying. Need to make sure the copy is what we want

Initiate Vote: Proposal for DAO voting signal. No transactions are executed.
Add Partner: Proposal issues voting or non-voting tokens from the DAO.
Become Partner: Proposal issues voting or non-voting tokens from the DAO.
Fund Company: Proposal transfers ERC-20 tokens from DAO treasury.

Think these are fine


Extend addopts rather than overwrite

This PR allows addopts to be extended with command line arguments rather than overridden, fixing #626
I added a simple test, actually it modifies an existing test that seemed to be checking for the overwrite behaviour. Let me know if you'd rather have a new test and whether I chose an appropriate location for the test.

Thanks @tcbegley for your awesome PR! I'll take a closer look / merge / make a new release after work

@all-contributors please add @tcbegley for idea, code, doc


[release blocker] doc test failing on beta branch (next stable)

As seen on flutter dashboard, doc test has been failing on beta branch throughout multiple releases.  https://flutter-dashboard.appspot.com/#/build?repo=flutter&branch=flutter-3.13-candidate.0
When we promote beta to stable in a few weeks, would be great if the doc test is green. Attempted a fix but after many hours we couldn't find the root cause of the error. Would be great if expert like @godofredoc @sealesj could help provide some insights. Thank you!
cc @CaseyHillers

This seems like a problem with the docs generation.
\s*<iframe\s+class="snippet-dartpad"\s+src="https:\/\/dartpad.dev\/embed-flutter.html\?.*?\bsample_channel=flutter-3.13-candidate.0\b.*">\s*<\/iframe>' in dev/docs/doc/api/widgets/Listener-class.html.

What happens when you checkout the release candidate branch and run: ./dev/bots/docs.sh?

thanks for inspecting! yeah running docs.sh on release candidate branch 3.13.0 gives many exceptions in https://paste.googleplex.com/5282349536247808

Still unsure why doc tests fail.
For context, Greg verified that when release branch is checked out locally, doc tests pass. However, if doc tests fail on luci, it would not upload the docs to the api.flutter.dev website. and this might be bad if we later decide to promote this branch to stable, because the docs would be out of sync

Moving out of release blockers.
I was able to manually verify the latest beta hash's doc.zip, and looking at the culprit api page I do not see any regressions. I sampled a few other pages as well and do not see other issues.

The problem is that current list of branches is returned with white spaces:
['* (HEAD detached at 7e07cd41cb)', '  remotes/origin/flutter-3.13-candidate.0']

And the logic fails here: https://cs.opensource.google/flutter/recipes/+/master:recipe_modules/repo_util/api.py;l=336?q=is_release_candidate_branch&ss=flutter

Fixed with https://flutter-review.googlesource.com/c/recipes/+/48980

Yeah thanks a lot for the fix for both doc test and code sign!


feat: the menu adapter of select

Checklist

[ ] Fix linting errors
[ ] Tests have been added / updated (or snapshots)

Change information

Why is this commit so long?


Fix elf sections so it returns the last section.

Can you add a testcase that explicitly tests the number of elf sections?  Maybe re-use the input data from the grub test, so we don't blow up the size of src/lib.rs.

Added a new test focused on elf sections. It only has one section, so the bug is painfully obvious.

Have you tested? Short on time and can't test myself.

@ahmedcharles

Yeah, I wouldn't add a test without running it. Also, CI passed.

I've also tested it in a kernel.

@xacrimon Do you have permissions for merging?  If so, you can probably go ahead and merge the reviewed PRs

Thanks.


Getting rid of debug flows and running w/o debug mode

My latest one-year run (Oct 2002 - Sep 2003) had some debug flows. But results are promising. It occurred in a few places and the problem seems to end-of-period storage problem for reservoirs. One debug flow on SR_BUL is quite big, others are small. I am just creating this issue. I need to run 82-year model and make calibration on that run not 1 year if needed. Since CALVIN and Hobbes test could be run w/o debug mode, we need to take a closer look what is causing it before modifying fixed time-series and minimum in-stream flow requirements.
1-year run debug flows:
Link: DBUGSRC-SR_BUL, Time: 2003-09-30, Flow: 165.997728
Link: DBUGSRC-SR_CLE, Time: 2003-09-30, Flow: 1.42277304048493
Link: DBUGSRC-SR_CR1, Time: 2003-09-30, Flow: 0.00999999977648258
Link: DBUGSRC-SR_CR2, Time: 2003-09-30, Flow: 0.00999999977648258
Link: DBUGSRC-SR_HTH, Time: 2003-09-30, Flow: 0.869099103516036

After Justin's updates for the new matrix format and fixes for MIF links that does not have a cost, I run the model (82-year) without debug mode but the solution got infeasible, so I run in debug mode and here are debug flows. Small flow amounts but enough to make the solution infeasible.\
Link: C18-DBUGSNK, Time: 2000-12-31, Flow: 1e-06
Link: DBUGSRC-N201, Time: 1924-09-30, Flow: 0.01931791186052756
Link: DBUGSRC-N201, Time: 1931-10-31, Flow: 0.0003588662482307825
Link: DBUGSRC-N201, Time: 1988-08-31, Flow: 0.036107923837622735
Link: DBUGSRC-N201, Time: 1988-10-31, Flow: 0.0003578662482306427
Link: DBUGSRC-SR_GNT, Time: 1948-04-30, Flow: 0.038725496962414674
Link: DBUGSRC-SR_GNT, Time: 1955-04-30, Flow: 0.03436905715971994
Link: DBUGSRC-SR_GNT, Time: 1978-03-31, Flow: 0.18396324513581153
Link: DBUGSRC-SR_RLL_CMB, Time: 1924-10-31, Flow: 0.0003578662482306427
Link: DBUGSRC-SR_RLL_CMB, Time: 1931-09-30, Flow: 0.024019490745414984
Link: DBUGSRC-SR_RLL_CMB, Time: 1988-09-30, Flow: 0.0004341997355741256
Link: HSD203-DBUGSNK, Time: 1925-12-31, Flow: 1e-06
Link: HSD203-DBUGSNK, Time: 1997-12-31, Flow: 1e-06
Link: WWP402-DBUGSNK, Time: 2000-01-31, Flow: 1e-06

Thanks Mustafa. Ok no big deal -- these are REALLY small, just numerical noise.
What is the usual process for fixing debug flows? Add more inflow somewhere?

Yeah there are two options: 1) Inject small flow to origin node of problematic links, 2) Find lower or upper bound constraint that causes mass balance problem and reduce it.
In the past, I chose the second option first. For this case, flow amounts are very small, so injecting small inflows mights be okay?

Sounds like option (1) would require adding new links, right? That could get confusing later.
With (2) we could just slightly modify the constraints by a few decimal places, although I'm not sure whether to increase or decrease them. But that sounds better to me.

Sounds like option (1) would require adding new links, right? That could get confusing later.
With (2) we could just slightly modify the constraints by a few decimal places, although I'm not sure whether to increase or decrease them. But that sounds better to me.

Yes, option 1 requires adding new links. However, N201 is upstream of SR_RLL_CMB and we already have a calibration link (CN2) that inject flow.
For option 2, this can be a little tricky because the model does not always put debug flows in the same place and time where the mass balance problem occurs. It can put very upstream reservoir to get some hydropower benefit, or in a previous time-period to reduce scarcity somewhere else. I had this problem a lot when I was dealing with debug flows, which was much greater than this. And then, I decided to use dual values on constraint flows. It gives the precise time and location.
If it is a debug source, we need to reduce the constraint and opposite for debug sink.
We can discuss this in more detail in our first meeting.

Yes, option 1 requires adding new links. However, N201 is upstream of SR_RLL_CMB and we already have a calibration link (CN2) that inject flow.
For option 2, this can be a little tricky because the model does not always put debug flows in the same place and time where the mass balance problem occurs. It can put very upstream reservoir to get some hydropower benefit, or in a previous time-period to reduce scarcity somewhere else. I had this problem a lot when I was dealing with debug flows, which was much greater than this. And then, I decided to use dual values on constraint flows. It gives the precise time and location.
If it is a debug source, we need to reduce the constraint and opposite for debug sink.
We can discuss this in more detail in our first meeting.

Ok, got it. Either one is fine with me since it won't have any affect on the output.

Here are debug flows after updating decimal places on input parameters (https://github.com/ucd-cws/calvin-network-tools/issues/48). We got rid of some noise, but there is still some to eliminate. Note: I haven't done anything, this is just after running with new decimal places.
Link: DBUGSRC-N201, Time: 1924-09-30, Flow: 0.022365432685755415
Link: DBUGSRC-N201, Time: 1931-10-31, Flow: 0.0018744477468057852
Link: DBUGSRC-N201, Time: 1988-09-30, Flow: 0.0005010300782868349
Link: DBUGSRC-N201, Time: 1988-10-31, Flow: 0.0008744477468054512
Link: DBUGSRC-SR_GNT, Time: 1948-04-30, Flow: 0.04043407809307542
Link: DBUGSRC-SR_GNT, Time: 1955-04-30, Flow: 0.035512803545655114
Link: DBUGSRC-SR_GNT, Time: 1978-03-31, Flow: 0.17911455385713015
Link: DBUGSRC-SR_RLL_CMB, Time: 1931-09-30, Flow: 0.025860218859669715
Link: DBUGSRC-SR_RLL_CMB, Time: 1988-08-31, Flow: 0.04098622248936756

@jdherman @mimijenkins1 for Bear river watershed (N201, SR_RLL_CMB), I used the existing calibration link to inject small flow amounts above.
Here are debug after adding infeasibility flows for N201 and SR_RLL_CMB.
Link: DBUGSRC-N201, Time: 1924-09-30, Flow: 0.00036543268575517374
Link: DBUGSRC-SR_GNT, Time: 1948-04-30, Flow: 0.04043407809307542
Link: DBUGSRC-SR_GNT, Time: 1955-04-30, Flow: 0.035512803545655114
Link: DBUGSRC-SR_GNT, Time: 1978-03-31, Flow: 0.17911455385713015

Now, we have debug flows for the 82-year run only for 4 locations/time-steps. I will add debug flow amount for DBUGSRC-N201 to existing link (CN2-N201).
For DBUGSRC-SR_GNT, however, we do not have a calibration link. I couldn't find which MIF or constrained flow is causing mass balance problem. I was wondering if it is okay to add these small debug flows to existing Mono Basin rim inflows since they are very small.
The schematic shows Mono basin and green dots represent minimum in-stream if storage requirements.

closing this issue. all debug flows are eliminated and pyvin can be run without debug mode

Woohoo!! 🚀

:)
In summary what I did is:

For DBUGSRC-N201 and DBUGSRC-SR_RLL_CMB, use existing calibration flow link and increase calibration flow amounts by debug flow amounts.
For DBUGSRC-SR_GNT reduce minimum in-stream flow requirement on SR_GNT-SR_ML by debug flow amount.

Yup! Well done Mustafa and team.
A great milestone.
Mimi
On Mon, 09 Jan 2017 16:21:30 -0800, Jon Herman<EMAIL_ADDRESS>wrote:

Woohoo!! 🚀
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

--
Marion W. Jenkins, PhD
Research Engineer
Dept. Civil & Environmental Engineering
Ghausi Hall, Rm 3019
University of California at Davis
Davis, CA 95616

Mustafa, this is great news. This has moved CALVIN into new era. Thanks for
your diligent work.
Kind regards,
Josue
On Mon, Jan 9, 2017 at 4:46 PM, mimijenkins1<EMAIL_ADDRESS>wrote:

Yup! Well done Mustafa and team.
A great milestone.
Mimi
On Mon, 09 Jan 2017 16:21:30 -0800, Jon Herman<EMAIL_ADDRESS>wrote:

Woohoo!! 🚀
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

--
Marion W. Jenkins, PhD
Research Engineer
Dept. Civil & Environmental Engineering
Ghausi Hall, Rm 3019
University of California at Davis
Davis, CA 95616
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/msdogan/pyvin/issues/29#issuecomment-271453976, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ANGlbKwXDHkvgnTrEVrG-M2zRsBSE66Tks5rQtThgaJpZM4KwTsJ
.

--
Josué Medellín-Azuara, Ph.D.
Associate Research Engineer
Department of Civil and Environmental Engineering
Center for Watershed Sciences
University of California, Davis
One Shields Ave. Davis, CA 95616
Mobile: + 1<PHONE_NUMBER>
Website: http://watershed.ucdavis.edu/medellin
Convener California Water and Environmental Modeling Forum, CWEMF
http://cwemf.org
Be green! Please don't print this e-mail unless you really need to.

Yes!  +1 +1


TFVC checkout documentation update

I changed following items:

itemspec parameter was talking about "check in" instead of "check out".
Added jump to anchor in page for more information about itemspec.

@Styxxy Thank you for your contribution, I am merging it now and it should be live shortly. Please accept our apologies for this initial delay while we work though the initial backlog of contributions.


Upload failed unexpectedly after 5 attempt

Storage Explorer Version: 1.10.1
Build Number: 20190919.2
Platform/OS: Windows 10
Architecture: x64
Regression From: NA
Bug Description
Trying to upload a VHD file through the Storage Explorer but its not working, we are getting the following error log. We are connected to Azure using the connection string method.
{
"message": ""Upload failed unexpectedly after 5 attempt""
}
Steps to Reproduce
Copying a VHD file (100GB) to a blob conteiner.
Expected Experience
We want to be able to copy the VHD file to a blob container so we can build our server.
Additional Context
We also tried to connect through our domain account and upload the file but that feiled as well, we got the following error.
{
"name": "StorageError",
"message": "This request is not authorized to perform this operation using this permission.\nRequestId:b4fbf996-b01e-0025-78bd-84119d000000\nTime:2019-10-17T07:33:40.8825690Z",
"stack": "StorageError: This request is not authorized to perform this operation using this permission.\nRequestId:b4fbf996-b01e-0025-78bd-84119d000000\nTime:2019-10-17T07:33:40.8825690Z\n    at Function.StorageServiceClient._normalizeError (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\azure-storage\lib\common\services\storageserviceclient.js:1205:23)\n    at Object.StorageServiceClient._processResponse (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\azure-storage\lib\common\services\storageserviceclient.js:751:50)\n    at Request.processResponseCallback [as _callback] (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\azure-storage\lib\common\services\storageserviceclient.js:319:37)\n    at Request.self.callback (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\request\request.js:185:22)\n    at Request.emit (events.js:182:13)\n    at Request. (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\request\request.js:1157:10)\n    at Request.emit (events.js:182:13)\n    at IncomingMessage. (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\request\request.js:1079:12)\n    at Object.onceWrapper (events.js:273:13)\n    at IncomingMessage.emit (events.js:187:15)",
"code": "AuthorizationPermissionMismatch",
"statusCode": 403,
"requestId": "b4fbf996-b01e-0025-78bd-84119d000000"
}
Thank you.
Regards,
Igor

Do you have the write permission?  The error message seemed to suggest you don't have permission to write.

Closing due to lack of reply.


Exists property is missing from ExistsResponse and ExistsAliasResponse

Elastic.Clients.Elasticsearch version: 8.13.1
Elasticsearch version: 8.11
.NET runtime version: 8.0
Operating system version:
Description of the problem including expected versus actual behavior:
ExistsResponse (both classes) and ExistsAliasResponse do not have an Exists property anymore.
Steps to reproduce:
1.
2.
3.
Expected behavior
A clear and concise description of what you expected to happen.
Provide ConnectionSettings (if relevant):
Provide DebugInformation (if relevant):

Hi @gpetrou,
thanks for reporting!
These properties are not defined in the specification. The old generator had a hardcoded condition to emit these properties. I'll manually add them back in the next patch release.

Do we need them? I think that "IsValidResponse" is enough to validate that, no?

@TheFireCookie That's correct, we don't really need them. These properties are just checking the status code - just like IsValidResponse:
public bool Exists => ApiCallDetails is
{
    HasSuccessfulStatusCode: true, HttpStatusCode: 200
};

For now I'll still add them back to not introduce more breaking changes than needed 🙂
I might remove them in the next major version. Another option would be to keep them and override IsValidResponse in addition. For these endpoints, a 404 is actually valid in my opinion. But that might over-complicate things as users are probably used to expect false for IsValidResponse when entities are non existing.

This property exists since NEST. Why remove it? There are already too many breaking changes to worry about.

Fixed in 8.13.4


Move to PyIceberg

Describe the bug
The current release of Datahub uses the legacy iceberg library. It is better to move to PyIceberg.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Being worked on in https://github.com/datahub-project/datahub/pull/8357

Closing this as https://github.com/datahub-project/datahub/pull/8357 was merged.


Content of "rea" with standardized "core" error codes

It would be interesting to have an error code part, before the error string. And with some standardized error code values.
I've also seen this issue sugesting adding a new tag "reaCode": #91
But if not wanted to avoid breaking "core" specifications, we could simply add an error code at the start of the current "rea" string like this:
"x: yyyyyy..." with

x = error code
yyyyyy... = a free string error description.

A supervisor (or another equipment) could just make use of the value before ":" separator character.
A list of standardized errors codes should be defined at the RSMP "Core" level in the specifications.
Also each SXL could define some errors adapted to its field. Perhaps adding an "error" sheet in the Excel document could be interesting (for information, not linked with yaml).
To avoid numbering clash with RSMP "Core" list, adding letters prefix before the error code could be used.
The TLC SXL should not have any RSMP "core" errors part included (only keeping plans errors, I/O errors, ...).
Ideas of errors for a standardized list for RSMP "Core" we could retrieve in the specifications :
"1: failed to desereliaze packet"
"2: error on bad packet mType not 'rSMsg'"
"3: unknown message type"
"4: missing/error for a JSON element"
"5: RSMP version requested not supported"
"10: unknown site"
"11: site already connected"
"20: SXL version requested not supported"
"30: for an alarm, failed to find aCId"
"31: for an alarm, unknown alarm specialisation"
"40: for a status, unknown sCI"
"41: for a status, unknown argument name"
"42: for a status, invalid or out of range value"
"50: for a command, unknown cCI"
"51: for a command, unknown argument name"
"52: for a command, incomplete arguments"
"53: for a command, invalid or out of range value"

The string error description can be dynamically generated with more or less details.
Example for an incompatible RSMP version:
"5: RSMP versions [3.2] requested, but only [3.1.1,3.1.2,3.1.3,3.1.4,3.1.5] supported"
Example for an unknown message type:
"3: unknown message type 'StatusReq'"

I would much prefer adding a reaCode, so that it can be validated with JSON Schema.

It would be possible to to have just a code, but sometimes it might be restrictive. I think a code + decrription is best.
Codes would be strings (enums), like 'unknownMessage', 'connectionError', etc.

The problem of adding a new reaCode is breaking current RSMP Core. So for now, we have to do with the single rea string available.
About the code value, isn't a simple numeric value more flexible for evolutions ? (not needing to enum all the possible strings errors exclusively).

I think we do want to enumerate all the codes, because that means we can validate the scheme. That also means added new codes in needed.
Whether we use an integer or an enum string, doesn't make a big difference in how we maintain the spec. But an integer has a smaller footprint, while a string might be easier to read.

Thank you for these enlightening remarks.
So if keeping for now with the only rea, the example for an unknown message type could become :
"unknownMessage: unknown message type 'StatusReq'"

Right. It's a bit of a hack to encode stuff into the reason string, and I would generally discourage it, but if you don't want to wait for the core spec to support a reasonCode, it's a possibility.

After some discussions on our side, people think it would be better to have an integer value for a new "reaCode".
This results in a very compact value, well suited to computer use (when some values (or range of values) have to been tested), and for humans the existing "code" fileds allows to have a direct and complete easy-to-understand description.
Numeric values should be classified according to different ranges of values corresponding to meanings,
and with a numeric value, it will be possible to add new values without having to modify a long list of enums strings.
With ranges values principle, even if not knowing exact cause, we can know the global meaning.
We have an example with the http errors code list : https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

I seems we agree it's best to add new reaCode enum attribute.


[SP-5863] Backport of PDI-18322 - KTR with MDI fails if executed on D…

…I/slave and optional target transformation specified (9.1 Suite)
cherry-pick of be2b5d0ac5e0595c583db3bcae3141e2d332c127 (form PR: https://github.com/pentaho/pentaho-kettle/pull/7847)
@bcostahitachivantara @smmribeiro

:white_check_mark: Build finished in 2m 43s
Build command:
mvn clean verify -B -e -Daudit -amd -pl plugins/meta-inject

:ok_hand: All tests passed!
Tests run: 45, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message