YARN-6667. Handle containerId duplicate without failing the heartbeat in Federation Interceptor.

JIRA: YARN-6667. Handle containerId duplicate without failing the heartbeat in Federation Interceptor.
From the actual situation, the probability of this happening is very low.
It can only be caused by the master-slave fail-hover of YARN and the wrong Epoch parameter configuration.
We will try to be compatible with this situation and let the Application run as much as possible, using the following measures:

Select a node whose heartbeat does not time out for allocation, and at the same time require the node to be in the RUNNING state.
If the heartbeat of both RMs does not time out, and both are in the RUNNING state, select the previously allocated RM for Container processing.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 36s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m 30s

trunk passed

+1 :green_heart:
compile
1m 37s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 36s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 48s

trunk passed

+1 :green_heart:
mvnsite
0m 56s

trunk passed

+1 :green_heart:
javadoc
0m 56s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 51s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 43s

trunk passed

+1 :green_heart:
shadedclient
21m  8s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 42s

the patch passed

+1 :green_heart:
compile
1m 29s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 29s

the patch passed

+1 :green_heart:
compile
1m 20s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 20s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 28s
/results-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.txt
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager: The patch generated 2 new + 0 unchanged - 0 fixed = 2 total (was 0)

+1 :green_heart:
mvnsite
0m 42s

the patch passed

+1 :green_heart:
javadoc
0m 35s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 35s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 34s

the patch passed

+1 :green_heart:
shadedclient
21m 15s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 58s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 40s

The patch does not generate ASF License warnings.

122m 37s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 9ac942544aec 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 27cb24fde3702f641ee3d9cd6c58c14526396342

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

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

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 39s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m  0s

trunk passed

+1 :green_heart:
compile
1m 39s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 40s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 49s

trunk passed

+1 :green_heart:
mvnsite
0m 58s

trunk passed

+1 :green_heart:
javadoc
0m 57s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 51s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 52s

trunk passed

+1 :green_heart:
shadedclient
21m 59s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 46s

the patch passed

+1 :green_heart:
compile
1m 41s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 41s

the patch passed

+1 :green_heart:
compile
1m 33s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 33s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 31s
/results-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.txt
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager: The patch generated 2 new + 0 unchanged - 0 fixed = 2 total (was 0)

+1 :green_heart:
mvnsite
0m 45s

the patch passed

+1 :green_heart:
javadoc
0m 38s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 37s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 44s

the patch passed

+1 :green_heart:
shadedclient
21m  6s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 52s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 48s

The patch does not generate ASF License warnings.

124m 27s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 3fd67a96ffda 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / fe48d3fac4fcb6d6b6d148ac15d2a2372ea6d812

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

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

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 49s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m 51s

trunk passed

+1 :green_heart:
compile
1m 44s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 34s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 52s

trunk passed

+1 :green_heart:
mvnsite
1m  3s

trunk passed

+1 :green_heart:
javadoc
1m  4s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 46s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 43s

trunk passed

+1 :green_heart:
shadedclient
21m 15s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 40s

the patch passed

+1 :green_heart:
compile
1m 31s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 31s

the patch passed

+1 :green_heart:
compile
1m 25s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 25s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 32s
/results-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.txt
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager: The patch generated 2 new + 0 unchanged - 0 fixed = 2 total (was 0)

+1 :green_heart:
mvnsite
0m 47s

the patch passed

+1 :green_heart:
javadoc
0m 36s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 34s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 33s

the patch passed

+1 :green_heart:
shadedclient
20m 43s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 56s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 43s

The patch does not generate ASF License warnings.

123m  7s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux eb8e29343e7c 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / fe48d3fac4fcb6d6b6d148ac15d2a2372ea6d812

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

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

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m 28s

trunk passed

+1 :green_heart:
compile
1m 40s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 36s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 48s

trunk passed

+1 :green_heart:
mvnsite
1m  3s

trunk passed

+1 :green_heart:
javadoc
1m  4s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 45s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 51s

trunk passed

+1 :green_heart:
shadedclient
21m  6s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 40s

the patch passed

+1 :green_heart:
compile
1m 27s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 27s

the patch passed

+1 :green_heart:
compile
1m 20s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 20s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 29s

the patch passed

+1 :green_heart:
mvnsite
0m 46s

the patch passed

+1 :green_heart:
javadoc
0m 39s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 32s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 28s

the patch passed

+1 :green_heart:
shadedclient
20m 36s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 53s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 44s

The patch does not generate ASF License warnings.

121m 58s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux efb97872a5ae 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 979a84ef8df9020419d9d07c210127e3f70ad236

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

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

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 34s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m 13s

trunk passed

+1 :green_heart:
compile
1m 37s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 38s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 50s

trunk passed

+1 :green_heart:
mvnsite
0m 56s

trunk passed

+1 :green_heart:
javadoc
0m 55s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 44s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 43s

trunk passed

+1 :green_heart:
shadedclient
20m 56s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 41s

the patch passed

+1 :green_heart:
compile
1m 26s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 26s

the patch passed

+1 :green_heart:
compile
1m 23s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 23s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 28s

the patch passed

+1 :green_heart:
mvnsite
0m 46s

the patch passed

+1 :green_heart:
javadoc
0m 39s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 32s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 29s

the patch passed

+1 :green_heart:
shadedclient
20m 27s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 53s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 42s

The patch does not generate ASF License warnings.

121m 15s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 22ffe7e5a131 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / a774a724ceeda2ee5b2fc4fe75f3bcfe12eabb1a

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

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

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

@goiri Can you help review the code? Thank you very much!

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m 46s

trunk passed

+1 :green_heart:
compile
1m 45s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 37s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 46s

trunk passed

+1 :green_heart:
mvnsite
0m 57s

trunk passed

+1 :green_heart:
javadoc
0m 54s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 41s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 53s

trunk passed

+1 :green_heart:
shadedclient
21m 41s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
22m  1s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 39s

the patch passed

+1 :green_heart:
compile
1m 25s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 25s

the patch passed

+1 :green_heart:
compile
1m 24s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 24s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 2 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
checkstyle
0m 28s

the patch passed

+1 :green_heart:
mvnsite
0m 43s

the patch passed

+1 :green_heart:
javadoc
0m 33s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 30s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 30s

the patch passed

+1 :green_heart:
shadedclient
21m  8s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 47s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 42s

The patch does not generate ASF License warnings.

122m 38s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux a8ddd9faf984 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / adeed0988de46d62e740cd483073ebfd7ee339d4

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/6/testReport/

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/6/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 36s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m 47s

trunk passed

+1 :green_heart:
compile
1m 38s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 30s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 44s

trunk passed

+1 :green_heart:
mvnsite
0m 53s

trunk passed

+1 :green_heart:
javadoc
0m 54s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 41s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 44s

trunk passed

+1 :green_heart:
shadedclient
21m 58s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
22m 20s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 38s

the patch passed

+1 :green_heart:
compile
1m 25s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 25s

the patch passed

+1 :green_heart:
compile
1m 21s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 21s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 2 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
checkstyle
0m 28s

the patch passed

+1 :green_heart:
mvnsite
0m 40s

the patch passed

+1 :green_heart:
javadoc
0m 32s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 30s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

-1 :x:
spotbugs
1m 36s
/new-spotbugs-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.html
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

+1 :green_heart:
shadedclient
22m 49s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 58s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 43s

The patch does not generate ASF License warnings.

124m 34s

Reason
Tests

SpotBugs
module:hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Exception is caught when Exception is not thrown in org.apache.hadoop.yarn.server.nodemanager.amrmproxy.FederationInterceptor.cacheAllocatedContainers(List, SubClusterId)  At FederationInterceptor.java:is not thrown in org.apache.hadoop.yarn.server.nodemanager.amrmproxy.FederationInterceptor.cacheAllocatedContainers(List, SubClusterId)  At FederationInterceptor.java:[line 1537]

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux d8e109b7bfee 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 55c9f807a2d777f907b4d3a5a0e95e96f7fa6995

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/7/testReport/

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/7/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
37m 38s

trunk passed

+1 :green_heart:
compile
1m 40s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 32s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 57s

trunk passed

+1 :green_heart:
mvnsite
0m 56s

trunk passed

+1 :green_heart:
javadoc
1m  3s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 50s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 44s

trunk passed

+1 :green_heart:
shadedclient
21m  1s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
21m 24s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 41s

the patch passed

+1 :green_heart:
compile
1m 26s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 26s

the patch passed

+1 :green_heart:
compile
1m 24s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 24s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 33s

the patch passed

+1 :green_heart:
mvnsite
0m 41s

the patch passed

+1 :green_heart:
javadoc
0m 35s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 33s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 33s

the patch passed

+1 :green_heart:
shadedclient
20m 39s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
24m 10s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 41s

The patch does not generate ASF License warnings.

121m 37s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 7241a7730551 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 72bd079b22720f1ab29c168a9f8b752d95ff74cf

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/8/testReport/

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/8/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

@goiri Please help to review the code again, Thank you very much!

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 38s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m 32s

trunk passed

+1 :green_heart:
compile
1m 43s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
1m 32s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 48s

trunk passed

+1 :green_heart:
mvnsite
1m  2s

trunk passed

+1 :green_heart:
javadoc
1m  2s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 44s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 52s

trunk passed

+1 :green_heart:
shadedclient
21m 15s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
21m 40s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 42s

the patch passed

+1 :green_heart:
compile
1m 27s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
1m 27s

the patch passed

+1 :green_heart:
compile
1m 21s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 21s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 32s

the patch passed

+1 :green_heart:
mvnsite
0m 44s

the patch passed

+1 :green_heart:
javadoc
0m 36s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 33s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 28s

the patch passed

+1 :green_heart:
shadedclient
20m 37s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
24m  1s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 43s

The patch does not generate ASF License warnings.

122m 12s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 980b2cd3c46d 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 554719b7b2c672abcb099a589b288861b2e9de31

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/9/testReport/

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/9/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

@goiri Please help to review the code again, Thank you very much!

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
16m 13s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  1s

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.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m  3s

trunk passed

+1 :green_heart:
compile
1m 44s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
1m 34s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 48s

trunk passed

+1 :green_heart:
mvnsite
0m 56s

trunk passed

+1 :green_heart:
javadoc
0m 57s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
0m 53s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 45s

trunk passed

+1 :green_heart:
shadedclient
21m  1s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
21m 24s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 42s

the patch passed

+1 :green_heart:
compile
1m 25s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
1m 25s

the patch passed

+1 :green_heart:
compile
1m 25s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 25s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 29s

the patch passed

+1 :green_heart:
mvnsite
0m 46s

the patch passed

+1 :green_heart:
javadoc
0m 36s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
0m 33s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 36s

the patch passed

+1 :green_heart:
shadedclient
20m 37s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 57s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 43s

The patch does not generate ASF License warnings.

138m 18s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux f017c225cfb2 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 6143a7e3fb5a4c4d19fd7382247100362fc06b21

Default Java
Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/10/testReport/

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

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4810/10/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.


Fix flake

To maintain the testing system easily, I suggest using the Yaml file as the primary configuration content input. The nixos.vast.settings could be an extra setting needed to generate in Nix. Also, we already have detailed comments in configu.vast.example.yaml. There is no reason to write the vast.yaml to Nix totally.
Most importantly,  I will re-generate all of the YAML files to modular and structured files for different testing roles via cheap lang. So,  the mkMerge could be a valuable option for merging the several YAML files in the final vast.yaml.
:memo: Checklist

[ ] All user-facing changes have changelog entries.
[ ] The changes are reflected on docs.tenzir.com/vast, if necessary.
[ ] The PR description contains instructions for the reviewer, if necessary.

:dart: Review Instructions

DONE: qemu-microVM

Check command nix develop github:gtrunsec/lambda-micro-vm-hunting-lab -c vm-lab bridge

Error: nixosMakeTest

Check command nix build ./\#vast-vm-systemd --no-link --print-build-logs

traps: vast[974] trap invalid opcode ip:7f3a91f56978 sp:7fff882e9970 e
rror:0 in libvast.so.2048.0[7f3a91e6d000+808000]

DONE Fixed src ignore rules.

gitignore to nix-filter fun.

DONE  supporting both attrs of settings and native yaml config file

DONE adding nixosVM-tests for systems service.

DONE adding integration of broker|pcap support in nixosModule.

DONE enabling hydra jobs in the flake.
For local hydra service CI checking

Up to now, this PR is still a draft. @tobim if you have time you can feel free to cherry-pick for merging. I tried my best to make some ideas about your changes.

Yeh, the static build works well now. But, I have no idea, how to build the internal plugins without static-build.

we still have two problems in our testing for the Non-static build vast Package.

Qemu:

traps: vast[974] trap invalid opcode ip:7f3a91f56978 sp:7fff882e9970 e
rror:0 in libvast.so.2048.0[7f3a91e6d000+808000]

Plugins can not be found.

we still have two problems in our testing for the Non-static build vast Package.
1. Qemu:

traps: vast[974] trap invalid opcode ip:7f3a91f56978 sp:7fff882e9970 e
rror:0 in libvast.so.2048.0[7f3a91e6d000+808000]

The release build is compiled with support for AVX2 instructions. It looks like the VM you are using doesn't have it. You could try using the package vast-ci from the overlay instead.

2. Plugins can not be found.

looks like we need a nixosModules.vast-client instead of putting all settings in nixosModule.vast`. 1ff954e

This is a little surprising, I would expect that plugins: [ "all" ] should work. A vast-import module would make sense anyways because that can run on another host as well and it might also need different systemd service options.

@tobim should we change this such that it merges into your PR?

@GTrunSec I took the liberty to cherry-pick a large chunk of your work into my PR branch. The only thing that is missing is the last commit which I believe should be a separate PR.

Sure, you are right. It should be in a separate PR. Once the https://github.com/GTrunSec/lambda-micro-vm-hunting-lab/tree/main/profiles/tenzir/vast microVMs cluster framework( for doctor) is done, I will open the other PR for that.


Missing Option monolog in config type

Hi,
I tried to use your new Version 4.0.1 for Symfony. But it is not working if I want to use monolog as error_handler.
Symfony: 5.1
Monolog-Bundle: 3.6
Sentry-Symfony: 4.0
I got the Error: Unrecognized option "monolog" under "sentry". Available options are "dsn", "messenger", "options", "register_error_listener".
I think it is related to the "new" schema. There is no entry for the monolog option.
https://github.com/getsentry/sentry-symfony/blob/172a4f283bc6f218db51692189a62796585b693b/src/Resources/config/schema/sentry-1.0.xsd#L10
If I am wrong please do not hesitate to tell me how can I implement the monolog error_handler with Sentry-Symfony version >4.0

Duplicate of #441. Documentation and README need to be updated, sorry about that.

how can I implement the monolog error_handler with Sentry-Symfony version >4.0

You can find some information in the UPGRADE-4.0.md file: basically, you just have to define the Monolog handler as a service and then use it in the monolog config as any other handler you may have


Mention building with the Go tool in README and contributing doc [phab:D149]

Created by schroederc at 2015-03-30 21:26:06:

fromberger accepted this revision at 2015-03-30 21:46:29

schroederc closed via commit 838b6c8cbb938c9089e15fbf25bd7061edfc7ab5 at 2015-03-30 22:01:57


ENH: Read data from an external transform file into the parameter map

Both Configuration::Initialize overloads now add values from an external file, when the specified parameter map has parameter ("Transform" "File"), and a "TransformFileName" parameter, which specifies the external file.
The values are stored into the parameters "ITKTransformParameters", "ITKTransformFixedParameters", and "ITKTransformType".
The value of the "Transform" parameter is then set to the elastix transform type name that corresponds with the "ITKTransformType" value.
TransformBase::ReadFromFile() does retrieve these new parameters and loads their values into the transform object.

Back to draft status: major revision coming soon  😃

Update: included a unit test that tests both ITK .tfm and HDF5 as external transform file, linked to by an elastix TransformParameters text file, respectively:
(Transform "File")
(TransformFileName "ITK-HDF5-Transform.h5")

and
(Transform "File")
(TransformFileName "ITK-Transform.tfm")

For the sake of time, I would like merge this pull request once the CI tests have passed successfully.


[TASK] Deprecate DeclarationBlock::expandBackgroundShorthand

The expandShorthands/createShorthands Functions are deprecated and will be removed without substitution in version 10.0. Expanding and creating the shorthand notation is out of the scope of this library. If you want to include this functionality in your project or build it into a separate package, get the code from the v8.5.1 version of this library.
Helps with fixing #512

Rebased it.

Rebased it.


fix: fix css file or contents missing error in build watch (#3742)

Description

Fix #3742, styles will be incomplete，because styles is initialized in buildStart.
https://github.com/vitejs/vite/blob/5979d0e3b2c071ee15408aa67974af04f7bb1c3d/packages/vite/src/node/plugins/css.ts#L290
In asset.ts, assetHashToFilenameMap initialization in buildStart causes getAssetFilename called in css.ts to return undefined.
https://github.com/vitejs/vite/blob/5979d0e3b2c071ee15408aa67974af04f7bb1c3d/packages/vite/src/node/plugins/css.ts#L314
I add another variable emittedHashesSet to determine whether to emit a file.
Additional context

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

Could you add tests that will fail when your fix is not applied?

Ok, you can read my repo in  #3742  about styles, I will create a new branch to reproduce the problem of returning undefined.

This is repo https://github.com/javastation/vite/tree/bug

clone https://github.com/javastation/vite/tree/bug
run yarn and yarn build-vite
cd ./vite/packages/playground/assets
run yarn watch
make some changes to index.html, you will find undefined in index.*.cssin dist
if you change icons.css, emitFile will trigger multiple times

What I meant was a test in our test-suite, so e.g. a unit test or integration test in one of the playgrounds. This way it will always checked when someone create a PR.
Your reproduction repo will currently only be checked once and then pass away.
So I would like to see tests to prevent e.g. regression in the future.

Ok, I got it wrong before.

I also noticed the html-plugin yesterday, some static assets in html will emit multiple times in build watch, cache collection is necessary, I will also try to do something for the project.


Helm chart support

Describe the problem/challenge you have

Helm chart is a popular way to package kubernetes apps, maybe we can support helm chart to allow some users with chart
experiences to eaily adapt antrea project.
Describe the solution you'd like
Provide helm chart with each release and publish it to officail helm chart repo
Anything else you would like to add?
Besides as an alternative way to distribute antrea, i'm not sure helm chart can provide additional features. Possible enhencement are:

Many commercial/oss container platform product include helm chart support, antrea helm chart can be easier integreted to these platform
Use helm values to customize antrea resources. May be we don't need the configmap-version any more (in helm chart)
Rollback feature support by helm

Other advantages of using Helm charts:

ability to list Antrea on https://artifacthub.io/
ability to set RBAC permissions granularly based on which Antrea features are enabled (if we wanted to do so today, we would need to provide many different combinations of YAML manifests)

Additional advantage:

let cluster administrators customize pod tolerations (especially for antrea-controller)

This issue is not resolved yet, there are still several changes required in order for the Helm chart to be usable by Antrea users.

Antrea Helm chart repo is available at https://charts.antrea.io.
$ helm repo add antrea https://charts.antrea.io/
$ helm search repo --devel --regexp antrea
NAME                  	CHART VERSION	APP VERSION  	DESCRIPTION
antrea/antrea         	1.8.0-alpha.2	1.8.0-alpha.2	Kubernetes networking based on Open vSwitch
antrea/flow-aggregator	1.8.0-alpha.2	1.8.0-alpha.2	Antrea Flow Aggregator
antrea/theia          	0.2.0-alpha.0	0.2.0-alpha.0	Antrea Network Flow Visibility

Helm installation method will be supported starting with Antrea v1.8.0.
At this stage, the only thing left is to update the documentation with this new supported installation method.


Add item parameter to List.addItem function

I am extending the List component to create my own factory of dynamic field types (based on #301). When I am adding an item to the list, I want to add a defined item with a type property so my dispatch function work as expected.

Sorry, I thought it was miking any sense, actually it does.

Thanks, released in https://github.com/gcanti/tcomb-form/releases/tag/v0.9.12


add Selector#toMap()

This is not a good idea because RxJava provides the same toMap():
db.selectFromBook().executeAsObservable()
        .toMap(new Function<Book, String>() {
            @Override
            public String apply(Book book) throws Exception {
                return book.title;
            }
        }).blockingGet();


"Native reviews" don't work well and prevent from using Elm in production

I totally understand the idea of having good native code in official package repository, but for now it just doesn't work.
Most of the issues in this repo are "Native review" issues, the oldest one waits for more than 8 months (!!!) and the newest are waiting for weeks just to get the label that they are indeed related to native reviews. Also, I don't think the review is thorough enough to give any guaranties that the code is really good.
Looking at comments I see that people are giving up and abandon their projects before they have a chance to get through the review. Elm is young and a lot of people are experimenting with it, but they cannot do it if an experiment waits for being reviewed for months. Also, no one will join and improve far from ideal but promising library if it anyway cannot be used easily because it stuck in the review process.
What is worse, review requirement prevents from using Elm in production. Production blocked by the review process is a nightmare. Of course we can use git submodules or something but it isn't any way better than not having package manager at all.
I think we shouldn't prevent the packages from getting into repository by requiring the review. The state of affairs shows clear enough that there are no resources for such an approach.
If you think the situation will get better in future (which I doubt), we can just use some kind of warning within the repository saying that the package is native and haven't reviewed yet. The other way could be to have completely separated experimental repository, but I think this way everyone will just eventually use it and abandon the official one.

I think pretty much everyone agrees with this assessment.
I have written a bit about my upcoming plans here and it is pretty clear that this is probably the most important thing to resolve for Elm to keep growing and becoming useful for more folks.
I want you to know that I think this issue is important and that I am going to be focusing on it primarily as soon as I can. I also want you to know that I work as hard and as quickly as is possible. No one is slouching around here, but to get a good solution that is going to keep Elm healthy takes time.
I am going to be flying back to SF tomorrow and getting 0.16 out the door in the following two days, so I need someone in @elm-lang/packages to continue this discussion in my place.

Thank you for quick response!
And thanks a lot for the great job you all are doing!
I'm currently thinking on extending elm-package functionality, this is what we need anyway to use Elm in commercial projects:

allow to use alternative (private) registries (besides package.elm-lang.org)
allow to get files from private git repositories and possibly from other sources (private registry itself, tarballs hosted somewhere, etc.)
possibly allow to use direct link to some package as a constraint (like npm does)

e.g. "dimsmol/vdom-to-html"<EMAIL_ADDRESS>it will make experimenting and hacking around much easier, but it conflicts with the idea of strictly versioned packages so much, that I'm not sure if it can be done in a reasonable way

make elm-package work in docker (workaround this issue)

While it won't fix an issue with the reviews, it will allow to move further without delay. One can experiment with updated version of elm-package without disrupting anything and without even waiting for changes to become the part of the official distribution.
I want also to mention that there is an issue with current versioning scheme. It doesn't allow to make beta releases available for early adopters while still distinguish them somehow in a constraint. For instance, I can have an agreement that odd version numbers are unstable, but there is no way to make a constraint to choose stable versions only. And there is no way to tag release as beta or something. Not sure how to solve it though.

Thanks :)
I added a note about what is going on in b35c30f so hopefully the root concern is addressed as best as possible without actually making the fixes yet.
Otherwise, again, pretty much all the things you have mentioned are on my personal roadmap for this project. Because Elm has grown a lot since the last time I focused on elm-package so pretty much all the things you have listed have become much more important as users have shifted from hobbyists who wanted to publish any community packages to businesses with private packages. Right now, companies are doing work arounds for this. I bet @rtfeldman can describe what they are doing at NoRedInk.
Point is, all the things you say are things that are now quite important! I am going to close this because I don't want to track work on these topics in this thread. Gotta keep things focused and close aggressively or hard-to-follow issues will bury the clear and actionable ones.
If you are interested in making some contributions, I'd focus on the Docker one. I really have no clue what the deal is there and am not an expert on containerization at all. So that's one where there'd be no toe stepping and you'd probably have a competitive advantage over me :)

Also, I think the idea of allowing links to git repos would address the concern about beta releases. If people want to test early, have them point at a tag. I don't think beta releases make total sense because you may do an experimental version that you want to show people that is MAJOR, but then decide it was all dumb and end up with a MINOR release.

Strongly agree about git repos being the best solution for beta releases.
I think "arbitrary Git URL" covers every missing case except "relative local file path" (e.g. if you have a project with a tests/elm-package.json that wants to bring in the root project while adding test-specific dependencies like elm-test and elm-check, being able to say something like "../": "1.0.0 <= v < 2.0.0" instead of manually duplicating the root project's dependency list inside the tests' elm-package.json like we do now).

I don't actually have a nice list of all these ideas, though I'm sure they have come up in various forms before.
Would you @dimsmol be up for writing up your ideas and @rtfeldman's in as clear a way as possible in a gist? I am imagining a brief description of each proposed thing in a gist in the same sort of brief format as https://github.com/elm-lang/elm-make/issues/59 with minimal examples.
If you can, please share it here, and I'll add it to https://github.com/elm-lang/elm-make/issues/59 in the "issue updates" section that is for tracking this sort of stuff. It's likely it'll all happen in one big batch.

extended dependency syntax
I agree that allowing links to git repos covers concern about beta releases.
Here I want to discuss how we want to specify such "link to something" dependencies (in future they can be not only links to git, but also links to tarballs, local dirs, etc.). There are at least two possible options here:

Use the link as a constraint, like this: "user/lib": "git://github.com/user/lib.git#commitish" (this is the way npm works)
Use the link as a name, like this: "git://github.com/user/lib.git#commitish": "1.0.0 <= v < 1.1.0"

While the second approach is something people are already trying to use, I think it isn't what we really want. There are some reasons against it:

It's very logical to use a link as a constraint, because it is actually a constraint saying "I want exactly the version I'm referring to"
Link destination is already an exact version, so having additional constraint on the version has no benefits besides of ability to double-check author's intentions what effectively means author should specify her intentions twice, which is tedious
We can have other dependencies in the graph referring the same library and if they will have different name we won't be able to detect versions conflict

The third reason is the most important one. Here is an example. Let's assume we have the package x/main which depends on libraries y/a and z/b, but y/a also depends on z/b. The author of x/main wants to experiment with beta version of z/b, so she updates the dependency to refer git://github.com/z/b.git#beta. But she is not aware that y/a also has a dependency on z/b, e.g. "z/b": "1.0.0 <= v < 1.1.0".
Deps graph may look like this:
x/main ---> y/a ---> z/b
     \---------------^

If x/main will have updated dependency as "z/b": "git://github.com/z/b.git#beta" we will immediately find the conflict, because there is no guaranty thatgit://github.com/z/b.git#beta required by x/main is compatible with 1.0.0 <= v < 1.1.0 required by y/b.
But if x/main's updated dependency will be "git://github.com/z/b.git#beta": "1.0.0 <= v < 1.1.0" there is no guaranty that it has any relation to z/b referred in y/a and we cannot find they are different versions of the same lib.
So, I propose to go the way npm goes and stick to the first option, namely "user/lib": "git://github.com/user/lib.git#commitish". Maybe we can invent some other approach, but the second option doesn't look good anyway.
dependency conflicts
In the case described above, we have the conflict. But we can fork y/a, update it's deps to use "z/b": "git://github.com/z/b.git#beta" and use github link for forked version of y/a in x/main. This will require a lot of actions, but anyway we can do it and then experiment with beta of z/b as we need.
But the deps graph can be more complicated. There can be a number of libraries depending on z/b or we can have something sitting very deep into dependency graph depending on z/b. In this case we will need to fork and patch a lot of libraries and it becomes unreasonable. We cannot ask all the authors of those libs to do something for us because we aren't even sure yet that beta version of z/b is what we really need.
Example of complicated graph:
x/main ---> y/a1 ---> y/a2 ---> y/a3 ---> z/b
     |----> z/k1 -------------------------^
     |----> z/k2 -------------------------|
     |----> z/k3 -------------------------|
     \------------------------------------/

In this graph we need to patch all the packages y/a1 - y/a3 and z/k1 - z/k3 to have a chance to try git://github.com/z/b.git#beta with x/main.
How does npm deal with this? With npm there will be no conflict at all, x/main can use one version of z/b and the other libs can use other versions at the same time. This is a way how npm works, but it causes very bad problems, so we cannot use it.
Instead, I propose to add an ability to force top-level constraints over all the constraints dependency packages may have. For instance, having "z/b": "force git://github.com/z/b.git#beta" could make all the dependency packages use git://github.com/z/b.git#beta regardless of their own constraints for z/b.
While this is a potentially dangerous feature, it can be very helpful for experiments and can be a savior if you need to adopt an urgent security fix or quickly workaround a bug in someone's package dependencies. Of course elm-package should output all kinds of warnings when dealing with this option and it would be better to prohibit packages with forced deps from getting into official repository.
caches and downloaded packages dirs
Currently, downloaded packages are saved in the package cache and elm-stuff directory under the paths like user/name/version. But what should be the path for a github link?
Surely it cannot be user/name/version because the package can still have no proper version assigned (as @evancz said you may think it will be major change but end up with minor improvement or vice versa). So we cannot guess the version of the beta package without potentially clashing with some future release version.
npm solves similar problem by translating links into directory names, so git://github.com/user/lib.git becomes something like git_github.com!user/lib (see details).
Going this way we could have path like user/lib/translated_url. Is this a good way to go?
getting package constraints
Currently elm-package gets deps for the package from the store, checks everything and only then starts to download files. For github links there will be no entry in the store, so the only way to get package deps is to download it's elm-package.json and parse it.
For git, however, there can be a problem with downloading a single file from a repository. For instance, there is no way to download a single file from github using git+ssh protocol (which is preferred because it allows to use ssh certificates transparently). The same problem is present for tarballs as well.
Will it be ok to download the whole package just to get it's dependencies list and probably fail with conflict right after that? I think for certain situations we just haven't any other way, but maybe there can be some other ideas?
dev dependencies
@rtfeldman, according to your proposal to use "../": "1.0.0 <= v < 2.0.0" dependencies for tests subfolder to indicate it should inherit all the dependencies of parent folder. I think it would be better to have syntax like "inherit": "../" for this, because there is no reason to have version constraint here (as explained above) and inherit keyword will more clearly indicate what's going on.
But it can be even better to adopt npm's idea of dev dependencies. Those are dependencies that are meant to be installed in dev environment which may need additional libs for tests, build process or something. This way you will just add everything you need for tests into dev dependencies of the main elm-package.json.
What do you think?

I think this discussion should move to its own issue. :smile:

let's continue here


Wrong Bootstrapping result after addition.

I write some simple code as below:
params := tfhe.ParamsUint4.Compile()
enc := tfhe.NewEncrypter(params)
defer enc.Free()
evalKey := enc.GenEvaluationKeyParallel()
eval := tfhe.NewEvaluater(params, evalKey)
defer eval.Free()
a := enc.EncryptLWE(13)
b := enc.EncryptLWE(7)
c := eval.AddLWE(a, b)
fmt.Println(enc.DecryptLWE(c))
c = eval.Bootstrap(c)
fmt.Println(enc.DecryptLWE(c))

The output is 4 12.
When the addition result c is larger than the modulus 16, it seems the bootstrap result is always 16-c. May I ask if this is a bug or an inherent result?

Hi, thanks for writing this issue.
Unfortunately, this is an inherent result. You can observe the same behavior in TFHE-rs too.
The reason for this is that Functional Bootstrapping in TFHE is negacyclic. To circumvent this, messages are usually encoded with a bit of padding. However, in this example, the added result is larger than the message modulus, hence overflowing occurs and the padding bit gets sets to 1. This negates the evaluating function, so f(x) = x becomes f(x) = -x.
Solution to this problem would require implementing FDFB(Full Domain Functional Bootstrapping), which is a part of ongoing research.
Hope this helps!

Thank you very much for your response.
I carefully reviewed your code. Taking Uint4 as an example, it seems that you created a region for Uint5 and implemented modulo 32 additive homomorphism on LWE ciphertexts. During encryption and decryption, you reduce these modulo 32 numbers to Uint4. On the other hand, you uniformly adopted Programmable Bootstrapping, where simple Bootstrapping is treated as an example of {f(x) = x}.
This is a very clever implementation approach. In the Uint5 space, due to the negacyclic property, only 0 to 15 are actually usable. Therefore, you explicitly define the plaintext space as Uint4 to avoid potential errors caused by LUT.
However, I encountered some difficulties when trying to build certain algorithms using your code.
Scenario 1: I tried to construct an algorithm. In the Z16 space, it uses the following NLUT:
0 -> 3
1 -> 2
2 -> 6
3 -> 12
4 -> 10
5 -> 0
6 -> 1
7 -> 11
LUT[8+i] = 16 - LUT[i]
In your design, this process occurs on ParamsUint3. However, due to the properties of modulo 8, the mapping above is reduced to:
0 -> 3
1 -> 2
2 -> 6
3 -> 4
4 -> 6
5 -> 0
6 -> 1
7 -> 5
LUT[8, ..., 15] is the same as before.
At this point, unless ParamsUint5 is used and Bootstrapping is performed after each addition to limit the size of the plaintext, we cannot achieve the above operations in Z16.
Scenario 2: We have arrays A and B of length n, with all elements in Z16. We want to determine for how many i, A[i] = B[i]. This is feasible on ParamsUint4 because A[i], B[i] ∈ [0, 15], A[i] - B[i] ∈ [-15, 15], and only one Programmable Bootstrapping is needed to determine their equality. Subsequently, a simple accumulation is sufficient.
However, if A[i], B[i] undergo previous operations or have undergone Programmable Bootstrapping beforehand, due to the negacyclic property, the comparison mentioned above becomes infeasible on ParamsUint4(A[i] - B[i] may be 16). To solve this problem, we would need to use ParamsUint5 or even ParamsUint6, control the plaintext size through frequent Bootstrapping, and thus complete the computation. This undoubtedly introduces significant overhead.
The commonality in both scenarios is that as the computational circuit grows, we must increase the scale of the plaintext field and perform frequent Bootstrapping to complete the computation. Therefore, I would like to inquire if you have plans to implement multiplication on LWE ciphertext domains as well as naive Bootstrapping (i.e., ParamsUint3 -> Z16, f(x) = x).
Thank you for reading this issue, and look forward to your response.

Thanks for your detailed comment!
In scenario 1, I believe it is possible using GenLookUpTableFullInPlace and LWEDecodeCustom. GenLookUpTableFullInPlace allows to encode f(msg) -> plaintext, rather than f(msg) -> msg, and LWEDecodeCustom allows you to decode LWE plaintext with user supplied modulus and delta.
Here is an example:
params := tfhe.ParamsUint3.Compile()
enc := tfhe.NewEncrypter(params)
defer enc.Free()

eval := tfhe.NewEvaluater(params, enc.GenEvaluationKeyParallel())
defer eval.Free()

// Part of your LUT
f := func(x int) uint64 {
	if x == 7 {
		// You have to scale plaintext manually,
		// Since this function maps message to full encoded plaintext
		return 12 << params.DeltaLog()
	}
	return 0
}

lut := tfhe.NewLookUpTable(params)
eval.GenLookUpTableFullInPlace(f, lut)

ct := enc.EncryptLWE(7)
eval.BootstrapLUTAssign(lut, ct)

// Okay, perhaps I named this method wrong,
// but what this does is decrypt LWE ciphertext to LWE plaintext (undecoded).
ptOut := enc.DecryptLWEPlaintext(ct)
msgOut := enc.DecodeLWECustom(ptOut, 16, params.Delta()) // Force modulus to be 16
fmt.Println(msgOut)

This should output 12, as desired.
Scenario 2 is similar to Scenario 1, but for general, non-negacyclic LUT. This is called Full Domain Functional Bootstrapping(FDFB), and is generally really hard. There are few approaches developed, such as CLOT21, YXS+21. However, most of them requires two bootstrappings, which is computationally similar or even slower than just using larger parameters; CLOT21 is slightly faster than that, but parameter selection is not straightforward IIRC.
What you can do is to keyswitch to larger parameter, but I'm not sure it's better than using a larger parameter from the start.
Hope this helps!


Update Logo/Theme

I am not a visual artist. I used a logo generator. I think at some point in the near future Solid needs to get a real logo. Now I'm not necessarily inviting an open free for all as I don't want to waste anyone's time but I could definitely benefit from some help.

Just a font logo: https://fonts.google.com/specimen/Major+Mono+Display?selection.family=Major+Mono+Display

@atfzl It's arguably less cheesy than what I have right now. But I think I want to do something where I can get an icon out of it. This is probably going to take some custom work. It's another S library though so have to differentiate from like Svelte. Thanks for taking the time to try an idea.

Besides I'd have to give up terrible snake puns.
"The Reactive UI library that Scales"
Sorry that's really bad. It's just been in my head ever since I wrote the Cost of UI Component article.

Something like this, maybe?

I did it keeping the idea of "solid" in mind, and trying to preserve the colors you choose for your current logo. I created every letter from scratch and the minimum size is 80x16 😄

@lukeshiru Hey awesome work.. I played in a band for years that was called Solid and we had so many logos for posters, shirts, albums etc, and when I saw it elements reminded me of few of the ideas we'd played with at certain times.
I think this has helped me understand better what I'm looking for. It's really the Icon that I'm looking for as I think the rest of the logo should be easily readible. Some strong san serif font etc. I think the rest fills in easier once the Icons in place.
So what I really like here is that the S as an Icon is unique. Not that I don't appreciate how every letter looks carved out of a solid cube, it carries the weight well. But more importantly, that S you aren't going to confuse with Svelte. And that's what I think is important. To have something that stands out again the other Library Icons.
Given that clarity I want to see if that opens up some more ideas.

I plopped these together just now. I'm quite a fan of the suckless project logotypes. Could be made more distinctive for a good icon.
![solid][https://i.imgur.com/8WAXzEy.png]

IMHO the current logo is nice and gets the point across.
✔ Deceptive
✔ Simple

As @danbrianwhite said, it gets the job done whilst looking good.

Thanks. I didn't put zero thought into. I just always feel like this is a weakness of mine.  Although that sense is telling me the current stuff is undeniably a bit cheesy.
Honestly I figured I'd be building the website by now(which is why I was looking at a facelift) but there has been a lot of really interesting dev stuff around Suspense and SSR keeping me busy, as I creep through building the Real World Demo. So I'm in no rush let's keep this open.

Thanks for the kind comments. Sorry for the delay since the last upload, we got busier with a delivery than expected. Here are some more concepts. They are pretty all over the place, just throwing ideas at the wall:
Concept 4 - Really clean and very concise. I actually like this concept more than the others.

Concept 5 - Something a bit more basic but something about the 3D is interesting. Haven't seen that done too much.

Concept 6 - Experimentation with some shapes/geometry.

Concept 7 - Another great contender. Simple, elegant and still looks interesting.

Wow you outdid yourself again. All of these are way better than anything I could do. I think these are much better logos than many businesses have.
I really like the font face and stance of concept 4. It's unique and stands out. Something about the 3d on the S keeps throwing me off a bit. Something about the positioning. Can't place it but otherwise I think it's the best of the bunch.  I also really like 7 and the flat design, and although it is more similar to other logos I've seen in the past, but that would be my only comment. Although if not single other submission came in I could easily work with that. And that might just be the case because these are all really impressive.

Glad to hear this new batch provided more viable options. I think concept 4 is more unique and while strange visually it has a memorable element to it. Definitely much different than other OSS projects. I’d encourage you to go with it but concept 7 works well too.
Of course I continue to encourage the community to take these ideas and iterate them! These are conceptual and if they give way to something stronger then...amazing :-)
If you plan to launch a new dedicated website for solid let me know. I’d be happy to donate some design and development time.

i vote for concept 3

hey ryan, why the snake in the current solid logo?  just curious to see if you had some thoughts about solid you'd like share to collectively think about what should the logo say about the framework.

@yuens1002 I had the exact same question.
I wonder if it is an allusion to Solid Snake from Metal Gear.

@bikeshedder haha didn't think about that. That's a really funny reference if it's true.

@yuens1002 and @bikeshedder
I'm going to attribute this to logo generator. I didn't have any particular attachment to the snake.
Truthfully I was just going through a bunch of options and wanted something that worked with the "S". There were a lot of 3D block sort of things that just looked to basic and uninteresting. I was definitely cognizant of Solid Snake of Metal Gear but I was just trying to to think of something I could make a tagline out of as a well. I particularly liked the phrase "deceptively simple" which worked with the snake and had some nice alliteration even though hard to say if it's flattering or not. So when I saw the snake, I pieced all of those things together as good enough to move forward with.
Since then I may have grown more fond of the snake but it is simply because although historically seen as symbol of evil, I think of it more playfully. Solid as a framework while on the surface is very familiar looking. But I'm definitely trying to pull people over to the dark side so to speak. It presents this comfortable API but under the hood it goes against conventional knowledge, eschewing the use of Virtual DOM, minimizing the mechanical role of Components, using JSX templating with a Reactive library.. and so on. If you look at articles/talks from any of the major libraries, React, Vue, Svelte, etc.. many of these things are thought as not possible or not good ideas. But Solid does it in a way that you don't even realize you're already past that point. You've already drank the Kool-Aid. For what I see as a disruptive change to how UI libraries work, it is deceptively subtle.

Well said Ryan, will share your thoughts with someone I know who may be
able to help us.
On Fri, Mar 13, 2020, 3:24 PM Ryan Carniato<EMAIL_ADDRESS>wrote:

@yuens1002 https://github.com/yuens1002 and @bikeshedder
https://github.com/bikeshedder
I'm going to attribute this to logo generator. I didn't have any
particular attachment to the snake.
Truthfully I was just going through a bunch of options and wanted
something that worked with the "S". There were a lot of 3D block sort of
things that just looked to basic and uninteresting. I was definitely
cognizant of Solid Snake of Metal Gear but I was just trying to to think of
something I could make a tagline out of as a well. I particularly liked the
phrase "deceptively simple" which worked with the snake and had some nice
alliteration even though hard to say if it's flattering or not. So when I
saw the snake, I pieced all of those things together as good enough to move
forward with.
Since then I may have grown more fond of the snake but it is simply
because although historically seen as symbol of evil, I think of it more
playfully. Solid as a framework while on the surface is very familiar
looking. But I'm definitely trying to pull people over to the dark side so
to speak. It presents this comfortable API but under the hood it goes
against conventional knowledge, eschewing the use of Virtual DOM,
minimizing the mechanical role of Components, using JSX templating with a
Reactive library.. and so on. If you look at articles/talks from any of the
major libraries, React, Vue, Svelte, etc.. many of these things are thought
as not possible or not good ideas. But Solid does it in a way that you
don't even realize you're already past that point. You've already drank the
Kool-Aid. For what I see as a disruptive change to how UI libraries work,
it is deceptively subtle.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ryansolid/solid/issues/101#issuecomment-598877547,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABSKP665UQTWUCVOVGSHGWDRHKCAHANCNFSM4JNM5X3Q
.

It's funny how the logo is now the most commented issue regarding solid-js.

@s0kil still a young community. Ryan is busy factoring a first official release while the rest of else are helping him bring the brand to life. The brand should reflect the goals of the project but also be approachable. It has to look and feel as professional as other OSS projects (IMO). Here are some additional concepts:
Concept 8A - Playing with the combination of circle and S.

Concept 8B - Similar to above although slight variation with colouring of the circle.

Concept 8C - Once again a similar concept however with some inner gradient to help emphasize the S.

Concept 9A - Simple and slightly more corporate feel.

Concept 9B - Similar variation with a smaller s. Not too much of a fan of this but might trigger some ideas for others.

@ddibiase Concept 8A looks really good.

It would be interesting for a logo to represent "solid" as in firm and stable in shape; not liquid or fluid.

@s0kil I generally agree. I'm trying to move away from the snake-concept. While a Metal Gear fan not sure if it plays well with how this community should be portrayed. I'm personally still loving Concept 4. My designer and I put together a few more variations.
The 3D is very different but together they look like a solid form, kind of like gears fitting together. Of course it's super abstract but I love how they emphasise the "S".
Concept 4A - Originally concept 4

Concept 4B - Different angling or slightly better balance in case the above angle looks awkward for anyone.

Concept 4C - Different angle and thickness.

Concept 4D -  Stacked and aligned properly it forms an S and looks like a solid figure/body.

Concept 4E - Completely different angling.

Sorry to re-hash this concept. There's something that I personally love about it. If it doesn't work though, oh well :-p just wanted to give it one final try to see if it spikes any interest in the community.

I'm really loving the way 4A and 4E are looking, super unique and memorable. I think it's important to really stand out above all the generic flat logos given how unique of a library Solid is.

Thanks for the feedback @rytone. That was the goal. It would be really great if we got more feedback (positive or negative) regarding these directions. Please voice your opinion!

Here's a completely flat version of the logo for everyone to give feedback on.

Although admittedly as I ask around and get feedback I have more people suggesting the following work very well for us. I'm consolidating/renaming them as official contenders.
We also haven't received much other feedback. Once again would love to see more coming in from the community. Please help by contributing constructive criticism. =)
Concept I

Concept II

This thread is nearing end of life. With the work I'm doing nearly done, the last task for 1.0 is the website, so I intend to use what I have available. To that end, if anyone is still holding out ideas, or has feedback on the proposed ones I could really use your help. Any feedback/comment could help a lot. I'm going to have to draw a line pretty quick here. If I can have everyone's contribution by Thursday, March 26th. Thanks again for helping through this process.

Hey, I've been asking my web developer colleague as well as some project manager and they all seemed to be attracted to the Concept I logo from the latest post.
They don't know much about the library and they mainly picked what standed out the most. I for myself also really like this one. There's a bold aspect that kind of say "Hey I'm here to stay" if that makes any sense :p

Thank you guys for all your feedback. It was really helpful. Especially thanks to @ddibiase for creating the logo. We've settled on Concept 4a. I think it does have this bold characteristic that makes it standout. The website will be coming soon.


How do I test if a combination of keys is in my multi_key_dict

Hi,
how do I test if a combination of keys is in my multi_key_dict
e.g:
matrix = multi_key_dict()
matrix['1', '2'] = []

#my try ???

print(('1','2') in matrix)
print(matrix.has_key((key1,key2)))

How do I do this ? Or is this possible ?
Thanks

Hi, sure, that would be useful, let me have a look.


Cannot import pyzmq in python 2.6 on Mac OS X 10.6

Installed using MacPorts or Pip, neither works.
Trackback as below:

\>>> import zmq
Traceback (most recent call last):
  File "", line 1, in
  File "/opt/local/Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages/zmq/__init__.py", line 38, in
    from zmq import core, devices
  File "/opt/local/Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages/zmq/core/__init__.py", line 26, in
    from zmq.core import (constants, error, message, context,
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages/zmq/core/poll.so, 2): Symbol not found: __PyByteArray_empty_string
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages/zmq/core/poll.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages/zmq/core/poll.so

Hm, I don't quite know how this would happen, since my build of pyzmq doesn't appear to ever reference PyByteArray_empty_string.  Googling around seems to suggest it might be a MacPorts issue, but it's not clear what the solution might be.

I expect there is something borked in your ports/environment, and it would probably be better to bring this up with the maintainers of either the python26 port or the py26-zmq port.
I just installed python26 and py26-zmq on my machine (up-to-date 10.7.2, not 10.6), which worked fine.  I'll soon close this issue here as 'not to do with pyzmq' unless I hear otherwise.

Closing as stale and not reproducible.


Add click event for the Image component

This PR is a continuation of #1070. The original commits by @moliata have been squashed and rebased onto the latest ucr branch, with changes from me including the addition of a "Clickable" property and updates to the documentation.

@ewpatton do you need me to resolve the conflicts?

@conorshipp Yes, if you can bring this up-to-date with ucr that'd be helpful.

Thanks @conorshipp for pushing this over the finish line and @moliata for the initial implementation.


Length of the blob received by "select"

Hi Roland,
First of all, thank you so much for writing and maintaining such an awesome library!
I have a question about the mechanism of receiving objects with dynamic length. Specifically, let's say, the blobs. Sending a std::vector<uint8> to a key foo is straightforward. But as I tried to read the same content back via select, there were two seemingly equivalent ways, either blob with len, or simply value(). In the test with sqlite3 and pgsql, blob with len is used, rather than value(), Is there any particular reason why this version is preferred?
Best,
Yukun

Hi Yukun,
Thanks for the praise :-)
And thanks for the question, of course. Both variants work just fine. value() returns a copy of the value, though.
Background:
In the early days, I decided to return a default-constructed value if you asked for the value of a NULL result. From today's perspective, that was probably a mistake. Every now and then I am thinking of changing that, but it is hard to do so without breaking everybody.
Cheers,
Roland

Thank you for the timely reply! Now I understand it much better :)


docs: updating createPaymentMethod params

Summary

Motivation

Testing

[x] I tested this manually
[ ] I added automated tests

Documentation
Select one:

[ ] I have added relevant documentation for my changes.
[ ] This PR does not result in any developer-facing changes.

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

can you also change L287 and L288 to:
  paymentMethodType: 'Card',
  paymentMethodData: {
    billingDetails,
  },

you mean in confirmSetupIntent?

will merge once the CLA is signed :)

Done


Drop-in EXP field doesn't add / on android(chrome) and WP(8 and 10)

Update for android we found out it's because of the custom keyboard we are using, we're wondering  if there's a way around this. The keyboard we are using during our test is called sogou, don't know why it's related to it but you can download if from the play store if you want to test it
Update 2 we have invested further and found out that only certain 3rd party we cause this problem, example are sogou and baidu, swiftkey and some other keyboard works just fine. However on WP it's the stock keyboard
Drop-in EXP field doesn't add / on android(chrome) and WP(8 and 10). We have just noticed this problem during our test, It works fine on safari(iOS).
Also for the card no. and exp on both android and WP u can type beyond 16 or 6 digits.

Thank you for the updates. We'll take a look.
We've historically disabled formatting for certain mobile browsers (Android FireFox) and not all keyboards report key events in the same way to the browser.

Thanks a lot !
Do you think switch to hosted fields can avoid this problem or that may also depend on the keyboard.
Also any timeline on 3.0?

Hosted Fields does not currently have input formatting like Drop-in does, although you can specify separate fields for month and year inputs and avoid the mismanagement of the / character.
3.0 is a work in progress, and we don't have a definite ETA at this time.

We've released a beta of our next major version. Though we do not have Drop-in ready for the beta of v3, Hosted Fields now has field formatting.
Here are some links to our official documentation:
Setup for v3
Migrating from v2 to v3
Hosted Fields demo in v3

Closing this now. Re-open if you have more questions.


isfolder fails to detect ordinary files, thus appending is impossible

This might be caused by a Lua change. Not sure. Anyway,  the fix is easy -- add  == 0 to the end of the line:
function isfolder(dir)
  return os.execute('test -d "'..escapepath(dir, '"')..'"') == 0
end

Without this fix, it was impossible to append files to the playlist -- I could only replace them, because the replace action doesn't check folder status.
The interface also displayed the file I was trying to add as if it were an empty directory :)

Did this start to happen recently? I'm still on an old mpv version so os.execute('test -d "'..escapepath(dir, '"')..'"') is still returning either true or nil so the == 0 will break that. I also noticed some bugs with path joining that would probably be fixed with using the utils.path_join. I think this script is in a dire need of a big rewrite, I'll try to find some time to do it.

Ah, I tend to run trunk version of mpv, so ..
mpv --version
mpv 0.29.0-75-gda1073c247 [redacted copyright notice]
 built on Thu Oct 25 12:51:31 ACDT 2018

Anyway os.execute is part of Lua, unless mpv modified it, so:
aurman -Qi lua |grep Version
Version         : 5.3.5-1

The current Lua documentation asserts that what you say is still true -- so I actually don't understand why my fix worked... Type coercion is the only thing that comes to mind.

Thanks for finding the cause for the issue. Seems like I have Lua52.  I guess the script can check if first or third return value equals 0.


Build from head fails with Bazel 1.1.0 but succeeds with Bazel 0.26.1

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 18.04
TensorFlow installed from (source or binary): source (building source issue)
TensorFlow version: build from head (2.0.0)
Python version: 3.7.3
Installed using virtualenv? pip? conda?: Conda
Bazel version (if compiling from source): 1.1.0 fails while 0.26.1 succeeds
GCC/Compiler version (if compiling from source): 7.4.0
CUDA/cuDNN version: CUDA 10.1, cuDNN 7.6.5
GPU model and memory: Nvidia RTX 2080 Ti

Describe the problem
Building with Bazel 1.1.0 fails with the following message:
ImportError: /home/daniel/.cache/bazel/_bazel_daniel/79db702fc9f94af7d11e11c5d64854d0/execroot/org_tensorflow/bazel-out/host/bin/tensorflow/python/keras/api/create_tensorflow.python_api_1_keras_python_api_gen.runfiles/org_tensorflow/tensorflow/compiler/tf2tensorrt/_wrap_py_utils.so: undefined symbol: _ZN10tensorflowlsERSoRKNS_6StatusE
Note: The failure of target //tensorflow/python/keras/api:create_tensorflow.python_api_1_keras_python_api_gen (with exit code 1) may have been caused by the fact that it is a Python 2 program that was built in the host configuration, which uses Python 3. You can change the host configuration (for the entire build) to instead use Python 2 by setting --host_force_python=PY2.
If this error started occurring in Bazel 0.27 and later, it may be because the Python toolchain now enforces that targets analyzed as PY2 and PY3 run under a Python 2 and Python 3 interpreter, respectively. See https://github.com/bazelbuild/bazel/issues/7899 for more information.
Provide the exact sequence of commands / steps that you executed before running into the problem
git clone https://github.com/tensorflow/tensorflow.git
cd tensorflow
git checkout -b mybranch
./configure
tf_configure.bazelrc.txt
bazel build --explain=verbose_explanations.txt --verbose_explanations --verbose_failures --subcommands=pretty_print --config=opt --config=cuda --config=v2 --cxxopt="-D_GLIBCXX_USE_CXX11_ABI=0" //tensorflow/tools/pip_package:build_pip_package &> log.txt
Any other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.
See ful log.txt (which shows failure with Bazel 1.1.0)
and log2.txt (which shows success with Bazel 0.26.1)
from the following link: Dropbox folder

@dbonner,
Is this still an issue? Please feel free to close the issue if resolved. Thanks!


??

Why is there no chapter 1-5

We got a volunteer who wanted to work on those, so we will in fact be getting them sometime.


Reloading from Checkpoint for training

If I have trained ELMo for 9 epochs, and I train for one more epoch separately, will it reload from the checkpoint?
Will the code support reloading from checkpoints and training from there?

Yes, if you use https://github.com/allenai/bilm-tf/blob/master/bin/restart.py


GET request query params in SSR

Describe the bug
It should return query parameters but it return nothing and won't provide any method to access GET parameters in SSR or server side.
Reproduction
Always
Logs
No response
System Info
Any System

Severity
blocking all usage of SvelteKit
Additional Information
No response

I have no idea what this means. And "Always" is not a valid reproduction.

I guess op is using RequestEvent#params instead of RequestEvent#url.searchParams. I often find complaints like this and they miss the docs.

This issue is not understandable. If you're not going to respect us and our time by following the template, there's no reason to leave this open


[doc/trivial] Fix st-flash manpage read example

SIZE must be specified as hexdecimal number (as per both documentation and implementation), current manpage example unexpectedly reads 0x4096 (16534) bytes instead of 4096 (0x1000).
(actually, 0x prefix is not necessary, number interpreted as hexdecimal anyway, and maybe confusing readers into thinking that number will be interpreted as decimal [without prefix] or octal [with 0 prefix])

Merged into develop branch with commit fa35d5b7ba365a4509e97f07c5c43d0ddb74657f.

@yumkam: Thx for your contribution!


added dongshin university

added dongshin university

@socialpercon I am sorry for a delay with processing your request. Pull request merged. Thank you!


Theme as separate repository

https://www.github.com/chexbox/Hash0ABA75 We will be moving over to this.

Got it.

I am sorry that I didn't tell anyone about this before I went ahead and made it.
If there is any css rule that we need to address, not added to the theme, we can use another stylesheet.

No problem. Could I be a collaborator on the theme repository?


[windows] FlutterAppRequiredException: The current directory does not appear to be a Flutter application project.

I am having issues running the tool on Windows. Same error with powershell, cmd and mingw. Firebase CLI is installed and configured for the project.
 flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 2.8.0, on Microsoft Windows [Version 10.0.19043.1237], locale en-US)
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision cf44000065 (14 hours ago), 2021-12-08 14:06:50 -0800
    • Engine revision 40a99c5951
    • Dart version 2.15.0
[√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[√] Chrome - develop for the web
[√] Android Studio (version 2020.3)
[√] VS Code, 64-bit edition (version 1.31.1)
[√] Connected device (2 available)

Building package executables...
Built flutterfire_cli:flutterfire.
Installed executable flutterfire.
Activated flutterfire_cli 0.1.1+1.
PS .\flutter-app> flutterfire configure
FlutterAppRequiredException: The current directory does not appear to be a Flutter application project.

Same for me on Mac OS

Hey @ezet - any chance you could share the pubspec.yaml for current directory that you're running the CLI in?

Hello, I am currently experiencing this issue. This is my pubspec.yaml if this could help moving forward with this issue.
name: XXXXXXXX
description: XXXXXXXXX
version: 1.0.0+1
publish_to: none

environment:
  sdk: ">=2.14.0 <3.0.0"

dependencies:
  bloc: ^8.0.1
  flutter:
    sdk: flutter
  firebase_core: ^1.10.5
  flutter_bloc: ^8.0.0
  flutter_localizations:
    sdk: flutter
  intl: ^0.17.0
  sentry_flutter: ^6.1.2
  percent_indicator: ^3.4.0

dev_dependencies:
  bloc_test: ^9.0.1
  flutter_test:
    sdk: flutter
  mocktail: ^0.2.0
  very_good_analysis: ^2.4.0

flutter:
  uses-material-design: true
  generate: true

Do you have a lib/main.dart in your project or do you have a different setup?

I think it might be that so I'm going to release a version shortly that no longer checks for that 😅

Please try 0.1.1+2 - thanks

Please try 0.1.1+2 - thanks

Could confirm, now it works with the new update. Thanks for the fast action.

I had an alternative lib/main.dart configuration, and can confirm it's working for me too now.

can you help me i have same that problem how can i solve that ?