HBASE-26564 Retire the method visitLogEntryBeforeWrite without RegionInfo in WALActionListner

https://issues.apache.org/jira/browse/HBASE-26564

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 10s
Docker mode activated.

_ Prechecks _

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

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

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

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 27s
master passed

+1 :green_heart:
compile
4m  6s
master passed

+1 :green_heart:
checkstyle
1m 28s
master passed

+1 :green_heart:
spotbugs
2m 58s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 13s
the patch passed

+1 :green_heart:
compile
4m  6s
the patch passed

+1 :green_heart:
javac
4m  6s
the patch passed

+1 :green_heart:
checkstyle
1m 10s
hbase-server: The patch generated 0 new + 39 unchanged - 1 fixed = 39 total (was 40)

+1 :green_heart:
checkstyle
0m 18s
The patch passed checkstyle in hbase-mapreduce

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

+1 :green_heart:
hadoopcheck
21m 55s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
3m 17s
the patch passed

_ Other Tests _

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

58m 54s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 7f161dcd0f5f 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8bca21b47d

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
86 (vs. ulimit of 30000)

modules
C: hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 37s
master passed

+1 :green_heart:
compile
1m 42s
master passed

+1 :green_heart:
shadedjars
8m 13s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  6s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 32s
the patch passed

+1 :green_heart:
compile
1m 44s
the patch passed

+1 :green_heart:
javac
1m 44s
the patch passed

+1 :green_heart:
shadedjars
8m 21s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  3s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
140m 25s
hbase-server in the patch passed.

+1 :green_heart:
unit
11m 25s
hbase-mapreduce in the patch passed.

186m 34s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 486420fbe43e 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8bca21b47d

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/1/testReport/

Max. process+thread count
4167 (vs. ulimit of 30000)

modules
C: hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/1/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 15s
master passed

+1 :green_heart:
compile
1m 36s
master passed

+1 :green_heart:
shadedjars
8m 35s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 59s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 52s
the patch passed

+1 :green_heart:
compile
1m 30s
the patch passed

+1 :green_heart:
javac
1m 30s
the patch passed

+1 :green_heart:
shadedjars
9m 10s
patch has no errors when building our shaded downstream artifacts.

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

_ Other Tests _

-1 :x:
unit
151m 54s
hbase-server in the patch failed.

+1 :green_heart:
unit
12m 43s
hbase-mapreduce in the patch passed.

199m  2s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
javac javadoc unit shadedjars compile

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

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8bca21b47d

Default Java
AdoptOpenJDK-1.8.0_282-b08

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/1/testReport/

Max. process+thread count
4342 (vs. ulimit of 30000)

modules
C: hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/1/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

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

_ master Compile Tests _

+0 :ok:
mvndep
0m 21s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  2s
master passed

+1 :green_heart:
compile
5m  1s
master passed

+1 :green_heart:
checkstyle
1m 47s
master passed

+1 :green_heart:
spotbugs
3m 39s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 52s
the patch passed

+1 :green_heart:
compile
4m 58s
the patch passed

+1 :green_heart:
javac
4m 58s
the patch passed

+1 :green_heart:
checkstyle
0m 25s
hbase-common: The patch generated 0 new + 39 unchanged - 5 fixed = 39 total (was 44)

+1 :green_heart:
checkstyle
1m  1s
hbase-server: The patch generated 0 new + 39 unchanged - 1 fixed = 39 total (was 40)

+1 :green_heart:
checkstyle
0m 19s
The patch passed checkstyle in hbase-mapreduce

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

+1 :green_heart:
hadoopcheck
24m  7s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
5m 10s
the patch passed

_ Other Tests _

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

67m 20s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

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

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 13f3b17870

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-common hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/2/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  9s
master passed

+1 :green_heart:
compile
1m 58s
master passed

+1 :green_heart:
shadedjars
8m 34s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 22s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 58s
the patch passed

+1 :green_heart:
compile
1m 55s
the patch passed

+1 :green_heart:
javac
1m 55s
the patch passed

+1 :green_heart:
shadedjars
8m 29s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 18s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 54s
hbase-common in the patch passed.

+1 :green_heart:
unit
146m 26s
hbase-server in the patch passed.

+1 :green_heart:
unit
12m  0s
hbase-mapreduce in the patch passed.

196m  1s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
javac javadoc unit shadedjars compile

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

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 13f3b17870

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/2/testReport/

Max. process+thread count
4774 (vs. ulimit of 30000)

modules
C: hbase-common hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/2/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
6m 40s
master passed

+1 :green_heart:
compile
3m  3s
master passed

+1 :green_heart:
shadedjars
10m 54s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 51s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
6m 16s
the patch passed

+1 :green_heart:
compile
3m  2s
the patch passed

+1 :green_heart:
javac
3m  2s
the patch passed

+1 :green_heart:
shadedjars
10m 35s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 46s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
3m 12s
hbase-common in the patch passed.

-1 :x:
unit
229m 31s
hbase-server in the patch failed.

+1 :green_heart:
unit
15m 32s
hbase-mapreduce in the patch passed.

297m  1s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux f6d0f39b4994 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 13f3b17870

Default Java
AdoptOpenJDK-11.0.10+9

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/2/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/2/testReport/

Max. process+thread count
2856 (vs. ulimit of 30000)

modules
C: hbase-common hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/2/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 33s
Docker mode activated.

_ Prechecks _

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

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

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

_ master Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  7s
master passed

+1 :green_heart:
compile
4m  8s
master passed

+1 :green_heart:
checkstyle
1m 28s
master passed

+1 :green_heart:
spotbugs
2m 52s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 52s
the patch passed

+1 :green_heart:
compile
4m  3s
the patch passed

+1 :green_heart:
javac
4m  3s
the patch passed

+1 :green_heart:
checkstyle
1m  5s
hbase-server: The patch generated 0 new + 39 unchanged - 1 fixed = 39 total (was 40)

+1 :green_heart:
checkstyle
0m 19s
The patch passed checkstyle in hbase-mapreduce

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

+1 :green_heart:
hadoopcheck
19m 50s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
3m 10s
the patch passed

_ Other Tests _

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

56m 14s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 4ba2306574dc 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / da616c00c7

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/3/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  5s
master passed

+1 :green_heart:
compile
1m 28s
master passed

+1 :green_heart:
shadedjars
8m 24s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 59s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 56s
the patch passed

+1 :green_heart:
compile
1m 28s
the patch passed

+1 :green_heart:
javac
1m 28s
the patch passed

+1 :green_heart:
shadedjars
9m 16s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  7s
the patch passed

_ Other Tests _

-1 :x:
unit
162m 45s
hbase-server in the patch failed.

+1 :green_heart:
unit
12m  1s
hbase-mapreduce in the patch passed.

208m 50s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
javac javadoc unit shadedjars compile

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

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / da616c00c7

Default Java
AdoptOpenJDK-1.8.0_282-b08

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/3/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/3/testReport/

Max. process+thread count
3567 (vs. ulimit of 30000)

modules
C: hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/3/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m  2s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m  8s
master passed

+1 :green_heart:
compile
1m 49s
master passed

+1 :green_heart:
shadedjars
9m  8s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  3s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

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

+1 :green_heart:
compile
1m 49s
the patch passed

+1 :green_heart:
javac
1m 49s
the patch passed

+1 :green_heart:
shadedjars
9m  0s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  3s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
201m 32s
hbase-server in the patch passed.

+1 :green_heart:
unit
15m 22s
hbase-mapreduce in the patch passed.

254m 23s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 22bbf0e826d8 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / da616c00c7

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/3/testReport/

Max. process+thread count
3447 (vs. ulimit of 30000)

modules
C: hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/3/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m  7s
Docker mode activated.

_ Prechecks _

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

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

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

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 29s
master passed

+1 :green_heart:
compile
4m  8s
master passed

+1 :green_heart:
checkstyle
1m 33s
master passed

+1 :green_heart:
spotbugs
2m 57s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 14s
the patch passed

+1 :green_heart:
compile
4m  5s
the patch passed

+1 :green_heart:
javac
4m  5s
the patch passed

+1 :green_heart:
checkstyle
1m  9s
hbase-server: The patch generated 0 new + 39 unchanged - 1 fixed = 39 total (was 40)

+1 :green_heart:
checkstyle
0m 19s
The patch passed checkstyle in hbase-mapreduce

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

+1 :green_heart:
hadoopcheck
21m 36s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
3m 18s
the patch passed

_ Other Tests _

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

58m 45s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/4/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 6c761f928db2 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / d399799c29

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
86 (vs. ulimit of 30000)

modules
C: hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/4/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 23s
master passed

+1 :green_heart:
compile
1m 44s
master passed

+1 :green_heart:
shadedjars
8m 31s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  2s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 31s
the patch passed

+1 :green_heart:
compile
1m 43s
the patch passed

+1 :green_heart:
javac
1m 43s
the patch passed

+1 :green_heart:
shadedjars
8m 14s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  4s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
140m 16s
hbase-server in the patch passed.

+1 :green_heart:
unit
11m 22s
hbase-mapreduce in the patch passed.

186m 11s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 0dfe49280da0 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / d399799c29

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/4/testReport/

Max. process+thread count
4243 (vs. ulimit of 30000)

modules
C: hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/4/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 48s
master passed

+1 :green_heart:
compile
1m 31s
master passed

+1 :green_heart:
shadedjars
8m 21s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 58s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 57s
the patch passed

+1 :green_heart:
compile
1m 29s
the patch passed

+1 :green_heart:
javac
1m 29s
the patch passed

+1 :green_heart:
shadedjars
8m 17s
patch has no errors when building our shaded downstream artifacts.

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

_ Other Tests _

+1 :green_heart:
unit
146m  6s
hbase-server in the patch passed.

+1 :green_heart:
unit
11m 58s
hbase-mapreduce in the patch passed.

190m 43s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/4/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3938

Optional Tests
javac javadoc unit shadedjars compile

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

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / d399799c29

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/4/testReport/

Max. process+thread count
4609 (vs. ulimit of 30000)

modules
C: hbase-server hbase-mapreduce U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3938/4/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.


BUG: Can't handle nan

Problem:
nan value is not None, so it will be skipped by check_for_none.
And nan is float and don't have len method, so check_empty_string raises an error.
>>> from thefuzz.fuzz import ratio
>>> ratio("a", float("nan"))  # or `np.nan`
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\Zero\mambaforge\envs\dtoolkit-dev\lib\site-packages\thefuzz\utils.py", line 38, in decorator
    return func(*args, **kwargs)
  File "C:\Users\Zero\mambaforge\envs\dtoolkit-dev\lib\site-packages\thefuzz\utils.py", line 29, in decorator
    return func(*args, **kwargs)
  File "C:\Users\Zero\mambaforge\envs\dtoolkit-dev\lib\site-packages\thefuzz\utils.py", line 46, in decorator
    if len(args[0]) == 0 or len(args[1]) == 0:
TypeError: object of type 'float' has no len()

Solution:
check_for_none need to be updated.
or create a new decorator for handling nan value.
https://github.com/seatgeek/thefuzz/blob/6e68af84e086b3e5f7253d4f9b0d6c7313e34637/thefuzz/utils.py#L33-L39

Now that rapidfuzz is used under the hood, this is working


Overloaded productions

Reviewer checklist

[ ] Test coverage: stack test --coverage
[ ] Public API documentation: stack haddock
[ ] Style conformance: stylish-haskell

This example is actually much worse than the example with sort injections: we have three constructors in a single sort which do not obey the "no confusion" axiom between different constructors, due to the overloading axioms.

I'm reviewing the Kore definition for this. It looks like the top-most symbol gets the attribute anywhere to indicate that it came from a K constructor. So, the first step should be to recognize that anywhere symbols are injective. We should also recognize that overloaded anywhere symbols are \bottom except where they have a defined overloading constructor; the frontend should generate such an axiom or axioms, but for now we could write the logic in the backend.

Is it really true that anywhere symbols are injective? I can't find an intuitive link between the name and the property. @traiansf , with whom I previously heard talking about anywhere, though it might have been in a completely different context.

Is it really true that anywhere symbols are injective?

Yes, but maybe we should give them a different attribute (injective?) in the frontend.
The overloaded symbols are considered constructors in K, but not in Kore. Therefore, they are given "no confusion, same constructor" axioms, in other words: injectivity axioms.

Ok. There is something weird about this, I would just add the injective attribute (which we can also add for normal constructors, it can't hurt, and it will probably simplify the attribute inference we do when loading kore definitions), but I guess that we can also use anywhere if we document it.

See also: kframework/k#513

I am closing this pull request because supporting KWASM is not a priority right now.


Nexys A7 board for opentitan

Hi
Is it possible to use Nexys A7 board instead of Nexys video as target fpga for the opentitan on FPGA?
If yes, could you please hint the procedures to do it.
Thanks a lot.

Hi @nicolast0604, thanks for your interest in OpenTitan.
The A7 board isn't currently usable in OpenTitan, as the earl grey toplevel design is much too large. You'll need to produce a toplevel which removes some functionality, reduces memories, etc.
The top_earlgrey example is a starting point for such an approach, but you'll see quickly that the tooling around that is rather fragile at the moment.
We intend to improve the tooling to make it easier to produce customized toplevels for smaller FPGA boards, initial work is available at #5636 and #5782. It will take a couple more weeks before we have the bandwidth to push this work over the finish line, however.
So for now, I'd suggest you start with top_englishbreakfast and try to reduce it until it first onto the A7 board. Doing so will require a bit of experience with FPGA board bringup, so if you haven't done that before I'd recommend going with a Nexys Video board instead.

I believe this question has been addressed. Feel free to reopen if that is not the case.


Add ability to download LSRs and serve as time-shifted placefiles for use in simulations

Uploaded LSR icon sheets to assets directory in this commit.

Incorporate Rod's updated LSR placefile code (9/24)


'Snapshots View' doesn't display when clicking 'View Share Snapshots' under one folder

Storage Explorer Version: 1.15.0-dev
Build: 20200730.1
Branch: master
Platform/OS: Windows 10/ Linux Ubuntu 16.04/ macOS High Sierra
Architecture: ia32/x64
Regression From: Previous release(1.14.2)
Steps to reproduce:

Expand one storage account -> File Shares.
Open the file share -> Create a new folder.
Open the folder -> Click 'View Share Snapshots' under the folder.
Check the result.

Expect Experience:
'Snapshots View' display well.
Actual Experience:
'Snapshots View' doesn't display.

Duplicate of #3268.

Hi @craxal
Snapshot View shows when directly clicking the 'View Share Snapshots' action. But it doesn't show when clicking the action under one folder.

@v-limu Understood. I'll reopen, but I have a PR out that should fix this.


Webpack 5 build stuck on AWS Amplify

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
d1ibz1zzj8f3a3
AWS Region
eu-west-2
Amplify Hosting feature
Frontend builds
Frontend framework
Next.js
Next.js version
13.5.4
Next.js router
App Router
Describe the bug
I'm trying to integrate storybook into a large nextjs application. I added all of the required configurations (devDependencies, scripts in package.json, storybook configs under .storybook and stories).
The first time building the app, it took about 5 minutes and was deployed without any issues.
I made a change to the application (added some new storybook stories) and pushed, but that time the build got stuck at a certain point.
I'm running storybook build which takes about 20s on my local machine, but gets stuck after a couple of seconds on AWS amplify. It gets stuck at different percentages. No errors are getting thrown, the build is just unresponsive.
I have cancelled and restarted the build about 8 times. I also tried rebuilding the commit which worked previously but that one also got stuck.
Expected behavior
The build should finish in about 5 minutes and should generate all of the required static files.
 Please run:
                                    npx update-browserslist-db@latest
                                    Why you should do it regularly: https://github.com/browserslist/update-db#readme
2023-10-30T16:41:11.385Z [WARNING]: <s> [webpack.Progress] 12% building 0/1 entries 400/553 dependencies 38/221 modules
2023-10-30T16:41:11.905Z [WARNING]: <s> [webpack.Progress] 12% building 0/1 entries 719/800 dependencies 54/303 modules
2023-10-30T16:41:12.624Z [WARNING]: <s> [webpack.Progress] 13% building 0/1 entries 884/900 dependencies 57/386 modules
2023-10-30T16:41:13.340Z [WARNING]: <s> [webpack.Progress] 13% building 0/1 entries 967/1000 dependencies 58/413 modules
2023-10-30T16:41:13.914Z [WARNING]: <s> [webpack.Progress] 14% building 0/1 entries 1073/1100 dependencies 74/428 modules
2023-10-30T16:41:15.269Z [WARNING]: <s> [webpack.Progress] 15% building 0/1 entries 1260/1300 dependencies 106/465 modules
2023-10-30T16:41:15.853Z [WARNING]: <s> [webpack.Progress] 17% building 0/1 entries 1590/1600 dependencies 134/586 modules
2023-10-30T16:41:16.551Z [WARNING]: <s> [webpack.Progress] 17% building 0/1 entries 1700/1724 dependencies 145/633 modules
2023-10-30T16:41:17.232Z [WARNING]: <s> [webpack.Progress] 18% building 0/1 entries 1800/1857 dependencies 155/656 modules
2023-10-30T16:41:17.975Z [WARNING]: <s> [webpack.Progress] 26% building 0/1 entries 2162/2186 dependencies 300/780 modules
2023-10-30T16:41:18.518Z [WARNING]: <s> [webpack.Progress] 27% building 0/1 entries 2400/2565 dependencies 311/966 modules
2023-10-30T16:41:19.170Z [WARNING]: <s> [webpack.Progress] 27% building 0/1 entries 2799/2900 dependencies 363/1147 modules
2023-10-30T16:41:19.879Z [WARNING]: <s> [webpack.Progress] 27% building 0/1 entries 3672/3700 dependencies 414/1299 modules
2023-10-30T16:41:20.441Z [WARNING]: <s> [webpack.Progress] 46% building 0/1 entries 4107/4158 dependencies 900/1371 modules

Additional information
I tried rebuilding another AWS Amplify app that I have which also uses nextjs. The build finished without issues, so I'm assuming it's not caused by a general AWS Amplify build outage.
Docker image that is used for the build is: public.ecr.aws/docker/library/node:16
Platform being used is Web.
Error message in the console is
Build failed to complete successfully. Reason: Build timed out

I recreated the application, new id is d11xtko56oucks. Issue still exists.

Okay so it turns out it was an error in the application itself. It was related to this issue: https://github.com/diegomura/react-pdf/issues/1678
But it's not clear why the build logs didn't show the output. It's probably because storybook asks for consent to send telemetry after an error:
=> Failed to build the preview
SB_BUILDER-WEBPACK5_0002 (WebpackInvocationError): Module not found: Error: Can't resolve './zlib_bindings' in './node_modules/zlib/lib'
    at ./node_modules/@storybook/builder-webpack5/dist/index.js:1:7584
    at ./node_modules/webpack/lib/HookWebpackError.js:68:3
    at Hook.eval [as callAsync] (eval at create (./node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:11:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (./node_modules/tapable/lib/Hook.js:18:14)
    at Cache.shutdown (./node_modules/webpack/lib/Cache.js:150:23)
    at ./node_modules/webpack/lib/Compiler.js:1229:15
    at Hook.eval [as callAsync] (eval at create (./node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (./node_modules/tapable/lib/Hook.js:18:14)
    at Compiler.close (./node_modules/webpack/lib/Compiler.js:1222:23)
    at ./node_modules/@storybook/builder-webpack5/dist/index.js:1:7569
    at finalCallback (./node_modules/webpack/lib/Compiler.js:441:32)
    at onCompiled (./node_modules/webpack/lib/Compiler.js:450:20)
    at ./node_modules/webpack/lib/Compiler.js:1177:21
    at eval (eval at create (./node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:20:1)
    at ./node_modules/webpack/lib/EntryPlugin.js:49:5
    at ./node_modules/webpack/lib/Compilation.js:2198:13
    at ./node_modules/webpack/lib/Compilation.js:2090:6
    at ./node_modules/webpack/lib/Compilation.js:1952:13
    at ./node_modules/webpack/lib/util/AsyncQueue.js:346:6
    at processTicksAndRejections (node:internal/process/task_queues:78:11)
✔ Would you like to help improve Storybook by sending anonymous crash reports?

To debug the issue in AWS Amplify, I added the --disable-telemetry option which then allowed the build to spit out the actual error logs.
The fix in the end turned out to be to update my package.json scripts to fix the zlib error and also disable telemetry:
"build-storybook": "cp ./node_modules/zlib/lib/zlib.js ./node_modules/zlib/lib/zlib_bindings.js && storybook build --disable-telemetry"


advertise test framework wiki when early setup fails

Very few people have seen the wiki.. this will help encourage people to lean on local-development and hopefully get more eyes on the wiki so we can fill in any gaps.

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
e90b40b6274c567e998508d733276898a7d41bc7
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
e90b40b6274c567e998508d733276898a7d41bc7
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

In response to a cherrypick label: new pull request created: #31533


older messages are append bottom instead of top

while open the conversation details with messages, default load the 30 recent messages, while scroll up older messages came, but these older messages append to bottom instead of top. can you please help, thank you.

same problem , is there a way to fix this ?

Yeah, should change the way loaded messages are populated. This shall be easier with our new ChatLog components.
You can investigate around here yourself, we will probably only get to this later.

I will investigate that , Thank you


Look into using "config-chain" for opts

https://github.com/isaacs/config-chain

Should this issue remain open?

Don't think so.  Closing.


refactor: Migrate AWS cloudfront/cloudwatch resources to new structure

[ ] internal/providers/terraform/aws/cloudfront_distribution.go
[x] internal/providers/terraform/aws/cloudwatch_metric_alarm.go

I think cloudfront_distribution and dx_connection are the hardest resources of aws for migration. I personally don't know what the right structure for them is.

@sinabakh Yeah, agree, this one is tough cookie. I have it in not-working state right now, but didn't have time to finish. Hope to finish it on a weekend :)


Allow less efficient use of BRAM resources

Before this change, yosys required 4096 bits (or at least 50%)
of the bits in a RAM to be used, in order to implement it as a
PB-RAM. Since there are less than 1000 FFs available in the FPGA
it means that any memory using somewhere between 1k and 4k bits
will not fit in the device.
This lowers the requirements on RAM efficiency to be more in line
with the iCE40 backend, which uses comparably sized FPGAs
Signed-off-by: Olof Kindgren<EMAIL_ADDRESS>

@olofk. This change makes sense. Approving it.


[Feature] Add Stage to Contact

Please add the stages parameter to contact because it is very important.
rails console

mautic = Mautic::Connection.first
contacts = mautic.contacts.where(search<EMAIL_ADDRESS>contact = contacts.first

contact.stage_id
=> nil

contact.stage
=> nil

contact.stages
=> nil

The contact by<EMAIL_ADDRESS>in Mautic has stage_id exist.
Thanks.

Hi @EnziinSystem ,
thanks for feedback, can you please more specify what's about it stage? I did quick look into Mautic doc and can't find it (https://developer.mautic.org/#get-contact)
thx

Hi @EnziinSystem ,
thanks for feedback, can you please more specify what's about it stage? I did quick look into Mautic doc and can't find it (https://developer.mautic.org/#get-contact)
thx

Hi,
You can read in the page: https://docs.mautic.org/en/stages
And stage in the left menu.

Hi,
You can read in the page: https://docs.mautic.org/en/stages
And stage in the left menu.

Latest released version now include "stage". See https://github.com/luk4s/mautic-rails/blob/master/app/models/mautic/contact.rb#L144, https://github.com/luk4s/mautic-rails/blob/master/app/models/mautic/stage.rb


Adsk Contrib - Adding the new cg and studio configs (issue #1999)

For issue #1999 adding the new cg and studio configs.

Added new configs cg-config-v2.2.0_aces-v1.3_ocio-v2.4.ocio and studio-config-v2.2.0_aces-v1.3_ocio-v2.4.ocio
Made default config cg-config-v2.2.0_aces-v1.3_ocio-v2.4
Updated the tests accordingly.

TODO: Some documents such as aces_cg.rst and aces_studio.srt need to be updated.

Related question: The list of builtin configs is growing, is there a deprecation/removal plan?

@KelSolaar , I'm guessing you're asking that question due to a concern over the increase in size it adds to the library?
The goal is to improve the system so that it only implements the deltas between configs rather than generating each from scratch. In the nanoColor branch we have a way of generating the built-in configs via code (starting from the YAML files you provided). Currently this simply regenerates each config from the YAML, but this approach could be extended to avoid a significant increase in size by only implementing the changes from one version to the next.

@zachlewis , thanks for the feedback. Let's discuss removing "CIE XYZ-D65 - Display-referred" from the inactive list at the TSC meeting on Monday.

Following the discussion at the TSC meeting today, we decided to add the color space "CIE XYZ-D65 - Scene-referred" to the inactive list. I logged this separately here. To recap, the group agreed that this is more for use via the API and is not something that should be exposed in artist menus.
@zachlewis , thanks for starting the discussion. I pushed a commit to implement the change.

@zachlewis , thanks for starting the discussion. I pushed a commit to implement the change.

I did put it first on my side, with the idea that we go from Scene to Display.


rancher/external-dns:0.6.2 Does not support Rancher with Custom CA

Rancher versions:
rancher/server: v1.6.0
rancher/agent: v1.2.2
Infrastructure Stack versions:
healthcheck: v0.3.1
ipsec: v0.11.2
network-services: 0.2.0
scheduler: 0.5.1
kubernetes (if applicable): N/A
Setup details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single Node
Environment Template: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:

Launch External DNS from Infrastructure Services into environment
Configure appropriately to connect to DNS
Launch

Results:
Container fails to start, giving error message:
6/27/2017 12:13:55 PMtime="2017-06-27T19:13:55Z" level=info msg="Starting Rancher External DNS service"
6/27/2017 12:13:55 PMtime="2017-06-27T19:13:55Z" level=fatal msg="Failed to configure cattle client: Get https://x.x.x/v1: x509: certificate signed by unknown authority"
6/27/2017 12:14:04 PMtime="2017-06-27T19:14:04Z" level=info msg="Starting Rancher External DNS service"
6/27/2017 12:14:04 PMtime="2017-06-27T19:14:04Z" level=fatal msg="Failed to configure cattle client: Get https://x.x.x/v1: x509: certificate signed by unknown authority"

Expected Results
Container should successfully connect to Rancher by first importing and updating the certificate trust store if a file is found on the host, here: /var/lib/rancher/etc/ssl/ca.crt
This would mimic the procedures required by the rancher-agent when using a Custom CA.
Thanks!

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.


Invalid project name with build_directory results in obscure Docker error

If you specify a project name that includes upper case letters or spaces, and use a container that uses build_directory, when the container is built you get a relatively unclear error message:

Building image failed: invalid reference format: repository name must be lowercase

It's not immediately obvious that the project name ends up being used as part of the docker image (although in hindsight it makes sense).

Hey @jagregory, thanks for letting me know about this. We should definitely be doing some validation on the project name (and probably the container name as well) to prevent issues like this.

Thanks again for your feedback @jagregory - I've fixed this issue and I'll push out a release with the fix shortly.
In the meantime, you can grab the latest version from the files section of https://bintray.com/charleskorn/batect/batect/0.33.0-dev.0.15%2B57c558f if you want to try out the fix before I publish the release. (It might take ~20 minutes for the build and publish to finish.)


[VS Code] Starting collaboration session: RPC connection closed.

<!--
For Visual Studio problems/feedback, please use the Report

This seems to be a duplicate of #1353 . However, your logs may provide us with helpful information. You can access them via the Live Share: Export Logs command from the command palette (ctrl + shift + p) and attach them to this issue.

Closing due to inactivity. Let's continue the conversation in the linked issue if you still see this happening. Thanks for using LiveShare!


Change the signature of the entity readers to take content type and class type.

This is in support of adding larger Jackson compatibility. It makes sense to make the readers aware of what they may be converting some entity into, and whether they can actually support the content type of that entity.
The changes contained here are a reflection of the conversation in #23.

Looks good to me!

Looking forward to this!
Is there something I can help with ?


feat(types): add lexicon type generation

This PR adds a script to automatically:

Download the latest lexicons from ATProto's repo
Generate TypeScript types using @atproto/lex-cli

Not ready for merge yet, but sharing for early feedback. Current status:

✅ Downloads latest lexicons from ATProto
✅ Extracts only lexicon files
✅ Generates types using official lex-cli
⏳ Need to decide on additional type enhancements (see @atcute/lex-cli)

Next steps:

Evaluate if we want to add branded types (like @atcute/lex-cli)
Add CI integration

related to #30

Closing this PR as its functionality has been superseded by #28 which was just merged.


Virtual Machine Scale Set - enum should have default values

Original reported: https://github.com/terraform-providers/terraform-provider-azurerm/issues/8454
The priority in virtual machine scale set resource is an enum, but this resource is not returned when not specified and default value is not specified in the swagger which is confusing for the customers.

@avirishuv can you take a look at this issue?

@ArcturusZhang could you please clarify that when is the 'priority' property not returned - during a Get vmss call, or something else ? Any steps you can share and expected behavior will be helpful.

You could try the config in the original issue: https://github.com/terraform-providers/terraform-provider-azurerm/issues/8454
It is using terraform but it is quite straightforward to convert it to REST API call. The key is no priority set in the request, and thus no priority in the response.

@ArcturusZhang the default value of 'priority' is Regular. Once the VMSS is created, the value of priority cannot be changed.
Also, if priority is not specified during the creation, then its value is not returned, because returning would break the get-put semantics.

hi @ArcturusZhang do you have any other questions on this topic? If not, should we close the issue?

Well, I do not have more questions and your answer sounds reasonable. We might need find some workaround for the issues in terraform. Thanks @avirishuv


Required Modules To Work

The module requires a list of modules in order to work without errors such as:

[X] productcomments
[X] ps_mainmenu
[X] ps_banner
[X] ps_imageslider

Not sure if more.
It will be nice if they would be listed on the readme. What do you think?

Hi @david8z,
thanks for your consideration, yes these are all native/default Ps modules, most of them are related to the Bootstrap endpoint for home page data. All the other APIs are independent of these modules, and I think the bootstrap endpoint is somehow project specific.
But it's a good idea to have a list in readme to show that the module works with these modules.
I will add it. Thanks


BluetoothGattCharacteristic needed to extract value on subscription

First of all, I'd like to thank you for your contribution, it has been very easy to integrate and works very well so far.
I have a problem though. I'm pairing with a Heart Rate Monitor and this is the code I was using to extract the heart rate value from the BluetoothGattCharacteristic from the Android framework class:
int flag = characteristic.getProperties();
int format = (flag & 0x01) != 0 ?
                BluetoothGattCharacteristic.FORMAT_UINT16 :
                BluetoothGattCharacteristic.FORMAT_UINT8;
int heartRate = characteristic.getIntValue(format, 1);

However, when I receive a CommandChange on a subscription now, I don't have access to either the properties of the characteristic, or the characteristic itself, so I cannot extract the heart rate.
How should I proceed here? If it is not even possible with the current state of the library and its code needs to be modified, I can implement the necessary modifications if you provide some guidance.

By inspecting how CommandResult is created, I think it is not possible to do what I want to do. It should hold the BluetoothGattCharacteristic.

Fixed merged into master.

A new release containing the changes has been published.
compile 'si.inova:neatle:0.9.3'


Problems with debug

Here's a common error, did not understand where the hidden problem, the Internet is a little information.
Unable to start debugging. Unexpected GDB output from command "-environment-cd C:\Users\я\Desktop\HELLOWORLD-MINGW". C:\Users\я\Desktop\HELLOWORLD-MINGW: No such file or directory.
code Launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/helloworld.exe",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"miDebuggerPath": "C:\Program Files\mingw-w64\x86_64-7.3.0-posix-seh-rt_v5-rev0\mingw64\bin\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}

Hi Team,
One small suggestion.
Can we analyse the problem as follows.
-> if the user is using a single package or folder path the we can pass the command prototype to the terminal to run the code.
D:\vs-workspace> & C:/Users/shuvagho/Anaconda3/python.exe d:/vs-workspace/python/com/python/core/modules/cursesio/cursesio.py
-> In case if the user is using multiple packages and one file is importing other package as a module then we can pass the command prototype to the terminal to run the code
 & C:/Users/shuvagho/Anaconda3/python.exe -m  python.com.python.core.modules.cursesio.cursesio


move external requests to background page for CORS

Without an Access-Control-Allow-Origin header, external requests to
fetch value/balances need to occur in a background page.
Fixes #17

Hi @sclem
I tested the PR and my Personal Capital updated as expected. Appreciate the update.


refactor!: rewrite and restructure existing functionality

This PR tracks progress on #11. At the moment, this branch recreates the plugin's existing functionality but removes the following options:

modifier: not useful, since anything but :t is massive, and modifying it messes with the plugin's automatic ambiguity resolution
index_format, padding, and icons: removed in favor of tab_format (see the README)
kill_maps, custom_command, and custom_map_prefix: removed in favor of buftabline.map() (see the README)
show_no_name_buffers: not useful
next_indicator: always set to >, which matches the automatic (and non-customizable) left-side truncation marker

Other changes:

Icon colors are enabled by default, which is consistent with other plugins (e.g. Telescope)
hlgroups is now a table, but I've put in backwards compatibility for hlgroup_current and hlgroup_normal

tab_format takes care of #10, #12, #13, and #14. This leaves the following tasks:

[x] Support customizable flag markers (trivial)
[x] Support more highlight groups (not too bad)
[ ] Fix broken tests, i.e. all of them (this is a pain, and I plan on focusing on integration tests that assert against the tabline itself)
[x] Consider padding (not hard to implement in the way barbar does it, but it makes tabline generation stateful, so I have to weigh the advantages)

Hi Jose. I noticed a small issue. I set the modified option inside the flags option to an empty string. I also added a | separator to the tab_format option:
local options = {
	tab_format = " #{n}: #{b}#{f} |",
	flags = {
		modified = "",
		not_modifiable = "[-]",
		readonly = "[RO]",
	},
}

I was hoping to see no effect after making a change to the current buffer. However, an empty space does appear:
No change:

Buffer changed:

Do you agree that this is a problem?

Ohh I just realized that by commenting out the whole line, I get the behavior I wanted. However, I do think that setting modified = "" should result in the same behavior.

Yep, agreed. Just pushed a commit that should take care of it. Let me know if you have any more feedback for now – I'll work on the highlight groups next time I have a chance.

I've implemented highlight groups (a breaking change to existing config keys) and made the decision not to include padding, mostly because I don't think I'd be able to do it justice, since I don't use any file tree plugins myself.
I'll rewrite the tests for peace of mind before merging, but other than that I think this is (hopefully) good to go.

Hi Jose, I just tested the new highlight groups but they don't seem to work for me. On the other hand, the old approach of using hlgroup_current and hlgroup_normal (instead of hlgroups) does function as expected. I pulled your last two commits of the develop branch.

By the way, I also noticed that the modified option inside the flags table is also not working: No matter what I set it to, [+] is always displayed.

Whoops! I was testing this out by directly modifying the plugin's options, but the timing of getting the user's flags and highlight groups wasn't working. Thanks for describing the problem clearly so I could diagnose it. Could you let me know if it works for you on the latest commit?

Everything seems to be working fine now! Thanks for spending time on this.

Thanks for confirming! I just finished rewriting the tests, so I'm going to merge this.


Consider project name

My Top Choices

Conduit
Hub
Gateway

My Next Choices

Interchange
Junction
Influx
Ingress
Jetway
Onramp

Other Choices

Airlock
Passage (way)
Pipe
Turnstile
Highway
Router
Convergence

If  you are looking for more illustrated (or brain fuck) name you can peek:
Janus is the god of beginnings, gates, transitions, time, doorways,[1] passages, and endings.

My guess is that it stays with the simple name it has now.

I'm going to close this as Spring Cloud Gateway describes exactly what it is, even if it is a bit boring.


Integration tests; intermittent failures

cribl will fail trying to connect to the default tcp json port
nginx will fail trying to get responses from the POST test

Both of these test failures were resolved by adding show delays between starting the servers and letting clients hit them. Interestingly, the delays were not needed running on my dev laptop or John's but Donn consistently had issues running on his EC2 instance.


As a user on mobile when I select a tag on the tag index page I want to see my selected tag directly below the tree, without any other details on the page

@rlskoeser When testing the index page on mobile I noticed the following:

when I select a tag and I'm taken to the tree page the active tag appears below the footer
there is an open panel of the project intro below the active tag

Here is the design on figma that we agreed on
It's happening on all browsers, below is the issue on chrome mobile emulator:

@gissoo I thought I had fixed that problem with the intro partially showing.  I see now that it's visible when you scroll, and that shouldn't be the case.
Did I interpret the design correctly? You're kind of cheating because you're not showing the full height, I assumed that you intended the tag to be at the bottom of the screen. How does the tag without an active leaf display with the footer? I think some of the footer will be visible on some devices, is this intended/desired?

@rlskoeser I was hoping the footer wouldn't be visible, I understand if it's impossible. I think the tag should appear above the footer even if it's stuck directly to the top of the footer.

@gissoo I was thinking sticking the tag to the top of the footer might be a reasonable solution (if the footer is visible). I think it would be hard for the footer not to be visible, but perhaps we can look at it together.
🤔 if the footer is not visible, we're going to have a scroll trap (zoom trap)....

completed in #172


Specifying the first displayed entity/chain in molstar using labelAsymId?

Hi @bioinsilico, continuing from before:
Is there a way to specify the sequence loaded into the molstar sequence panel (for example by labelAsymId) on startup?
I saw that there was a params and a props that seem to pass values to the molstar init, but I don't see any options that might relate to setting the initial state (e.g. chain, entity, etc) on the sequence pane.
Do you have any advice?
Thanks for your help

Hi @cyrus0824! I am not sure if I understand your question. The sequence loaded into molstar is defined by the PDB entry. Please, could you elaborate on your question?

Hi @cyrus0824! Is any progress on this ticket?

Hi @cyrus0824, I will close this ticket. But please feel free to reopen it if convenient.


user access for seeing monitoring dashboards

The documentation should specify that a user needs to have the View Monitoring role in the project where Monitoring is installed to access the monitoring dashboards. Otherwise, the dashboards are grayed out.

Possibly related to #963.
cc @martyav

Related to https://github.com/rancher/dashboard/issues/4466

@btat @martyav To be honest, I'm slightly confused about what the fix for https://github.com/rancher/dashboard/issues/4466 is. It seems the original expected and actual results have changed throughout the comment thread.
Back to the topic of this issue. The most common issue I see raised by customers regarding monitoring and RBAC is that users see the links in the 'Monitoring' page as grayed out. The documentation needs to cleary say what permissions are required to allow this. In my testing, the only way I have seen this is by:

Installing or moving the cattle-monitoring-system namespace to a project where the users have View Monitoring role
The users need at least Read Only role on one project in the cluster

If these are indeed the required steps to see the Monitoring dashboards available (not grayed out) in the cluster, then the documentation should specify that. The comment https://github.com/rancher/dashboard/issues/4466#issuecomment-1771627358 says that's a workaround. But to me, that seems like the solution. Clarity is needed here and it needs to be explicit in the documentation.


Panel Attribute Sections

Hello Ryan,
How can I create such a sectionable panel, Can you give me hint or suggestions please?

Example from Button Block panel..
Sincerely.

https://github.com/m-Ryan/easy-email-demo/blob/main/src/CustomBlocks/MyFirstBlock/Panel.tsx
check this

Thanks..
https://ant.design/components/collapse/
-> That one worked.


Set up prettier for Solidity according to the current style

Analyze the current Solidity style and set up prettier accordingly. It doesn't have to match perfectly.
https://github.com/prettier-solidity/prettier-plugin-solidity

@bbenligiray please review #324 at your convenience

Fixed by #324 .


chore: add CodeQL Analysis to Repo

It is showing one alert in test_project.py, do we want to also address that?

yeah probably

It is showing one alert in test_project.py, do we want to also address that?

took a further look and dismissed it as False Positive
UI for reporting and removing false positives is easy, can do it through github on the files page


⚠ Mobitopup has degraded performance

In 637264b, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 6581 ms

Resolved: Mobitopup performance has improved in c8952fb.


Custom elaborated error messages

With the parser getting more sophisticated than ever, we have the opportunity to break free from the V8-compatible error messages.

Some obvious questions.
When to do this?

Right away
At the next major version (3.x) so as to maintain compatibility

What's the basis for the new message?

Take V8 and extend it as necessary
Take SpiderMonkey (aka Firefox) and extend it as necessary
Use something from Shift JS
Standardize at ESTree

@ariya In a friendly tone. What is the basic ideas here? Only replace replacing the current error messages with more informative messages or a more sophisticated error system? I would suggest both.  As a simple beginning. All error messages now could be refactored into enum values. A export const enum. Similar to what you now do for tokens, and only use the numeric representation of the error messages in the code. You would also save some bits when minified if you do that.


Box size and periodicity as global var

Overriding the box size and periodicity settings of the input should be done globally, like previous.
This makes more sense.

This has been implemented in 2.0.0-a1.


3 new rebuses.

Associated Issue: #121
Summary of Changes

Added 3 commonly used rebuses.

Pull Request Test Coverage Report for Build 264

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 90.686%

Totals

Change from base Build 263:
0.0%

Covered Lines:
126

Relevant Lines:
137

💛  - Coveralls

Thanks!


maximum recursion depth exceeded when calling a Python object

After Sysprep the Windows 2012 image goes into a boot loop with only the error in the command prompt,
"maximum recursion depth exceeded when calling a Python object"
Hoping to get some more information about this error.

Closing issue, as no updates were received from the OP.


Large datasets cause extremely slow imports

I'm currently using this target with the zendesk tap. We're using this to keep a local copy of the zendesk data, which we use to run daily reports, along with some additional use cases. I've had the import running for several days and noticed that cpu was spiking on my db instance along with some queries taking several minutes to run. After doing a bit of digging, I found that some of my tables were already into the millions of records and needed some indexes.
Specifically, the indexes needed were around the _sdc_sequence and _sdc_level_{}_id columns.
I'm wondering what the thoughts were around potentially making a PR to automatically create these indexes or if maybe it would be better to just have that noted in the documentation as to specific fields that might need to have indexes as the tables start growing.
For specifics, at the moment, these are what my largest tables (over 100k records) look like:

table
count

tickets__custom_fields
5,418,717

ticket_audits__events
2,466,633

ticket_audits__events__value
461,196

tickets__tags
342,643

ticket_audits
234,680

ticket_audits__events__previous_value
118,678

@bradleyprice I think we'd be extremely happy with any help on this!
The documentation is an obvious low hanging fruit, so any recommendations you have on that are very welcome.
As far as a code enhancement, do you have any specific ideas or requests for the feature?
I think we've been managing our larger installations by routinely running some add index commands, so it sounds like this could definitely be an improvement for everyone using this codebase. I have some ideas as to what would make the most sense, but you have more recent pain in this area and are arguably a better expert on this than I 😄

So, I haven't had much of a chance to think about it. As soon as I have a chance I am going to gather some logs from postgres to analyze the queries being generated.
I was thinking it would be easy enough to generate an index when new schemas are being created, since we know what queries are being used to insert data into the database. The downside to this is that we could potentially be creating unused indexes, since not all tables will be large enough to need an index. Some of my tables have upwards of 10 million records, while some of them have less than 10.
I see 2 potential methods we could take:

Create indexes for all new tables

pros

easy
if a user wanted to opt-in to using the auto creation of indexes, but had previously setup indexes for their existing tables, there wouldn't be an issue

cons

potentially creating indexes that aren't needed, in the case of a small dataset
existing tables wouldn't get indexed (in the case of someone who is already using this target)

Analyze table as import happens

pros

not creating useless indexes (depending on how we decide when to create an index)
retroactively takes care of existing tables

cons

less efficient, since we'd have to continually check for some threshold
if a user had existing tables with indexes, we'd need to either check to see if an indexes exist or allow a user to configure what tables to index or not index

I assume with any method that was taking, this would need to be an "opt-in" feature, since there are probably people who would want to handle indexing themselves.
I'd love to hear more about your thoughts around potential implementations or potential issues.
Thanks!

Those are more or less the pros/cons I was thinking as well.
The "fun" part with the implementation is that currently our logic for upserting a table breaks each operation necessary to upsert a table into a separate comand. ie, we have a create_table, add_column, make_column_nullable, etc. etc. Since we don't construct one large command to run on each table, we'd have to add some special logic to either:

ensure that the columns which need indexes exist
when we go to add_column for one of our target columns, we also add index after the operation is complete

I think this has to be opt-in. The simplest is definitely "add indexes for join columns" and if we run into performance problems with this for folks down the road, we can add a more complex flag which has some threshold.


How do I get autocomplete of hosts to work for an alias or function?

I have a custom function which takes in a hostname argument.  I would like to be able to tab-complete the hostname just like I can with ssh/rsync/scp/etc...  I've tried adding the short alias to my function "wl" to the the line in the common-aliases.plugin.zsh:
zstyle -e ':completion::(ssh|scp|sftp|rsh|rsync|wl):hosts' hosts 'reply=(${=${${(f)"$(cat {/etc/ssh_,~/.ssh/known_}hosts(|2)(N) /dev/null)"}%%[# ]}//,/ })'
And tried doing the same in my .zshrc.  But neither seems to work.
How can I apply the hosts completion to an arbitrary function or alias?

Could you stick that code sample in triple-backquotes so we can see the exact string and it doesn't get interpreted as Markdown formatting? Some stars in there are turning things in to italics.
Like this.

\\zstyle -e ':completion::(ssh|scp|sftp|rsh|rsync|wl):hosts' hosts 'reply=(${=${${(f)"$(cat {/etc/ssh_,~/.ssh/known_}hosts(|2)(N) /dev/null)"}%%[# ]}//,/ })'

I just took the line from the common-aliases.plugin.zsh which I believe provides tab completion for ssh, and added my alias "wl" to the list of commands.  But that doesn't seem to actually work.

Short answer: that zstyle line just customizes the manner in which zsh looks up hosts when it knows it needs them for completion. To tell zsh that your function takes hosts as an argument, do this.
compdef _hosts wl

If only one of your function's arguments takes hosts, then you may want to define your own _wl() completion widget function to go along with the main wl() function that can do more context-sensitive completing.
Long answer: see the Completion System section of the Zsh Reference Manual for all the details of defining completion.

Perfect!  Thank you very much!!!


[feature] forum - show latest post in threads index (#755)

addresses: https://github.com/restarone/violet_rails/issues/721

feat(): showing the latest post in thread preview of threads#index

feat(): added test cases

Co-authored-by: Prashant<EMAIL_ADDRESS>

@alis-khadka LGTM on staging-- thanks for your contribution!


[android] Please check if NAT and UPnP are actually starting.

I've added more alerts to the filters, I've tried forcing it on the settings pack applied to the session and I don't ever get a portmap alert on BTEngine's Inner Listener.
        final SettingsPack sp = session.getSettingsPack();
        sp.setBoolean(settings_pack.bool_types.enable_upnp.swigValue(), true);
        sp.setBoolean(settings_pack.bool_types.enable_natpmp.swigValue(), true);
        sp.setBoolean(settings_pack.bool_types.announce_double_nat.swigValue(), true);
        session.applySettings(sp);

My InnerListener's INNER_LISTENER_TYPES array looks like this:
private static final int[] INNER_LISTENER_TYPES = new int[]{TORRENT_ADDED.swig(),
            PIECE_FINISHED.swig(),
            PORTMAP.swig(),
            PORTMAP_ERROR.swig(),
            DHT_STATS.swig(),
            STORAGE_MOVED.swig(),
            LISTEN_SUCCEEDED.swig(),
            LISTEN_FAILED.swig(),
            EXTERNAL_IP.swig()
    };

@aldenml  last night you mentioned I should try turning on a debug flag on jlibtorrent, but I can't find how to do this on session nor on the libtorrent class. completely forgot how it was and not very easy to find.

You mean logging? https://github.com/frostwire/frostwire/blob/master/common/src/main/java/com/frostwire/bittorrent/BTEngine.java#L166, just pass true and add the relevant constant to the filter (PORTMAP_LOG).

Thanks!

Sweet :)
I/BTEngine(29937): broadcasting search for rootdevice
I/BTEngine(29937): adding port map: [ protocol: tcp ext_port: 40849 local_port: 40849 ]
I/BTEngine(29937): adding port map: [ protocol: udp ext_port: 40849 local_port: 40849 ]
I/BTEngine(29937): found router at: fe80::6eca:8ff:fe0e:a120
I/BTEngine(29937): ==> get public IP address
I/BTEngine(29937): ==> port map [ mapping: 0 action: add proto: tcp local: 40849 external: 40849 ttl: 3600 ]

Some interesting findings with respect to ports. At this point I'm trying to find what the actual port is it that the client would be seeding on.
What the portmap log says in this instance
I/BTEngine(12906): broadcasting search for rootdevice
I/BTEngine(12906): adding port map: [ protocol: tcp ext_port: 54517 local_port: 54517 ]
I/BTEngine(12906): adding port map: [ protocol: udp ext_port: 54517 local_port: 54517 ]
I/BTEngine(12906): found router at: fe80::6eca:8ff:fe0e:a120
I/BTEngine(12906): ==> get public IP address
I/BTEngine(12906): ==> port map [ mapping: 0 action: add proto: tcp local: 54517 external: 54517 ttl: 3600 ]

So port 54517 right?
What BTEngine says it's listening on
Then, since I never got the portmap alerts, I decided to create my x.pe parameters using the port returned by BTEngine.getListenPort() (which does change on every run too, so it's not something hardcoded), that port is different than the one we try to port map, 56094 in this instance:
I/MagnetUriBuilder(12906): creating magnet with:
I/MagnetUriBuilder(12906): 2602:30a:2c88:db10:c2ee:fbff:fe5a:c898%22 : 56094
I/MagnetUriBuilder(12906): 2602:30a:2c88:db10:557:246a:1f6f:442%22 : 56094
I/MagnetUriBuilder(12906): <IP_ADDRESS> : 56094

as a funny note, if we ask BTEngine for it's listen interfaces string (which comes out of the SettingsPack, we just get what was passed during setup, not the actual interfaces.
I/MagnetUriBuilder(12906): BTEngine.listenInterfaces: <IP_ADDRESS>:0,[::]:0

So if we were to somehow get the port on a portmap alert, we should do remote tests to see which port works best, my logic says, the one on the portmap should be good for outside connections. Maybe the one returned by session.listen_port() is good for local transfers.

Yes, 54517 is the port, but in which interface? You are getting different ports due to some unknown reason in your device (the phone I assume), that should not happen and it didn't happen in my device when I tested. Something wrong is happening here. The port mapped in the portmap is the one that it's working in the local port too. If session.listen_port() is different, that's not good.
I would start by figuring out whey aren't you getting the alerts and why it rebinds the port so fast that ends with an inconsistent state.

I'm going to try and print the session.listen_port() when I get that portmap alert to see if at that point in time the ports match, and maybe there's some sort of session pause/resume that might be causing the inconsistency.

so indeed, you're right.
Each interface is trying to bind to a different port.
I/BTEngine(30620): LogAlert:  listening on: [::]:54478 external port: 54478
I/BTEngine(30620): LogAlert:  listening on: <IP_ADDRESS>:52351 external port: 52351
I/BTEngine(30620): LogAlert:  listening on: [::]:42791 external port: 42791

weirdly we see that double attempt on that IPv6 address there, but right after I get this error message:
I/BTEngine(30620): LogAlert: cannot to bind to interface [:: 0] ":: : system": Address family not supported by protocol

And session.listen_port() gives us 54478, the first one on the list.
However, the port mapping seems to be done with the other port 👀
I/BTEngine(30620): PortmapLogAlert: adding port map: [ protocol: tcp ext_port: 42791 local_port: 42791 ]
I/BTEngine(30620): PortmapLogAlert: adding port map: [ protocol: udp ext_port: 42791 local_port: 42791 ]

--
note and question
I read that the IPv6 notation for address:port should be written like this [address]:port, i wonder if your magnet parsing patch took into consideration those squared brackets, see the log alerts, the messages seem to use the right notation. I'll be fixing my x.pe= values to look like this:
x.pe=[fe80::6eca:8ff:fe0e:a120]:52351

what do you think....just kidding :D yes, it parse the endpoint taking care of the brakets, actually I submitted a PR(https://github.com/arvidn/libtorrent/pull/757) to fix a minor parsing bug there.

btw, something is telling me that there could be a subtle bug in libtorrent

I'm looking for a way to enumerate the listening interfaces.
There should be something in session like:
session::getTcpEndpoints(std::vector<tcp::endpoint>& endpoints)
session::getUdpListeningPort(std::vector<udp::endpoint>& endpoints)
and then you could grab from those the listening ports.

btw, so I tested sending the magnet to frostwire desktop, which I suppose was built with the latest jlibtorrent that supports x.pe=, but I felt like it wasn't supporting it because it didn't matter what port I put on the x.pe= addresses, in both cases, I managed to download the torrent info, and then the transfer stayed at 0 Kb/s, however, as soon as I paused the seeding client and seeded again (SeedAction in frostwire-android) the transfer would start immediatly.

Well, at least you managed to download the magnet! right. Yes, the support in RC_1_1 is limited, but it's there. You just need to manage to add the peers part to the url in the params like in this test: https://github.com/arvidn/libtorrent/blob/RC_1_1/test/test_torrent.cpp#L237


Renaming look_ahead maybe?

It might be a joke 🤣 but not sure if it is too late to rename ctx.look_ahead() to ctx.lookahead() since the object is Lookahead or there might be other limitation?

It might be a joke 🤣 but not sure if it is too late to rename ctx.look_ahead() to ctx.lookahead() since the object is Lookahead or there might be other limitation?

For forward compatibility, it may be better to keep the current name. 🙂

Thanks @sunli829 out of my curiosity so .lookahead() is planned to be used for something else in the future?


Release 1.1.0

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.457%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
236

Relevant Lines:
370

💛  - Coveralls


Mongoid6 support

Looks great. It's missing a CHANGELOG entry, https://github.com/mongoid/mongoid-locker/blob/master/CHANGELOG.md.

Same as for #44, fix the build (remove old rubies) and we're good to go.

Didn't see the update notification, thanks! Merging.

@sivagollapalli We could use another maintainer on this project, right now it's just me and @afeld. Interested? Really it's no work other than checking in occasionally and helping any PRs out and maybe a release.


Limit Computation Time

I've got an IP that takes to long to solve. As I modeled it with gurobi previously I know that it reaches a feasible solutions after a short time and spents most of the time without improving the solution.
Is it possible to stop the computation early, e.g. after 20 seconds?

Due to the lack of a timeout, we now changed to the non-commercial SCIP which is free for academic purposes. It does not have any nice JavaScript / node.js interface, so we have to call it via child_processes, but it offers a bunch of settings including timeouts. Moreover, according to these benchmarks, SCIP is one of the fastest non-commercial solvers for mixed integer programs and the included LP solver SoPlex even offers exact rational solutions!

FWIW, I've implemented a timeout for Mixed Integer LPs.
You can incorporate it by updating your model like this:
{
    "optimize": "stuff",
    "options": {
        "timeout": 3000,
    }
}

Which returns whatever the process has after that time has elapsed. I'm gonna close this issue, but feel free to re-open it if this doesn't solve your issue.
Thanks,
-JWW


[Explore] persist options after the datasource is modified

Is your feature request related to a problem? Please describe.
Not sure if this qualifies as a bug or a feature request.
In chart explore view, when you click Edit datasource and save, it clears all the chart options. Even if no changes are made 😮
Describe the solution you'd like
Possible solutions:

Keep all chart options. Running the query could result in an error if the datasource edit significantly changed relevant columns/metrics
Keep all chart options and flag invalid options.
Remove invalid options

Describe alternatives you've considered

Leaving things as they are. Maybe this behavior is intentional/too hard to change?

This was fixed by https://github.com/apache/incubator-superset/pull/10092


Filter default values from widget state

@jdfreder as per discussion.

Woot!

We should probably also be able to get rid of the views list, and the serialization of the cell.


aggregate fixes and features from active contributors

Hey there, @qrkourier, I appreciate the request however late this may be. If you or anyone else can confirm this running fine with their flavor of OS here in the thread for history's sake then I'm happy to merge.


Add release notes for Omni Core 0.0.10

This pull request adds release notes for Omni Core 0.0.10, which resolves #96.
Please leave your comments, if there is anything to update.

Awesome, you're the best! I integrated your suggestions with very minimal changes here and there. :)

We should extract the description, at least for the feature activations, and add it as seperated document. Likewise, the debug log categories should be documented properly (see: #193), and code comments may be added to the catogries. This could be something post 0.0.10 though.
But I was wondering: what do you think about publishing a blog post about the feature activation mechanism? I mean, there isn't much missing in my opinion, maybe a few more words, maybe a link to the key-generation instructions or so, but this could be a good introduction for 0.0.10.
I also think we should publish more details about every feature to activate, primarily to notify users, but also to describe the change. Ideally each feature activation is also documented (and potentially added to the spec at some point).
Which brings me back to the list of outstanding points, which may, or may not be added to the change log, namely the other features:

the MetaDEx
disable crowdsale participations when "granting tokens"
disable DEx "over-offers" and to switch to plain integer math
"send-all" transactions
disable ecosystem crossovers in crowdsale logic

Unfortunally I'm a bit short of time today, and hopefully I find more tomorrow to finalize the RC, so we can start building tomorrow or the day after.

But I was wondering: what do you think about publishing a blog post about the feature activation mechanism? I mean, there isn't much missing in my opinion, maybe a few more words, maybe a link to the key-generation instructions or so, but this could be a good introduction for 0.0.10.

This sounds like a great idea - should I draw something up?

I also think we should publish more details about every feature to activate, primarily to notify users, but also to describe the change. Ideally each feature activation is also documented (and potentially added to the spec at some point).

No arguments here, sounds good :)

Which brings me back to the list of outstanding points, which may, or may not be added to the change log, namely the other features

This is an interesting point actually - I think we should write about them just like we did with OP_RETURN for example, but (might be a bit late to raise this hehe) perhaps 'feature' is the wrong term?  Stuff like Class C, MetaDEx and Send-All are all new features sure, but things like the changes to logic are not really features per se.  I don't really have a better term, but perhaps we may invite criticism for calling logic changes "features" - not really sure, what do you think?

Unfortunally I'm a bit short of time today, and hopefully I find more tomorrow to finalize the RC, so we can start building tomorrow or the day after.

I'm actually interstate this weekend visiting the wife's family, I have my laptop and a copy of my Gitian Builder VM so fingers crossed all should be well, worst case I'll be back at my desktop for Monday.

@zathras-crypto: This sounds like a great idea - should I draw something up?

Sure, this would be awesome! Please let's go though it before publishing though. :)
One of the points I really criticized about previous releases was the lack of raising awareness, so this is a good chance to tackle it. I'm not sure, if this is the best way, but in general, and for the future, maybe we could try to move in the following direction (ideal scenario):

publish new ideas early, preferably before the integration, to get additional input, and to ensure the community won't outright reject it
soon-ish before the activation, describe the new "feature" in greater detail
after the activation, publish specifics, such as the activation transaction, or the exact activation triggering block
publish a follow up, in case it went well, this step might be optional, in case it went south, causes should be analyzed and reflected upon

We may start from step 2 at this point, but right now, it would already be very nice to describe the feature activation mechanism in general. It's new, it's shiny and wasn't used for meta-protocols in the past, so let's tell everyone, haha. :)

As for the release notes, currently we have the following structure:

General intro
Upgrading and downgrading
Important changes and notes
Notable changes
Changelog

The idea behind "important changes" was to have a section for "must read" stuff, such as outlining incompatibilities, or to highlight changes, which may not be expected, basically things "anyone should be aware of". I'm not too amazed be the title though, and ideas for alternatives are welcome.
The "notable changes" are intended to describe non-critical changes, and it's probably self-explanatory.
When thinking about it: ideally the changes that make a major release "major" end up in "important changes", and changes that may be integrated into minor releases end up in "notable changes". As consequence, a minor release shall not have any "important changes" (otherwise it would be a major release).
I agree that "features" are somewhat special, and should deserve a seperate section. Maybe there should be a section called "protocol changes", which lists all new "features"?
I'm also not very sure how to deal with Bitcoin Core specific changes. Some probably qualify as "important", and may explicitly be highlighted, but I don't think it's very useful to rehash everything either.

I'm actually interstate this weekend visiting the wife's family, I have my laptop and a copy of my Gitian Builder VM so fingers crossed all should be well, worst case I'll be back at my desktop for Monday.

Have a good trip! Just to clarify: are you going to read updates in the meantime, or should I just go ahead? I don't want to take away your family time.. :)

Except description for the MetaDEx, the release notes are pretty advanced. A few parts should probably be refined, but I think most things that need to be mentioned are in.

I added the most recent changes and squashed everything.
In the absence of feedback I'm going to merge it within 24 hours.

@dexX7 @zathras-crypto great job! Here are some suggested wording edits for clarity.
change:

An upgrade is mandatory, and highly recommended.

to

An upgrade is mandatory. Prior releases will not be compatible with new behavior in this release.

change:

Transactions with type 4 transfer all tokens in the specified ecosystem from the source to the reference destination.

to

Transactions with type 4 transfer available balances of all tokens in the specified ecosystem from the source to the reference destination.

Is tx type 21 supported or should it be removed from the spec? tx types 25-28 should be added to the spec.

Thanks @marvgmail

Is tx type 21 supported or should it be removed from the spec?

Tx 21 was replaced with 25-28 yep, and tx 21 is no longer recognized by Omni Core (it never was in any released product).  I think @dexX7 opened an issue on spec - to be honest I think the spec is way behind, and the period while we're waiting for feedback between release candidate and release might serve as a good opportunity to bring it back up to current.

Thanks @marvgmail, updated via 46caae8873defb91510a58faacef2baad6d24ad0 and 26b61efb35194cbc3833404fa9f4c5909f9425f8.

Gave another once over, looks good to me.  Very thorough and very informative.
Thanks again dude :)

Happy to hear this, thanks! :)

Beginning my read through now.

Extraordinarily well done, putting this document together.  The descriptions and the changelog are all extremely thorough and well presented. Let’s do it.

Thanks guys, I'm going to merge this after the CI checks passed (d'oh.. hehe).
@zathras-crypto: for the splash screen update I added:
+  - #278 Remove "Omni Wallet" branding in splash


Fix blinking tests

[ ] [Regression] GH-3904 - Should correctly switch to iframe loaded from form
[ ] Upload -> Should clear the upload
[ ] Upload -> Should upload files
[ ] [Regression](GH-856) Test should not hang when redirect occurs after the page is loaded
[ ] [API] t.switchToIframe(), t.switchToMainWindow()->   Should keep context if the page was reloaded
[ ] (https://github.com/DevExpress/testcafe/pull/5104) Scroll -> Events initiated by scroll should have valid properties

Scroll -> Events initiated by scroll should have valid properties started blinking again