HBASE-22861 [WAL] Merged region should get its WAL according to WALProvider

JIRA: HBASE-22861

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
1214
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 3 new or modified test files.

_ branch-1 Compile Tests _

+1
mvninstall
489
branch-1 passed

+1
compile
38
branch-1 passed with JDK v1.8.0_222

+1
compile
39
branch-1 passed with JDK v1.7.0_232

+1
checkstyle
89
branch-1 passed

+1
shadedjars
163
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
37
branch-1 passed with JDK v1.8.0_222

+1
javadoc
39
branch-1 passed with JDK v1.7.0_232

0
spotbugs
211
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
206
branch-1 passed

_ Patch Compile Tests _

+1
mvninstall
119
the patch passed

+1
compile
37
the patch passed with JDK v1.8.0_222

+1
javac
37
the patch passed

+1
compile
39
the patch passed with JDK v1.7.0_232

+1
javac
39
the patch passed

-1
checkstyle
83
hbase-server: The patch generated 1 new + 326 unchanged - 0 fixed = 327 total (was 326)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
170
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
298
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

+1
javadoc
28
the patch passed with JDK v1.8.0_222

+1
javadoc
38
the patch passed with JDK v1.7.0_232

+1
findbugs
167
the patch passed

_ Other Tests _

-1
unit
1888
hbase-server in the patch failed.

+1
asflicense
19
The patch does not generate ASF License warnings.

5401

Reason
Tests

Failed junit tests
hadoop.hbase.regionserver.TestRegionMergeTransaction

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/1/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 2f87f86425fb 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-507/out/precommit/personality/provided.sh

git revision
branch-1 / d2793f1

Default Java
1.7.0_232

Multi-JDK versions
/usr/lib/jvm/java-8-openjdk-amd64:1.8.0_222 /usr/lib/jvm/java-7-openjdk-amd64:1.7.0_232

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/1/artifact/out/diff-checkstyle-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/1/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/1/testReport/

Max. process+thread count
733 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/1/console

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
72
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 3 new or modified test files.

_ branch-1 Compile Tests _

+1
mvninstall
512
branch-1 passed

+1
compile
66
branch-1 passed with JDK v1.8.0_222

+1
compile
41
branch-1 passed with JDK v1.7.0_232

+1
checkstyle
90
branch-1 passed

+1
shadedjars
169
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
43
branch-1 passed with JDK v1.8.0_222

+1
javadoc
36
branch-1 passed with JDK v1.7.0_232

0
spotbugs
166
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
162
branch-1 passed

_ Patch Compile Tests _

+1
mvninstall
112
the patch passed

+1
compile
37
the patch passed with JDK v1.8.0_222

+1
javac
37
the patch passed

+1
compile
39
the patch passed with JDK v1.7.0_232

+1
javac
39
the patch passed

-1
checkstyle
83
hbase-server: The patch generated 2 new + 326 unchanged - 0 fixed = 328 total (was 326)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
153
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
281
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

+1
javadoc
27
the patch passed with JDK v1.8.0_222

+1
javadoc
37
the patch passed with JDK v1.7.0_232

+1
findbugs
156
the patch passed

_ Other Tests _

-1
unit
9475
hbase-server in the patch failed.

+1
asflicense
47
The patch does not generate ASF License warnings.

11880

Reason
Tests

Failed junit tests
hadoop.hbase.client.TestAdmin2

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/2/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 7b42d820793c 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-507/out/precommit/personality/provided.sh

git revision
branch-1 / d2793f1

Default Java
1.7.0_232

Multi-JDK versions
/usr/lib/jvm/java-8-openjdk-amd64:1.8.0_222 /usr/lib/jvm/java-7-openjdk-amd64:1.7.0_232

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/2/artifact/out/diff-checkstyle-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/2/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/2/testReport/

Max. process+thread count
4545 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/2/console

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
116
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 3 new or modified test files.

_ branch-1 Compile Tests _

+1
mvninstall
535
branch-1 passed

+1
compile
53
branch-1 passed with JDK v1.8.0_222

+1
compile
42
branch-1 passed with JDK v1.7.0_232

+1
checkstyle
93
branch-1 passed

+1
shadedjars
167
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
41
branch-1 passed with JDK v1.8.0_222

+1
javadoc
39
branch-1 passed with JDK v1.7.0_232

0
spotbugs
181
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
175
branch-1 passed

_ Patch Compile Tests _

+1
mvninstall
121
the patch passed

+1
compile
39
the patch passed with JDK v1.8.0_222

+1
javac
39
the patch passed

+1
compile
43
the patch passed with JDK v1.7.0_232

+1
javac
43
the patch passed

-1
checkstyle
89
hbase-server: The patch generated 1 new + 326 unchanged - 0 fixed = 327 total (was 326)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
174
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
300
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

+1
javadoc
30
the patch passed with JDK v1.8.0_222

+1
javadoc
40
the patch passed with JDK v1.7.0_232

+1
findbugs
174
the patch passed

_ Other Tests _

-1
unit
9709
hbase-server in the patch failed.

+1
asflicense
60
The patch does not generate ASF License warnings.

12296

Reason
Tests

Failed junit tests
hadoop.hbase.replication.regionserver.TestRegionReplicaReplicationEndpoint

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/3/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 447c075d127b 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-507/out/precommit/personality/provided.sh

git revision
branch-1 / d2793f1

Default Java
1.7.0_232

Multi-JDK versions
/usr/lib/jvm/java-8-openjdk-amd64:1.8.0_222 /usr/lib/jvm/java-7-openjdk-amd64:1.7.0_232

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/3/artifact/out/diff-checkstyle-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/3/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/3/testReport/

Max. process+thread count
4173 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/3/console

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Not related failed UT.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
75
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 3 new or modified test files.

_ branch-1 Compile Tests _

+1
mvninstall
646
branch-1 passed

+1
compile
65
branch-1 passed with JDK v1.8.0_222

+1
compile
41
branch-1 passed with JDK v1.7.0_232

+1
checkstyle
87
branch-1 passed

+1
shadedjars
163
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
37
branch-1 passed with JDK v1.8.0_222

+1
javadoc
38
branch-1 passed with JDK v1.7.0_232

0
spotbugs
172
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
164
branch-1 passed

_ Patch Compile Tests _

+1
mvninstall
120
the patch passed

+1
compile
37
the patch passed with JDK v1.8.0_222

+1
javac
37
the patch passed

+1
compile
41
the patch passed with JDK v1.7.0_232

+1
javac
41
the patch passed

-1
checkstyle
89
hbase-server: The patch generated 1 new + 326 unchanged - 0 fixed = 327 total (was 326)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
158
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
299
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

+1
javadoc
28
the patch passed with JDK v1.8.0_222

+1
javadoc
38
the patch passed with JDK v1.7.0_232

+1
findbugs
170
the patch passed

_ Other Tests _

-1
unit
11097
hbase-server in the patch failed.

+1
asflicense
88
The patch does not generate ASF License warnings.

13732

Reason
Tests

Failed junit tests
hadoop.hbase.master.TestMasterShutdown

hadoop.hbase.replication.regionserver.TestRegionReplicaReplicationEndpoint

hadoop.hbase.client.TestAdmin2

hadoop.hbase.master.TestDistributedLogSplitting

hadoop.hbase.master.TestWarmupRegion

hadoop.hbase.master.cleaner.TestLogsCleaner

hadoop.hbase.regionserver.TestSplitTransactionOnCluster

hadoop.hbase.master.TestAssignmentManagerOnCluster

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/4/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux e6228ceca06a 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-507/out/precommit/personality/provided.sh

git revision
branch-1 / bb31ffa

Default Java
1.7.0_232

Multi-JDK versions
/usr/lib/jvm/java-8-openjdk-amd64:1.8.0_222 /usr/lib/jvm/java-7-openjdk-amd64:1.7.0_232

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/4/artifact/out/diff-checkstyle-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/4/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/4/testReport/

Max. process+thread count
4490 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/4/console

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
1326
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 3 new or modified test files.

_ branch-1 Compile Tests _

+1
mvninstall
507
branch-1 passed

+1
compile
42
branch-1 passed with JDK v1.8.0_222

+1
compile
42
branch-1 passed with JDK v1.7.0_232

+1
checkstyle
93
branch-1 passed

+1
shadedjars
193
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
36
branch-1 passed with JDK v1.8.0_222

+1
javadoc
41
branch-1 passed with JDK v1.7.0_232

0
spotbugs
181
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
177
branch-1 passed

_ Patch Compile Tests _

+1
mvninstall
155
the patch passed

+1
compile
46
the patch passed with JDK v1.8.0_222

+1
javac
46
the patch passed

+1
compile
46
the patch passed with JDK v1.7.0_232

+1
javac
46
the patch passed

+1
checkstyle
90
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
169
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
323
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

+1
javadoc
32
the patch passed with JDK v1.8.0_222

+1
javadoc
42
the patch passed with JDK v1.7.0_232

+1
findbugs
175
the patch passed

_ Other Tests _

-1
unit
10792
hbase-server in the patch failed.

+1
asflicense
61
The patch does not generate ASF License warnings.

14620

Reason
Tests

Failed junit tests
hadoop.hbase.replication.multiwal.TestReplicationEndpointWithMultipleWAL

hadoop.hbase.client.TestAdmin2

hadoop.hbase.master.normalizer.TestSimpleRegionNormalizerOnCluster

hadoop.hbase.client.TestReplicaWithCluster

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/5/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 31d6509eb033 4.4.0-137-generic #163-Ubuntu SMP Mon Sep 24 13:14:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-507/out/precommit/personality/provided.sh

git revision
branch-1 / bb31ffa

Default Java
1.7.0_232

Multi-JDK versions
/usr/lib/jvm/java-8-openjdk-amd64:1.8.0_222 /usr/lib/jvm/java-7-openjdk-amd64:1.7.0_232

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/5/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/5/testReport/

Max. process+thread count
4298 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/5/console

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.hadoop.hbase.master.normalizer.TestSimpleRegionNormalizerOnCluster
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 41.361 s - in org.apache.hadoop.hbase.master.normalizer.TestSimpleRegionNormalizerOnCluster
[INFO] Running org.apache.hadoop.hbase.replication.multiwal.TestReplicationEndpointWithMultipleWAL
[INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 26.84 s - in org.apache.hadoop.hbase.replication.multiwal.TestReplicationEndpointWithMultipleWAL
[INFO] Running org.apache.hadoop.hbase.client.TestAdmin2
[INFO] Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 130.194 s - in org.apache.hadoop.hbase.client.TestAdmin2
[INFO] Running org.apache.hadoop.hbase.client.TestReplicaWithCluster
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 115.657 s - in org.apache.hadoop.hbase.client.TestReplicaWithCluster
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 47, Failures: 0, Errors: 0, Skipped: 0

All failed tests are not related.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
51
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 3 new or modified test files.

_ branch-1 Compile Tests _

+1
mvninstall
512
branch-1 passed

+1
compile
43
branch-1 passed with JDK v1.8.0_222

+1
compile
49
branch-1 passed with JDK v1.7.0_232

+1
checkstyle
100
branch-1 passed

+1
shadedjars
178
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
38
branch-1 passed with JDK v1.8.0_222

+1
javadoc
49
branch-1 passed with JDK v1.7.0_232

0
spotbugs
174
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
170
branch-1 passed

_ Patch Compile Tests _

+1
mvninstall
125
the patch passed

+1
compile
41
the patch passed with JDK v1.8.0_222

+1
javac
41
the patch passed

+1
compile
44
the patch passed with JDK v1.7.0_232

+1
javac
44
the patch passed

+1
checkstyle
90
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
179
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
329
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

+1
javadoc
29
the patch passed with JDK v1.8.0_222

+1
javadoc
43
the patch passed with JDK v1.7.0_232

+1
findbugs
169
the patch passed

_ Other Tests _

-1
unit
7065
hbase-server in the patch failed.

+1
asflicense
25
The patch does not generate ASF License warnings.

9538

Reason
Tests

Failed junit tests
hadoop.hbase.procedure.TestFailedProcCleanup

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/6/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 07dbcafbabb8 4.4.0-157-generic #185-Ubuntu SMP Tue Jul 23 09:17:01 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-507/out/precommit/personality/provided.sh

git revision
branch-1 / 24a821c

Default Java
1.7.0_232

Multi-JDK versions
/usr/lib/jvm/java-8-openjdk-amd64:1.8.0_222 /usr/lib/jvm/java-7-openjdk-amd64:1.7.0_232

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/6/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/6/testReport/

Max. process+thread count
4522 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-507/6/console

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.


Change HashSet to LinkedHashSet in test files and set constraints for statement and tags

Coverage remained the same at 80.167% when pulling 0323b2ff3bc684c3b692ed62795e266c518246ec on jasonvank:milestone-v1.4 into ff3a31d5f4c1d2589de35d0da504c228e0006fe8 on CS2103-AY1819S1-T12-4:milestone-v1.4.


“nom” → “master”

Removes unneeded paths. See http://rakudo.org/2017/10/27/main-development-branch-renamed-from-nom-to-master/

Thanks.


Speed painting

Current coverage is 53.74% (diff: 56.98%)

Merging #206 into dev will increase coverage by 0.31%

@@                dev       #206   diff @@
==========================================
  Files           160        161     +1
  Lines          3403       3407     +4
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1818       1831    +13
+ Misses         1585       1576     -9
  Partials          0          0

Powered by Codecov. Last update 562b51c...a457ef0


[Impeller] Implement pooling of render target textures.

This is primarily necessary for Vulkan but may help Metal too. Xcode does warn of late texture creation even though it is fairly fast. On Vulkan, even memory-less (lazily allocated device-transient textures) take a long time to allocate. This may possibly be because the virtual address space for the texture still needs to be reserved.

The pooling mechanism should probably be tacked on to the resource manager. Currently, the resource manager is a Vulkan thing that we can move to the platform agnostic HAL.

I sorta have mixed feelings about this. Being able to declare your textures as if you're re-allocating them each frame, but having them get automagically reused under the hood would be convenient for EntityPass in particular. OTOH, I'm having trouble conceptualizing how this behavior fits into Impeller's design.
Extending the lifetime of buffers under the HAL seems like it would be difficult to get right on any backend. What would mark the end of the extended lifetime? Since frames aren't really sensible concept under the HAL, we could try tying resource lifetime extensions to impeller::Surface flips... but what if the application doesn't render to a surface?
There's also a lighter concern around predictability. We'd be transitioning to a world where sometimes allocating a RT texture is free and sometimes it's expensive, with little feedback as to why. However, I don't think this is that big of a deal, since the vast majority of renderers that use offscreen RT textures would wind up needing a short application-level cache for RT textures anyhow.

We'd be transitioning to a world where sometimes allocating a RT texture is free and sometimes it's expensive,

This is sort of already the case though. if you allocate too much, or having concurrent work doing allocation you will stall on Vulkan.

I'm not sure if we should necessarily expose this via the allocator, or if this should only be an optimization for render target textures. For decoded images this is unlikely to help.

We'd be transitioning to a world where sometimes allocating a RT texture is free and sometimes it's expensive,

This is sort of already the case though. if you allocate too much, or having concurrent work doing allocation you will stall on Vulkan.

This is sort of a minor concern, but what I mean is that by adding an opaque caching mechanism that varies between backends, renderers may begin relying on free reuse of RT textures between frames, and then run into steep unexpected turbulence as a result. Whereas they would have been better off in all cases on all backends if they'd just managed RT texture reuse more explicitly to begin with.

Yeah I think that makes a lot of sense!

Whereas they would have been better off in all cases on all backends if they'd just managed RT texture reuse more explicitly to begin with.

This is going to be tricky though. At least in Flutter today, applications are unable to manage the allocations as they are all abstracted in the renderer - so its our responsibility to make sure we're being efficient.
Allowing users to manage this themselves for flutter_gpu sounds like a good idea. We should take note of the information we need in order to implement render target pooling in the backend and ensure it is exposed in a reasonable way in the HAL. For example, if we need the fence waiter signals for texture reuse on Vulkan, then we'll need to find a way to expose that.

This is going to be tricky though. At least in Flutter today, applications are unable to manage the allocations as they are all abstracted in the renderer - so its our responsibility to make sure we're being efficient.

By "application" I meant "renderer above the HAL"; in Flutter's case, the Entity Framework. I don't think it would be appropriate for Flutter apps to manage RT texture lifetimes. 😛

We should take note of the information we need in order to implement render target pooling in the backend and ensure it is exposed in a reasonable way in the HAL. For example, if we need the fence waiter signals for texture reuse on Vulkan, then we'll need to find a way to expose that.

Is reusing an offscreen RT texture on contiguous frames not currently safe on the Vulkan backend? Mind giving a rundown on why that's the case? 🤔 Since EntityPass::OnRender is restricted to one thread, this seems like something we should be able to make safe without incurring performance penalties, unless we're allowing multiple frames' encoding jobs to smash into each other.

Safe is definitely the wrong word. I think Safety only comes into play if we were aliasing the texture allocations. What I am worried about is performance - but without any prototypes to evaluate this yet perhaps I'm worried about nothing. Here is the quandary:
Lets assume that we have more than one frame in flight - that is we could be encoding one frame while the GPU is still working on the previous frame.
While encoding frame one, we create a glyph atlas texture at some size NxN. We transition to a copy src, We upload data to it, and then encode a transition from a copy src to sample texture (forget the exact layout transition terminology).
While encoding frame two, while the GPU is still working on frame one. We decide we need a new MxM glyph atlas texture (where M < N), and so we recycle the texture from frame one. First we transition the texture to a copy src... what happens?

The command along with the data to copy gets queued up and executed after frame one is finished?
The layout transition blocks until the previous frame is finished?

I don't really have any idea. If we build a quick experiment to just recycle if we can from frame N - 1 we should be able to see if we block in the layout transitions

Oh, we're talking about two different things here. The glyph atlas isn't a render target texture; it's written by the host and transferred each frame.
It wouldn't be possible for us to at least block the write/transfer on the previous frame's sampling of the atlas on the GPU. So for that, I suspect we'd be better off spending extra memory to flip between 2 textures (or more, depending on the frame constraints).
But for offscreen color RT textures (as well as any non-transient depth-stencil textures on Metal/Vulkan), these should be possible to reuse across contiguous frames without limiting performance.

Right, I'm using the glyph atlas as an example but we need to do a layout transition any time a render target is sampled by the parent pass. My concern isn't specific to upload data but more about the semantics of layout transitions.

I wanted to build a prototype to evaluate my concerns above, its fairly simple: https://github.com/flutter/engine/pull/44519
This does not attempt to do anything other than match the exact size of render targets, but it seems to have a good number of cache hits per frame.  that said, I seem to run into two issues:

Advanced blends in flutter wonderous app are causing the validation error below. i don't know if that is due to the slow performance leading to the textures being "in use" longer (essentially confirming that we need to wait until the fencewaiter fires?)

E/flutter (21811): -----------------------------------------------------------------
E/flutter (21811): [ERROR:flutter/impeller/base/validation.cc(49)] Break on 'ImpellerValidationBreak' to inspect point of failure:
E/flutter (21811): --- Vulkan Debug Report  ----------------------------------------
E/flutter (21811): |                Severity: Error
E/flutter (21811): |                    Type: { Validation }
E/flutter (21811): |                 ID Name: VUID-VkWriteDescriptorSet-descriptorType-00337
E/flutter (21811): |               ID Number: -1779207809
E/flutter (21811): |       Queue Breadcrumbs: [NONE]
E/flutter (21811): |  CMD Buffer Breadcrumbs: [NONE]
E/flutter (21811): |         Related Objects: DescriptorSet [23520752741405584] [UNNAMED]
E/flutter (21811): |                 Trigger: Validation Error: [ VUID-VkWriteDescriptorSet-descriptorType-00337 ] Object 0: handle = 0x53900000005390, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; | MessageID = 0x95f3717f | vkUpdateDescriptorSets() pDescriptorWrites[1] failed write update validation for VkDescriptorSet 0x53900000005390[] with error: Write update to VkDescriptorSet 0x53900000005390[] allocated with VkDescriptorSetLayout 0x45140000004514[Descriptor Set Layout TextureFill Pipeline V#2] binding #64 failed with error message: Attempted write update to combined image sampler descriptor failed due to: ImageView (VkImageView 0x4f000000004f[ImpellerOnscreenResolve]) with usage mask 0x12 being used for a descriptor update of type VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER does not have VK_IMAGE_USAGE_SAMPLED_BIT set.. The Vulkan spec states: If descriptorType is VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE or VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, the imageView member of each element of pImageInfo must have been created with VK_IMAGE_USAGE_SAMPLED_BIT set (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkWriteDescriptorSet-descriptorType-00337)
E/flutter (21811): -----------------------------------------------------------------
E/flutter (21811): [ERROR:flutter/impeller/base/validation.cc(49)] Break on 'ImpellerValidationBreak' to inspect point of failure:
E/flutter (21811): --- Vulkan Debug Report  ----------------------------------------
E/flutter (21811): |                Severity: Error
E/flutter (21811): |                    Type: { Validation }
E/flutter (21811): |                 ID Name: VUID-VkImageMemoryBarrier-oldLayout-01211
E/flutter (21811): |               ID Number:<PHONE_NUMBER>
E/flutter (21811): |       Queue Breadcrumbs: [NONE]
E/flutter (21811): |  CMD Buffer Breadcrumbs: [NONE]
E/flutter (21811): |         Related Objects: Image [80264348827721] [ImpellerOnscreenResolve]
E/flutter (21811): |                 Trigger: Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01211 ] Object 0: handle = 0x490000000049, name = ImpellerOnscreenResolve, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x3e9335e3 | vkCmdPipelineBarrier(): .pImageMemoryBarriers[0].oldLayout Image barrier Layout=VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL is not compatible with VkImage 0x490000000049[ImpellerOnscreenResolve] usage flags 0x12. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, and oldLayout or newLayout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL then image must have been created with VK_IMAGE_USAGE_SAMPLED_BIT or VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01211)

This doesn't work unless the sizes match exactly, because we need to either alias the memory or re-create some parts of the texture. This would also imply that we need to wait for the fencewaiter to fire.

Right, I'm using the glyph atlas as an example but we need to do a layout transition any time a render target is sampled by the parent pass. My concern isn't specific to upload data but more about the semantics of layout transitions.

Assuming we're talking about reusing textures between contiguous frames and not within the same frame, I think the additional image barrier we'd need to insert shouldn't block on anything unless the previous frame is already way too slow to be under budget.
As long as we're properly setting up barriers in-between each use of the image resource, that should be all that's needed to gate usage of the resource across frames. It shouldn't be necessary to e.g. wait for all work of the previous frame to complete -- especially not host-side.

Advanced blends in flutter wonderous app are causing the validation error below. i don't know if that is due to the slow performance leading to the textures being "in use" longer (essentially confirming that we need to wait until the fencewaiter fires?)

I think those validation errors are indicating that the layout transition is invalid because the texture is not allocated with the correct usage flags to be compatible with the destination layout. We'd need to also include the usage bitmask in the hash when reusing textures (probably the whole TextureDescriptor).

I think the errors I hit were unrelated, updating and rebuilding seems to have removed them!

Less hacky version with no validation errors: https://github.com/flutter/engine/pull/44527
Unfortunately this still renders incorrectly on the advanced blends in wonderous, parts of the texture seem to be missing actually. Might try tracking via the fence waiter too

As a note for the issue above, and for precision in terminology, we're not pooling in the Vulkan implemenation. Vulkan requires that lazily allocated ( aka memoryless ) textures receive dedicated allocations, and may require dedicated allocations for textures based on their size.

This change improved worst frame time on the new gallery:
https://flutter-flutter-perf.skia.org/e/?queries=device_type%3DSM-G973U1%26test%3Dnew_gallery_impeller__transition_perf&selected=commit%3D36334%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DSM-G973U1%252Cdevice_version%253Dnone%252Chost_type%253Dlinux%252Csub_result%253Dworst_frame_rasterizer_time_millis%252Ctest%253Dnew_gallery_impeller__transition_perf%252C
On the advanced blend benchmark (which has significant usage of large offscreen textures), the numbers improved dramatically:
https://flutter-flutter-perf.skia.org/e/?queries=test%3Danimated_advanced_blend_perf__timeline_summary&selected=commit%3D36338%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DSM-G973U1%252Cdevice_version%253Dnone%252Chost_type%253Dlinux%252Csub_result%253Dworst_frame_rasterizer_time_millis%252Ctest%253Danimated_advanced_blend_perf__timeline_summary%252C


Review HGNCId - LocusId associations

Somehow mistakes have been made for the associations between gene names (LocusId) and HGNCid. We discovered this in Lund when a gene panel contained only the gene CBL but the STR module displayed results for both CBL and BEAN1. At a quick review I notice that BEAN1 and CBL both have assigned HGNCId 1541 (correct for CBL but not for BEAN1). Further down in the stranger list CSTB and DAB1 both have 2482 (correct for CSTB but not for DAB1). It's possible that there are more discrepancies, I haven't done a systematic check, so please review the entire catalog.

Thank you - well spotted! We will correct them and run a check for the others before releasing a new version.

I have now also added a couple of verification scripts for the variant catalogs, one of which will check HGNCId and gene symbol against genenames.org (HGNC) so we hopefully don't have this again. Also note that the DAB1 RU was pretty bad as well - a revcomp mistake. And BEAN1 is still untested for lack of a positive control.
Just throwing a thought out: are you well on top of which ones are highly uncertain (I guess basically the ones you would not have DNA on the shelf for) or would it help if we device some kind of notation marking which ones have seen more proper verification?

I think a "verification flag" may be helpful.


Rendering a image in openseadragon at its original pixel resolution

Hi,
We are trying to open a simple Jpeg image at its original resolution without having the image stretched to the viewport. We have tried all the default zoom settings and they do not seem to do what we are asking. We also tried setting viewer.viewport.zoomTo() but it only works if we set a timeout. If we do not set a timeout the zoomTo doesn't seem to do anything.
Are there any events that OpenSeadragon emits that will fire after an image is already loaded so that the zoom can then be set after the image is loaded?
Also are there any settings that can be specified to load the image at its Original Resolution?
Thanks!

Yes, opening the image is asynchronous, so you need to wait for the open event. You can use imageToViewportZoom to find out the appropriate zoom for the original resolution. Like so:
viewer.addHandler('open', function() {
  var zoom = viewer.viewport.imageToViewportZoom(1);
  viewer.viewport.zoomTo(zoom, null, true);
});

Excellent! That worked perfectly!
Thanks so much Ian, I really appreciate it! 👍


Build javadoc in Travis

If javadocs are needed for releases, they should be built in Travis.  See #452 .

I think https://github.com/twosigma/webtau/blob/master/pom.xml#L604 is not correct.  I think java.home will point to a jre usually which won't have javadoc.

Wait, how did it work before?

This line:
                        <javadocExecutable>${java.home}/bin/javadoc</javadocExecutable>

Is new since the last release.  1.13 did not have this: https://github.com/twosigma/webtau/blob/1.13/pom.xml
The PR that added it is https://github.com/twosigma/webtau/pull/430 but I'm not sure that specific bit of configuration is needed.  Docs say it's optional so I would suggest we remove it and let Maven figure out where to get javadoc from: https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#javadocExecutable

Removed the javadocExecutable, waiting on travis


React redux prototype

[x] Create Redux prototype
[ ] Create a component for the header
[ ] Create a component for filter buttons
[ ] Create a component for the ward bar
[ ] Create a component for the faction switch
[ ] Create a component for the camp bar
[ ] Create a component for the truesight bar
[ ] Create a static component for the map
[ ] Hook up Redux actions to components

I'd suggest you merge this branch and use a new one for the tests, for you're basically done with prototyping the app using Redux. What do you think?

You have an open list of checkboxes though. Well, I'll see what you decide :+1:

There's a little more I want to add to it before I merge it.


Token billing: createCard(), updateCard(), deleteCard()

See core OmniPay documentation:
https://github.com/thephpleague/omnipay#token-billing
This driver uses:

registerToken() for createCard()
completeRegistration() to complete registerToken (should probably be completeCreateCard())
TokenRemoval request for deleteCard()
createToken when generating a card token during authorize instead of (perhaps) createCard
token to pass in a saved token during authorize instead of cardReference

These now need knocking into shape for consistency with other gateways (at least for consistency with the core documentation).

OmniPay Common has both get/setToken and get/setCardReference. I'm going to assume they can be used interchangeably, so will just stick to "token" here for now.

Hi Jason, that's not strictly correct.  cardReference is the correct parameter. token is used for things like oAuth access tokens that are part of the authentication process. See PayPal REST  for an example. Some gateway plugins do use them interchangeably but that's not the correct usage for token.

Thanks for the clarification. I'll fix that.

Okay, I'm going for:

$gateway->createCardReference() to create a standalone card reference (gets card details from the user and generates a card reference for it, stored at Sage Pay.
$gateway->deleteCardReference() to tell Sage Pay to forget a stored card reference.
completeRegistration() for handling the return from a Server createCardReference() has been merged into acceptNotification() (i.e. one notification handler to handle all Server callbacks).
The parameter on payments to tell Sage Pay to create a card reference with a payment is now set/getCreateCardReference()
The parameter on payments to tell Sage Pay to store (for future use) a card reference with a payment is now set/getStoreCardReference()

@delatbabel where can we discuss gateway implementations settling on the correct usage of token vs cardReference? Do you know if this will be cleaned up in Omnipay 3?

I suspect you may need to start a new issue here.

Just to note, these changes leave all the old "token" based method names active, but just mark them as deprecated. The intention is to remove them in OmniPay 3.0.

In release 2.4.0


Add support for level-based DCs to inline @Checks

I'm not a fan of this approach. I'd rather integrate into foundry itself and make level based a math function (instead of @self.level stuff). Maybe<EMAIL_ADDRESS>"rare") with the signature of levelDC(level: number, adjustment?: Rarity | Adjustment) .


Return mention of entity in the returned text

The original text can be obtained by TEXT(?text), but seems ?text has the same behavior. Is there a way to get the entity mention in the text or the original text record id?
For example,
PREFIX fb: <http://rdf.freebase.com/ns/>
SELECT TEXT(?text) SCORE(?text) WHERE {
 ?text ql:contains-entity fb:m.05b6w .
}
LIMIT 100
ORDER BY DESC(SCORE(?text))

returns
The crew of Apollo 11 : Commander Neil A. Armstrong , Command Module pilot Michael Collins , Lunar Module pilot Edwin E. Aldrin , Jr .

Is there a way to get the mapping of Neil A. Armstrong to m.05b6w in this sentence?

There is currently no way to extract the mention directly. I think this could be implemented with the #175 proposal and special mention predicates on the text records. Sadly, due to other priorities there is currently no one actively working on this.

Oh, that's too bad. I check the document for +text support, so the Wordsfile is used to build index, but the mapping of mention and entity are not kept and actually the order of lines does not matter right? Docsfile contains the real sentences, which is returned as ?text. If that's the case maybe I can just keep all information needed in that file.
I think the extraction of mention will be very useful, especially when preparing data for many machine learning models.

I am currently going through many old issues to check if they still have relevance.

Qlever could in principle store the not only the mapping from entity to the texts that contain those entities but additionally the start and end markers. This would require changes not only internally, but also in the input format. If we want to implement this, we should make this option configurable, as it would possibly impact the performance of queries that don't use the position and would basically double the size of the TextIndex on disk.
The actual question is, how beneficial this would be. I can see some use in a UI that then colors the  entity mentions.
I particular I would not use this for machine learning models because it is exactly the other way round: You typically need some kind of (often learning-based) entity linking tool that creates the input to QLever. These tools might or might not associate an entity mention with  specific place in the text.
In summary I can see some (however limited) usage of your request, but not in the way you intended it.
I am sorry, that it took so long to pick this up again, If you still are working or interested in this field, please contact us again (here or via email). Especially we also have people working on EntityLinking in our group.

Closing this because the user did not report back.


[AutoPR cognitiveservices/data-plane/CustomImageSearch] Add cognitiveservices\data-plane\CustomImageSearch\readme.typescript.md

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/4273

(message created by the CI based on PR content)


Stuck at Installing dependencies

After installing Flutter, Dart and node.js, following all intermediate steps. I've tried to run:
dart parabeac.dart -k <> -f <>
It begins to install dependencies and has been this way for over an hour. Multiple reboots and network diagnostics were done, but it still won't progress further.
 Installing Parabeac-core and its dependencies

Alright, we are going to take a look to this issue.
Can you tell us which version of Dart & node.js are you using?


Make alternative Layout - With blown up profile image (fit screen)

Select video - thumbnail, covers checkbox on post create


Refactoring(FSM, errors.Op): Refactoring of FSM and error.Op messages

Transition map initialization:

	// Transition map
	transitionMap := make(map[Event]reflect.Method)
	init, _ := reflect.TypeOf(c).MethodByName(InitializeMethodName)
	// event -> Initialize
	transitionMap[Initialize] = init

	serve, _ := reflect.TypeOf(c).MethodByName(StartMethodName)
	// event -> Start
	transitionMap[Start] = serve

	shutdown, _ := reflect.TypeOf(c).MethodByName(ShutdownMethodName)
	// event -> Stop
	transitionMap[Stop] = shutdown

	c.FSM = NewFSM(Uninitialized, transitionMap)

I think that it should be a separate function and FSM init should be like: c.FSM = initFSM(InitialState, transitionMap, states)
2. Uniform error messages. At the moment I can see different variants:

errors.Op("NewContainer") (capital first letter, camel form)
errors.Op("register all") (lower case, space)
errors.Op("internal_init") (underscore)
All operations inside the errors should be in form of lower case and words separated by space.

Done in v2


Methodology that uses monthly data directly, with an adjustment for variable billing cycle lengths

Caltrack handles monthly data by apportioning monthly usage to daily values, then fitting regression models to the daily data. To reduce data processing and computational burden, we would like to consider a methodology that uses monthly data directly, with an adjustment for variable billing cycle lengths.
We propose to include a monthly model specification (hdd, cdd, intercept terms) that uses monthly data directly. Monthly usage is divided by the number of days in billing cycle before fitting the model, to yield average usage per day in each billing period.

Agreed. Using the daily average energy usage for each monthly observation is a better way to handle the variable billing cycle length issue. It preserves the original form of the data and the real number of observations in the time series.

Proposed test methodology:

Caltrack monthly models will be fit to the baseline period usage data. These models convert billing data to daily values and fit a model to the daily data.
A second model will be fit to the same data, but will include as independent variables:

usage per day (i.e. usage during a billing period / number of days during that billing period)
average degree days (i.e. total degree days during a billing period / number of days during that billing period)

Model fit statistics will be calculated on the reporting period data (out of sample) for all buildings, yielding two sets of building-level model fit statistics: one for the default modeling method and the second for the new method.

Acceptance criteria:

Model fit statistics for the two approaches will be pairwise compared using a statistical test (e.g. paired t-test). If differences in model fits between the two approaches are deemed to be due to chance (i.e. p>0.1), then the new method will be added to the Caltrack monthly spec as an alternative modeling approach for billing data.

Using daily average energy use for each billing period requires a weighted regression or an optimization routine to avoid model bias when converting back to the billing period length.  This is pretty easy, so I am unclear why the "monthly" usage was converted to daily values.

@bkoran This is right. I'm going to try to dig up the CalTRACK 1.0 discussion to recall the specifics of what we considered.

RESULTS
Background
Modeling using billing data was underspecified in Caltrack 1 (availability of daily data was assumed for the default methods).
Recommendations
We are proposing the following method for using billing data be clarified in the Caltrack specification.

Calculate the number of days in each billing period n.
Calculate the average usage per day (UPD) in each billing period. This is calculated by dividing the total usage during the billing period by n.
Calculate the average degree days per day during each billing period. This requires aggregating individual degree days for the entire billing period then dividing by n.
Use weighted least squares regression when fitting candidate models. Pass the daily average usage and degree days as the independent variables and use the corresponding n as the weight for each billing period.

Excellent.  FWIW, an alternate approach that could be useful depending upon how things are implemented is to use the independent variables as described, and use a minimization routine to minimize RMSE while requiring the monthly bias be zero.  Monthly bias being the bias estimated after converting the modeled kWh/day back to monthly billing periods by multiplying by n.  I mention this because a minimization routine may be implemented for interval models.

Technically you're not estimating a weighted least squares regression but only weighting each daily observation with the number of days in the billing cycle. Correct?

We're recommending using weighted least squares with the number of days ni as the corresponding weights for each billing cycle i. This is equivalent to using each daily observation ni times in the regression.

Hi Hassan,
MY only concern was with the use of the words “weighted least squares” which is normally associated with addressing the problem of heteroskedasticity.
Regards,
Rick
From: hshaban<EMAIL_ADDRESS>Sent: Tuesday, March 06, 2018 12:04 PM
To: CalTRACK-2/caltrack
Cc: rsridge; Comment
Subject: Re: [CalTRACK-2/caltrack] Methodology that uses monthly data directly, with an adjustment for variable billing cycle lengths (#67)
We're recommending using weighted least squares with the number of days ni as the corresponding weights for each billing cycle i. This is equivalent to using each daily observation ni times in the regression.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/CalTRACK-2/caltrack/issues/67#issuecomment-370910036 , or mute the thread https://github.com/notifications/unsubscribe-auth/Ai2m6xxG5eUf68fUEiceDB088uzJsYccks5tbuu5gaJpZM4R1afH .  https://github.com/notifications/beacon/Ai2m66sQrXAW-Km81SSTfKtDDwI44832ks5tbuu5gaJpZM4R1afH.gif

Good point, Rick. Weighted least squares is typically used to deal with heteroscedasticity, but in that case the weights are set as 1/variance (or some proxy for that). I don't think there's a limitation on the weights you can use with generalized weighted least squares and, on the other hand, some software packages offer WLS just by adding a weights argument to an OLS function. Overall, I agree with you that we should be clear with terminology in the actual Caltrack specification. I'll clarify in the documentation that we are referring to a regression that is carried out with number of billing period days as the weights, not the (sometimes default) regression used to deal with heteroscedasticity.

Thanks, Hassan.
-Rick
From: hshaban<EMAIL_ADDRESS>Sent: Tuesday, March 06, 2018 1:26 PM
To: CalTRACK-2/caltrack
Cc: rsridge; Comment
Subject: Re: [CalTRACK-2/caltrack] Methodology that uses monthly data directly, with an adjustment for variable billing cycle lengths (#67)
Good point, Rick. Weighted least squares is typically used to deal with heteroscedasticity, but in that case the weights are set as 1/variance (or some proxy for that). I don't think there's a limitation on the weights you can use with generalized weighted least squares and, on the other hand, some software packages offer WLS just by adding a weights argument to an OLS function. Overall, I agree with you that we should be clear with terminology in the actual Caltrack specification. I'll clarify in the documentation that we are referring to a regression that is carried out with number of billing period days as the weights, not the (sometimes default) regression used to deal with heteroscedasticity.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/CalTRACK-2/caltrack/issues/67#issuecomment-370933836 , or mute the thread https://github.com/notifications/unsubscribe-auth/Ai2m63J4NuKrpU-HuZAVEGrcKgndgB29ks5tbv7egaJpZM4R1afH .  https://github.com/notifications/beacon/Ai2m6579S_q9k6mmf0RJry4lMQhL11sNks5tbv7egaJpZM4R1afH.gif

This update has been integrated in CalTRACK 2. Closing this issue


Support for .meb version <IP_ADDRESS> (Fast and Furious Crossroads, Project CARS 3)

Hi!
First of all, thanks for that project, you are genius. Really.
Can you please add the support for version <IP_ADDRESS> of .meb files (which used in such games like Fast and Furious Crossroads, Project CARS 3)?
The main difference in the header.
In earlier versions header size was 8 bytes, in that version its size is 12 bytes.
I attach an example of .meb file to research.
acura_nsx_01_body_loda_md.zip
P.S.: (maybe I should create another PR for that, don't know) Fast and Furious Crossroads from PS4 have another .meb format, if you're interested - let me know. I have some (but not all) information about it.
Regards, Mike.

Addressed in 6d9dbd474552b9b986ae1586ef2e645dc803a886


Pyactuator showing 9 threads when running single thread in threads.count

Hi, first, this plugin is amazing, congratulations!!
Well, I'm using with Flask app serving with waitress.
When I run with one thread it shows 9 on pyctuator, when run with two thread it shows 10 on pyctuator and so on. Is this right?

Hi @ericsouza , thank you for your feedback!
Under the hood, Pyctuator uses sys._current_frames() to obtain a list of current threads and then introspect each one.
The documentation on sys._current_frames() states (somewhat enigmatically) that:

This function should be used for internal and specialized purposes only.

without specifying what the valid use cases are.
I'm not familiar with waitress, but I can imagine it having some background threads working to collect metrics, garbage collect, serve debug APIs, etc. Looking at their documentation, it seems that threads configures "The number of threads used to process application logic (integer).", so maybe they have some other threads which are not for application logic...
Can you share a screenshot of the threads you see, as well as the configuration you use?
If there's a bug in the threading module's code we'd be happy to find it and fix it, so the more details you can give us - the better!

Hey @MatanRubin. Well, it's probably something that I don't know about the way threads works on python (I actually am a new developer). I tried just using flask run with debug disabled just and it shows 10 threads at thread.count
Below is my pyctuator/metrics/thread.count json output :
{
"availableTags": [
],
"baseUnit": "Integer",
"description": null,
"measurements": [
{
"statistic": "COUNT",
"value": 10
}
],
"name": "thread.count""
}
I'm not sure of what you mean by show my the threads, you mean threads on my machine with ps -ef ?

Threading in Python is an interesting topic. In CPython threads are not OS threads, but virtual threads - they all run on the same OS thread. This is a good resource to start reading about the subject.
Note that Pyctuator shows you the thread count under the metrics endpoint, and you can also see actual stack traces for each thread using the threaddump endpoint.
For example:

If you're using Spring Boot Admin you can see this visually under the "Thread Dump" tab:

And if you click a thread you can see its stack trace:

To get all of this working quickly you can take a look at the Flask Pyctuator Example

Ow! Such amazing things!! Thank you @MatanRubin. I will read the resource and close the topic. 😁


mmx related target specific option mismatch

This might be related to other things that are already reported and being worked on, but I wasn't really sure so I opened a new bug here.
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/equalization/s
rc/equalizer_rrrf.o src/equalization/src/equalizer_rrrf.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/crc.o
src/fec/src/crc.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec.o
src/fec/src/fec.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec_co
nv.o src/fec/src/fec_conv.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec_co
nv_poly.o src/fec/src/fec_conv_poly.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec_co
nv_pmatrix.o src/fec/src/fec_conv_pmatrix.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches     -c -o src/fec/src/fec_conv_punctured.o src/fec/src/fec_conv_punctured.c
In file included from src/dotprod/src/dotprod_rrrf.mmx.c:50:0:
src/dotprod/src/dotprod_rrrf.mmx.c: In function ‘dotprod_rrrf_execute_mmx’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
 _mm_hadd_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/dotprod_rrrf.mmx.c:203:9: error: called from here
     sum = _mm_hadd_ps(sum, z);
         ^
In file included from src/dotprod/src/dotprod_rrrf.mmx.c:50:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
 _mm_hadd_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/dotprod_rrrf.mmx.c:204:9: error: called from here
     sum = _mm_hadd_ps(sum, z);
         ^
make: *** [<builtin>: src/dotprod/src/dotprod_rrrf.mmx.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
 _mm_addsub_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
         s = _mm_addsub_ps( ci, cq );
           ^
make: *** [<builtin>: src/dotprod/src/dotprod_cccf.mmx.o] Error 1
In file included from src/dotprod/src/sumsq.mmx.c:49:0:
src/dotprod/src/sumsq.mmx.c: In function ‘liquid_sumsqf’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
 _mm_hadd_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/sumsq.mmx.c:85:9: error: called from here
     sum = _mm_hadd_ps(sum, z);
         ^
In file included from src/dotprod/src/sumsq.mmx.c:49:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
 _mm_hadd_ps (__m128 __X, __m128 __Y)
 ^
src/dotprod/src/sumsq.mmx.c:86:9: error: called from here
     sum = _mm_hadd_ps(sum, z);
         ^
make: *** [<builtin>: src/dotprod/src/sumsq.mmx.o] Error 1

Are you running the master branch?

1.3.0

Can you please document what cpu features are needed so I can update the deps in gentoo?
And then a release tag if at all possible.

It's less to do with features needed than having the right compiler flags. See this patch https://github.com/jgaeddert/liquid-dsp/pull/65
And hopefully Joseph does make a new release with this fix in it :)

Ahh, so it's auto testing for cpu arch and setting the cflags appropriately?  Won't that break binary packages for all distros?

I don't know what's typical for distributions to do. Are there still any running computers left on this planet without SSE2? ;)
You can work around this by using standard cross-compile flags for generic x86. I imagine this sort of practice would be fairly standard for someone making a package, but I've never done that specifically so I don't know

It looks like the configure script is testing for support in the current cpu and then enabling the flags.  I have no idea how to use "standard cross-compile flags" to bypass that happening.  I'd be grateful for a lesson though.

Hah, I'm not entirely sure either. But I do know that when I've chosen compile target as arm or x86 on android, it doesn't enable the SSE features. But I don't know the nitty gritty of how autoconf actually disables that check :(

Oh, oops, misread what you said
I think what you might want is something like ./configure --host=x86_64-pc-linux-gnu-gcc? Looking back at my build scripts I believe --host bypasses local arch testing

In gentoo we typically offer flags the user can set to enable certain cpu features when applicable.  Is there a way to set the flags that I want to rather than let it auto-detect?  If not, I can try to dig up some examples of how it's done now.

I have no idea there, unfortunately. I'm not the project owner, just someone enthusiastic about it
You might have some luck checking config.ac to see if it takes any flags like that

I'm certainly not an expert on detecting compiler options either! If there were a standard method for doing this I don't think it would be a problem, but it seems scripts, package managers, etc. all have different expectations for how to achieve this. I'm open to suggestion. Maybe CMake is all it's cracked up to be?

@jgaeddert afaik, the "correct" way to do this is to have an --enable-mmx type flag for each thing you want to enable rather than attempting to auto-detect.  This way, you can set the default to be autodetect but packagers can override the default with their needed option.  Would that be possible?

Yes, I think that would be reasonably simple.


Create SECURITY.md

Hey there!
I belong to an open source security research community, and a member (@srikanthprathi) has found an issue, but doesn’t know the best way to disclose it.
If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.
Thank you for your consideration, and I look forward to hearing from you!
(cc @huntr-helper)

cc @luisza

His, sorry the delay in answer, I create a security policy (and SECURITY.md file), also you can contact me at luisza14 {at} gmail.com, I will see your issue as soon I can.

@luisza - I will get that sent to your e-mail shortly - thanks for the response! ⚡
Just for reference, the report can be found directly here:
https://huntr.dev/bounties/725e2c5c-594e-4802-a30e-41c6cd64384e/

@JamieSlome Could you share the report with me as well please? I logged in via huntr.dev, but I don't seem to have access.

@captn3m0 - are you sure you have push access to the repository?
I'd recommend visiting the URL again and just refreshing. Let me know if this does not work for you ❤

I have also sent an e-mail to the address stated in the SECURITY.md.


Inspired by warrick ?

does wayback-machine-scraper want to be a replacement for warrick ?
to what extent is it inspired or based on warrick ?
http://timetravel.mementoweb.org/

It's not inspired or based on warrick at all, I had never seen that project until you posted it. Skimming through their README, warrick seems focused on recovering a site at a specific point in time. That behavior is possible with wayback-machine-scraper, but it's also possible to download multiple versions of a page, specify time ranges, and filter based on regular expressions. The core functionality of wayback-machine-scraper is also made accessible through the scrapy-wayback-machine Scrapy middleware, so it's easy to integrate into Python/Scrapy projects. I wouldn't say that wayback-machine-scraper is aiming to be a replacement for warrick or any other project, just that they're projects in similar problem domains with different interfaces and slightly different target use cases.


JS and CSS assets not found after deployment to heroku (production)

In a plain Vanilla SANE stack I tried the deployment to heroku. While working locally without a problem, the JS and CSS asset lead to 404 on heroku. The backend API is working, though.
Examples:
 >> 404
 >> 404
I did try heroku buildpacks (ember and node.js), but I do not have enough experience.
How can this be fixed?
Thank you.

So are you trying to serve your ember app through sails? The most simple way right now is to just run ember build --environment=production --output-path=../server/assets/ in your client folder, check the new files in and then push the app to heroku like any sails app.

Hi,
Maybe something like the project: https://github.com/rwz/ember-cli-rails does. It puts the ember-cli builds automagicly in the backend public dirs. It comes handy when having multiple frontend apps.
Thanks for the awesome project!

@alexjp That is a good call and there will something better be coming.
In regards to this issue, simple answer: delete the .sailsrc file in your server  folder.
Long answer: It turns out that because the grunt hook is disabled sails does not serve any assets file - this is not an issue if you use something like nginx to server your assets. But it does if you just use sails lift. Will have to find a proper solution for that.

Just submitted https://github.com/balderdashy/sails/pull/2543 which would be one way to solve the issue on sails level.

Thanks for your efforts, but it seems we are not quite there.
A completely newly generated SANE stack without modification delivers on port 1337 "Welcome to your backend!". I added just a img tag linking to a pic in the images folder created during "sane generate". Even this image returns 404. So it is not specific to ember.
In detail:
I modified the index.html with a relative path to the image:
<img src="images/alyne_logo.png"/>```

Then: sails lift.

On the sails console it reads:
GET / 200 1.918 ms - -
GET /images/alyne_logo.png 404 4.170 ms - 9

A .tmp/public folder is not created either. It is served from the assets folder.

Hmm, it does work for me when I delete the .sailsrc file that is odd - but there seems to be a better solution. Open up your server/.sailsrc file and change it to:
{
  "hooks": {
    "grunt": false
  },
  "paths": {
    "public": "assets"
  }
}

Let me know if that fixes the issue.

No worries, will push the new version soon.

Hey guys - this is my first foray into ember & sails. Is there a rough & dirty list of steps that you took to get this deployed to heroku? Just a standard sails deployment to heroku? Or the Getting started with Node tut?

Very interested in this. So if I am not wrong, we run the ember build command above and then update the .sailsrc to the code above?

Thank you Globegitter, this worked for me. (Y)

Thanks a lot Globegitter

Hmm, it does work for me when I delete the .sailsrc file that is odd - but there seems to be a better solution. Open up your server/.sailsrc file and change it to:
{
  "hooks": {
    "grunt": false
  },
  "paths": {
    "public": "assets"
  }
}

Let me know if that fixes the issue.

Thank you thank you thank you very much, 8 hs trying solutions here and there, thank you, genius!


Accept only rar or zip

Hello,
I would like to know how i can accept only rar and zip files.
Thanks

You need to filter the mime type of the file (from your form input) before you assign it to your model. This packages doesn't assume anything regarding mime type validation; It's going to take whatever you give it.


ci: release 0.11.3

:robot: I have created a release beep boop
0.11.3 (2023-11-01)
Bug Fixes

deps: update dependency @canonical/react-components to v0.47.1 (529c5d6)
deps: update dependency vanilla-framework to v4.4.0 (b9e3b03)
deps: update dependency vanilla-framework to v4.5.0 (bd40882)
downgrade Kratos sdk (b36de36)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/canonical/identity-platform-login-ui/releases/tag/v0.11.3 :sunflower:


[Frontend] Fix shape init for ONNX frontend

The model https://github.com/onnx/models/tree/master/vision/classification/inception_and_googlenet/inception_v1 has 0th input pointing to the weights. The change repeats onnx frontend tests approach to shapes for all inputs

Hi @dlexplorer ,
Would it be possible to add a test stressing the onnx case?

to stress test of tvmc with onnx frontend? We can add inception v1 into tests, I see some a_model.onnx is used in tvmc frontend tests already, but do not know how to add assets for testing and layout of final test package.
BTW, I was wrong saying in the desc that the same approach was used in the tests. It is used in another app: https://github.com/apache/tvm/blob/main/apps/wasm-standalone/wasm-graph/tools/build_graph_lib.py#L33

Can we add a unit test that hits this import path?
Could you specify usecases to cover in the test?
I am aware about googlenet from onnx models having input not in the 0th

I just want to hit the code, even creating a silly 1 op onnx model and parsing without providing shapes would be sufficient.

I just want to hit the code, even creating a silly 1 op onnx model and parsing without providing shapes would be sufficient.

There is this one (below) that compiles a network using TVMC (and hence this code), without providing shape.
Are you talking about something different?
https://github.com/apache/tvm/blob/dc51f176297bbfc303bc32f5585a70c66b107003/tests/python/driver/tvmc/test_compiler.py#L117

That works for me.


[itpp] build ippp with lapack, blas and fftw

Is your feature request related to a problem? Please describe.
Currently vcpkg does not build itpp with lapack, blas and fftw, and thus some basic functions like matrix inverse is not available.
For this simple example about vectors and matrices , itpp will report the error "LAPACK library is needed to use inv() function".
Proposed solution
I hope vcpkg build itpp with lapack, blas and fftw, which have already been ported to vcpkg.
Describe alternatives you've considered
I do not know how vcpkg works, but I think we need to first remove the three lines in ports\itpp\portfile.cmake
-DCMAKE_DISABLE_FIND_PACKAGE_LAPACK=ON
-DCMAKE_DISABLE_FIND_PACKAGE_FFT=ON
-DCMAKE_DISABLE_FIND_PACKAGE_BLAS=ON

Additional context
Related issue: https://github.com/microsoft/vcpkg/issues/6006

https://github.com/microsoft/vcpkg/pull/16385#discussion_r583250149 @ras0219  could you please help to confirm this?

@ras0219-msft ping~

please keep it open


Update JVM options

-XX:-UseBiasedLocking
why do you add this one for presto?  is there any compare before and after?


Nick: Watch landlooney.com

Nick requests the watch of the watch_keyword landlooney\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

landlooney\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Alpha gradient introduces grayness

Test: background: conic-gradient(rgba(43,247,254,0), rgba(43,247,254,1));
Expected result: A smooth conic gradient from the background color (white on your conic gradient page) to increasingly less-light-blue to light-blue.  Try replacing conic-gradient with linear-gradient for an example of the correct colors.
Actual result: A conic gradient from the background color (white on your conic gradient page) to gray to grayish-blue to light blue.

Browser: Firefox 39 beta in Linux

Thanks for reporting! Interestingly, this doesn't occur in Chrome (both the color problem and the moire pattern).

I'll bet this is caused by feeding the color through the browser for parsing, and the browser normalizing a fully-transparent color to rgba(0,0,0,0) (transparent black).  Lea, are you using the "paint into a 1 pixel canvas, then read the color out" trick you've used elsewhere?

This is working correctly now in Firefox 40.  Thanks!


add topics

I suggest adding the topics particle-physics, high-energy-physics in the About section.

Thanks for the suggestion! I've added the topics.


Feature/wdboggs/add run dt to field specs

Types of change(s)

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Trivial change (affects only documentation or cleanup)
[ ] Refactor (no functional changes, no api changes)

Checklist

[ ] Tested this change with a run of GEOSgcm
[x] Ran the Unit Tests (make tests)

Description
This PR adds run_dt to FieldSpec. run_dt for a FieldSpec is determined by run_dt for the component the Field is associated with. It is needed on the FieldSpec for setting ExtensionAction. run_dt is not an attribute for VariableSpec, so when a FieldSpec is constructed from a VariableSpec, run_dt must be set after construction.

I added run_dt to make_itemSpec to set run_dt for FieldSpec. Because make_itemSpec produces a StateItemSpec, which does not have a run_dt variable, I used a select type(itemSpec) ... end select block to cast itemSpec to FieldSpec. It's rather ugly, but it's better than adding run_dt to StateItemSpec. There could be another place to set run_dt for FieldSpec, but barring that, we are stuck with the select type :pig:

My apologies - I had forgotten that recent changes had relocated where we set the geom:
https://github.com/GEOS-ESM/MAPL/blob/39d4278dbebe1624fe35b3b31eb0872f33d3647e/generic3g/registry/StateRegistry.F90#L630-L654
It should never be part of VariableSpec.

DT should be passed alongside geom and vertical grid.

Adding run_dt to set_blanket_geometry required adding it to set_geometry for StateItemSpec and the types derived from it. We may rename both procedures to be more inclusive for geometry and run_dt.


how to allow duplicate selections

Is there a way for select2 v3.5.x to allow selecting the same item multiple times?
It seems the default behavior (which is probably the most common use case) is to remove the selected item from the dropdown list.  But I'd like to keep the item in the dropdown list and be able to add more duplicates of the same item.
Thanks.

Not in 3.5.x, but it is allowed in 4.0.0.
https://github.com/select2/select2/issues/1002

@kevin-brown  thanks for the response.  But allowing duplicate IDs is not necessarily the feature I was looking for.
I was hoping that when clicking on a selection in the drop down, that selection would not disappear, but rather, you could select that option multiple times.
Simply adding duplicate options into the select tag is not the feature I'm inquiring about.
I think with select2    4.x, maybe a plugin could be written to support this?  I'm trying to see if this would be a 'simple' change or a pretty involved change.
Thanks.

But allowing duplicate IDs is not necessarily the feature I was looking for.

In order to allow for a selection to be made more than once, Select2 needs to allow for the id to be chosen multiple times (or else you would have to make it unique).

Simply adding duplicate options into the select tag is not the feature I'm inquiring about.

If you want to select something multiple times, there is going to have to be multiple options in the select tag. If there wasn't, the server would only know about the first selection, which sorta defeats the purpose of duplicate selections.

I'm trying to see if this would be a 'simple' change or a pretty involved change.

Select2 allows for multiple selections to be made with the same id, which is what you would be looking for here. The trick would be hiding existing selections from the results, or you would inevitably hit duplicates, but that could be as simple as checking data.element.selected in the templateResult option.
You can actually do this without much effort by closing the evt.params.data.element on select2:select and appending it to the <select>, which would add the option back so it can be selected again. You would also have to delete the <option> on select2:unselect (same param) to avoid them stacking up over time.

This appears to be more of a usage question than a bug report or common feature request.  As we continue to keep the Select2 issue tracker geared towards these two areas, bug reports and common feature requests, we are redirecting usage questions to other communities such as the mailing list, IRC, or Stack Overflow.

Hi @kevin-brown. I'm having same problems trying to understand it. Can you show me a sample code, because the select2:select event is not called when option is selected by second time.
ps: my data is loaded by ajax. Thanks.


Minimal changes to compile with OCaml 4.07

This is a bit of a hack and won't really scale across lots of OCaml versions.  It builds with OCaml 4.07.0+rc1 though, so it at least unblocks other testing against the soon-to-be latest OCaml release.
If you want to build rtop you'll also need https://github.com/diml/utop/pull/238 (or a better equivalent allowing utop to build under 4.07).

We should probably update the ci to test 4.07 😄

Definitely!  Is that something you'd like to have in this PR or a separate one?  I'm not sure how to approach that since utop is not ready for 4.07 yet.

Thank you. Would you mind adding the relevant CI to this PR? After it's merged, I can revert that portion of it, but then as soon as utop is fixed, I'll just unrevert it.

@jordwalke Thanks for reviewing!  I've added separate commits for CircleCI and Travis.  These checks could remain and be updated when the final 4.07.0 release lands once they're working properly.
Travis should have the utop pin removed once https://github.com/diml/utop/pull/238 lands in a utop release.  It should also be updated to the 4.07.0 switch once 4.07.0 is released.
CircleCI would only need to have the utop pin removed.  The ocaml/opam2 docker image used in that config should be automatically updated to the latest 4.07.x point release as they come out.

Is the comment formatting test failure on Travis expected?
I just pushed an update to pin to utop's master branch - https://github.com/diml/utop/pull/238 has been merged so it has proper 4.07 support now.
I'm happy to squash these commits when the PR is ready if you'd prefer that.

Hmm the comment failure is not expected. I can probably investigate, if you don't have the time, but it'll be next week.
If you rebase on master you'll have to add a new file mlVariants.re.4.07.0 and copy the contents of mlVariants.re.4.06.0 to it.

@IwanKaramazow If you have time to look at this I'd appreciate it.  It'll be a little while before I can come back to work on this more.

I'll see what I can do

@IwanKaramazow Now that 4.07.0 is official - do you want to finish this up or should I?  Aside from rebasing and adding the file you mentioned (https://github.com/facebook/reason/pull/2013#issuecomment-399636360) do you know if there there is anything else left to do?

Rebased on master with CI bumped to the actual 4.07.0 release and mlVariants.re.4.07.0 added to the source tree.
There is a still a formatting test failure in comments.mli that I can reproduce locally.  Not sure why it happens:
Unit Test: ./comments.mli
diff --git a/Users/travis/build/facebook/reason/formatTest/typeCheckedTests/expected_output/comments.rei b/Users/travis/build/facebook/reason/formatTest/typeCheckedTests/actual_output/comments.rei
index c6f7d58..0d0f98b 100644
--- a/Users/travis/build/facebook/reason/formatTest/typeCheckedTests/expected_output/comments.rei
+++ b/Users/travis/build/facebook/reason/formatTest/typeCheckedTests/actual_output/comments.rei
@@ -1,8 +1,8 @@
 /* **** comment */
 /*** comment */
-/*** docstring */
+/** docstring */;
 /* comment */
-/*** docstring */
+/** docstring */;
 /*** comment */
 /**** comment */
 /***** comment */
  ⊘ FAILED
  /Users/travis/build/facebook/reason/formatTest/typeCheckedTests/actual_output/comments.rei
  doesn't match expected output
  /Users/travis/build/facebook/reason/formatTest/typeCheckedTests/expected_output/comments.rei
  To approve the changes run:
    cp /Users/travis/build/facebook/reason/formatTest/typeCheckedTests/actual_output/comments.rei /Users/travis/build/facebook/reason/formatTest/typeCheckedTests/expected_output/comments.rei

I just rebased this on master and investigated the failure. Here's the difference (refmt is current master's refmt on 4.06.1)
$ echo '(** docstring *)' | refmt --parse ml -past
[]
$ echo '(** docstring *)' | ./_build/install/default/bin/refmt --parse ml -past
[
  structure_item ([1,0+0]..[1,0+16])
    Pstr_attribute "ocaml.text"
    [
      structure_item ([1,0+0]..[1,0+16])
        Pstr_eval
        expression ([1,0+0]..[1,0+16])
          Pexp_constant PConst_string(" docstring ",None)
    ]
]

So the issue here is in 4.07 OCaml parses (** docstring *) as [@@@ocaml.text " docstring "] but in previous versions it just parses it as a comment...

Maybe related to https://github.com/ocaml/ocaml/pull/1693

Yes, the parsing behaviour has changed on the ocaml side. A specific test with the behaviour for 4.07 makes sense here (I think)

Thank you for picking this up @anmonteiro!

I think this is ready now. Can I get an approval? @IwanKaramazow @jordwalke @chenglou

Thank you all very much for collaborating on this to get it ready! I look forward to using this.


DB Schema changes + other minor stuff

Change target JDK to 1.8 instead of 9
Change naming of some getters/setters that were made manually
Change DB schema to fix relations

:kissing_heart:


Re-exports do not work with library mode

[x ] I have checked issues with bug label and found no duplicates

Expected Behavior

On the root of this project, I run this command (after having installed typedoc):
npx typedoc --mode library --inputFiles source/lib/index.ts --tsconfig source/tsconfig.json --out docs/documentation
Everything works well. The index.ts exports a function (generate) and re-exports the Options from another file.
I get something like this:

What I want is the same thing, but without the externals, like this:

Hence I run this command:
npx typedoc --inputFiles source/lib/index.ts --excludeExternals --mode library --tsconfig source/tsconfig.json --out docs/documentation
With the --excludeExternals added
Actual Behavior

The problem is that now the re-exported Options is disappeard, and I get this:

Steps to reproduce the bug

To reproduce, clone this project, install typedoc 0.17.0 as dev dependency and run this: npx typedoc --inputFiles source/lib/index.ts --excludeExternals --mode library --tsconfig source/tsconfig.json --out docs/documentation to generate the documentation of source/lib/index.ts
Environment

Typedoc version: 0.17.0
Node.js version: 12
OS: Ubuntu 18

So, there is a problem here, but it isn't exactly what you thought it was.
Version 0.17.0 doesn't include library mode - and TypeDoc has a bug so it doesn't tell you that it is ignoring that you told it to use library mode and is using modules mode #1237.
--excludeExternals is working as expected. The Options type is not included in your input files, and is therefore considered external, so it is removed by --excludeExternals.
What you are looking for is not to remove the "externals" (bad name, needs fixing, after library mode is done...) from your documentation (after all, that's where Options is defined!) but simply removing it them from the navigation.
The --toc option is supposed to let you do this, and I was going to suggest creating a typedoc.json file with { "toc": [ "\"index\"" ] } in it, but this seems to be broken in modules mode (the globals list appears to be unaffected by this option, which seems like a bug that I don't have time to chase down right now)

Ok, thank you, sorry if I did not notice library mode was still not available
I see now a 0.17.1, is it still without lib mode?
When library is available, will I be able to have what I need (have the documentation of all things exported or re-exported by the only index.ts file)?
Is there any other way to do this with the current version?

Yes, library mode is supporting precisely that use case.
0.18 (assuming no required breaking changes are needed before library mode is done) will contain library mode.
You can install typedoc@next if you want to use library mode now. I'm afraid there isn't a great solution in the existing version for your issue.


Suppress some MSVC warnings on Windows build

GINT: convert wstring -> string using TextUtfEncoding (C4244 possible loss of data)
ZXingQtReader/ZXingReader: some casts (C4244)
example/blackbox CMakeLists: define _CRT_SECURE_NO_WARNINGS (C4996 unsafe func)

This PR is ready for review.

This PR is ready for re-review after https://github.com/nu-book/zxing-cpp/pull/299/commits/6c215b861b014e08529b099270fbf564c0621a51.

Thanks.


make maxscrollmax size configurable

Thanks for contributing to react-virtualized!
Here is a short checklist of additional things to keep in mind before submitting:

Please make sure your pull request description makes it very clear what you're trying to accomplish. If it's a bug fix, please also provide a failing test case (if possible). In either case, please add additional unit test coverage for your changes. :)
Run tests locally (npm test) to ensure that your change did not break linting or functionality.
Be sure you have notifications setup so that you'll see my code review responses. (I may ask you to make some adjustments before merging.)

It's not something which should be configurable. It's constant value which depends on browser abilities.

if that is the case how would react virtualised work for react components which have scroll height more than 1.5 million? This breaks 'scrollToRow' use case . I need this to work for my app. Are are any other suggestions ? @TrySound @bvaughn

@TrySound @bvaughn Is there a specific reason these values should not be changed? Are there specific problems in any specific browsers with higher values?

@paulkenney Yeah, you should find safe values or you will have even bigger problems. For example when chrome reaches limit it just stop render after it. When firefox reaches limit it starts proportionally decrease width. So different browsers even behaves differently. Currently we hardcoded size for chrome which is 1.67771e7 , others get IE size.
@scarlettlite scrollToRow should work. Virtualized scales scroll when the size is more then calculated in this function. Probably you found a bug. Can you create codesandbox example which reproduces the problem?

https://codesandbox.io/s/rl5jv04k3q I created this example the reproduces the issue. Here I take as input the div and where In div ( the vertical offset in div ) I want to scroll to and then compute the scroll top that I pass to the grid . On Safari/Firefox if the scroll Height of the virtualised grid exceeds 1.5 million this calculation fails.

May I ask, which version of Internet explorer does version 8.x support?


Proposal: input param for generate version between current and next major

I'd like if there is input param that makes requirements not like:
aaa==0.0.1
bbb==1.1.0
ccc==2.0.0
but like:
aaa>=0.0.1,<1.0.0
bbb>=1.1.0,<2.0.0
ccc>=2.0.0,<3.0.0

I think this can be done by using import statement with comment. like
import abc #>=0.0.1, <1.0.0

Any other idea?

I would make it simpler, just providing an optional flag to pipreqs that changes == into >=

Right but that would do it to all of your imports, instead of conditionally. It could be of some use to small projects who can rely on that and just are an addon to something else.
But in that case... wouldn't it be 'better' to just keep it out of code, a do a find-and-replace on the generated file?

Feature implemented in PR#239 as ~=


mount on /newsiebot

this will mount everything on /newsiebot

GET /newsiebot/health-check will work
POST /newsiebot/publish will work

:+1: from cmika

+1


Update guzzlehttp/guzzle to version 7

Please update guzzlehttp/guzzle to version 7.
Thank you in advance.

Guzzle 7 requires a minimal version of php:^7.2.5 which may reduce the compatibility of this library which currently supports php:>=7.0
Do we have any policy around what is the minimum supported version of PHP? @IcyApril

@haphan https://www.php.net/supported-versions.php

As the guzzle7 PR was merged, is there any ETA on when a new release will be tagged?

Also curious when a release will be made, this is the only package keeping me from updating my project.

@IcyApril Can we get a release tagged so we can use the merged Guzzle 7 PR? Thanks!

I think we can temporarily install the package from the master branch to use the merged Guzzle 7 PR.
composer require cloudflare/sdk:dev-master

I think we can temporarily install the package from the master branch to use the merged Guzzle 7 PR.
composer require cloudflare/sdk:dev-master

I would lock it on the commit hash for now
"cloudflare/sdk": "dev-master#7db3d6e62c7ab8fa29780354e8d370c49939cdec",

This is like 2 months old now, when will Guzzle 7 be tagged? Just do a major version update for it. 1.2.x or 2.x or however you want.

Does no one at Cloudflare use this package at all? If you put yourself through your customer/user pain points, things get done a lot faster... 😞

Does no one at Cloudflare use this package at all? If you put yourself through your customer/user pain points, things get done a lot faster... 😞

@IcyApril Any idea what's going on? How can we (the community) help?

@IcyApril Any idea what's going on? How can we (the community) help?

Does no one at Cloudflare use this package at all? If you put yourself through your customer/user pain points, things get done a lot faster... 😞

https://www.parkersoftware.com/blog/are-you-eating-your-own-dog-food/

Does no one at Cloudflare use this package at all? If you put yourself through your customer/user pain points, things get done a lot faster... 😞

https://www.parkersoftware.com/blog/are-you-eating-your-own-dog-food/

Does no one at Cloudflare use this package at all? If you put yourself through your customer/user pain points, things get done a lot faster... 😞

https://www.parkersoftware.com/blog/are-you-eating-your-own-dog-food/

Does no one at Cloudflare use this package at all? If you put yourself through your customer/user pain points, things get done a lot faster... 😞

https://www.parkersoftware.com/blog/are-you-eating-your-own-dog-food/

Any update as to when the new version will be tagged?

This should be closed as they have released 1.1.7 with Guzzle 7, although I believe this should have been at least 1.2 but ideally, 2.0 as this does break if we have other packages relying on Guzzle 6.

Complete lack of feedback from maintainers is really disappointing.
While, off course , depending on a newer Guzzle version is a good thing for the project, making it user friendly way is completely possible and a preferred. As was previously suggested, that could be done in two ways:

releasing v2 of the package
allowing both versions to co-exist with ^6.0 || ^7.0 version constraint in 1.x release

On behalf of community and users of this project I'm asking maintainers to update version constraint to ^6.0 || ^7.0 and release new version for 1.x branch.


Paloma LightNode Client Proof of Purchase on EVM - Pigeon

Pigeon implementation for https://github.com/VolumeFi/paloma/issues/1865

Currently blocked by EPIC for compass events


[BEAM-10475] Add transform translator for GroupIntoBatches in Java.

Changes in this PR:

Add a transform translator for GroupIntoBatches in Java to populate the URN and payload in the runner API.
Updated GroupIntoBatches implementation to wrap batching parameters in a class so that can be reused by both variation of the transform (with or without sharded keys).
Updated DataflowPipelineTranslatorTestaccordingly to also check the runner api proto.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @boyuanzz

R: @boyuanzz

Run Java PreCommit

Run Java_Examples_Dataflow PreCommit

Run Java PreCommit

Run Java PreCommit


Add profiles to backup data (and add flag to restore)

Required information

Distribution: Ubuntu
Distribution version: 20.04

LXD version: 5.0 (latest/stable)

Issue/feature description
When exporting a container, backup/container/backup.yaml contains a list of assigned profiles, but the profiles themselves are not included. However, for archival/debugging/documentation purposes, having a copy of said profiles is often necessary (and thus currently requires an extra step).

It would be helpful to have an option --include-profiles that would store a copy in, e.g., backup/profiles/<name-of-profile[s]> upon lxc export.
Upon lxc import --include-profiles, those archived profiles then could be handled like configuration files shipped with .deb packages that can be viewed, compared, renamed/selected.
In a second step, maybe even a filter selecting individual profiles to include/process this way could be added.

@presztak absolutely!

I think we should just always include the profile data in the backup.yaml.
For restoration, it's a bit harder. We may indeed need a flag to control this but I think that can be made at a later time, so long as we have the data in the backup, it would at least allow for manual restoration.
The issue I have with the restoration through a flag is that we'll need to decide what to do with it already exists, do we attempt to update it, ... and this could be security sensitive.

@stgraber,
just to clarify, in this change we will:

add profiles to backup by default (without any additional flag) upon lxc export
not implement import of profiles

that's correct?
And one more because I'm not sure. What will be the best place for profiles? backup/profiles/<name-of-profile> or profiles should be stored directly into backup/container/backup.yaml file?

Yeah, that's correct.
I think we can put directly in backup.yaml, similar to what we're doing with storage pools.


Support for Laravel 5.2

I will create one branch for 5.1 version and then merge it with master.

hi Mitul,
when do you plan to merge this banch? are there still tests to run? thanks to both

I will get it done soon once I'm back from holidays.

In the commit posted below, illuminate/support 5.2 is now required.
Because of this, composer will always need to install laravel 5.2 (laravel 5.1 uses illuminate/support 5.1)
Why is illuminate/support 5.2 now required?
Can't we change this to "illuminate/support": "~5.1" ??
https://github.com/jonphipps/laravel-api-generator/commit/21dac85ef4d0bb08394d1657213c07be7643f264

Laravel's versioning is not semver compatible and the 5.2 api breaks 5.1, so it's a problem (see https://laraver.xyz/versions/v5.2.0-beta1). If the 5.2-compatible changes work with the 5.1 api, then ~5.1 would be great, but someone (not me at the moment) will have to test that.

Okay, well I propose that after testing, we should at least tag the last version that's compatible with laravel 5.1, and write this in the readme


Remove .Relational for consuming metadata at runtime

At runtime, metadata should be consumed, usually indirectly, through the current provider's API to ensure that any provider-specific overrides are honored. This means it is never correct to use .Relational to consume metadata after the model has been built, although it is often valid to use it to set metadata when constructing the model.
This change removes the read-only interface-based .Relational methods and fixes everywhere they were being misused.

:shipit:


Problem with Qt

Hi I`m trying to build the software and I stock in this error
CMake Error at sim/CMakeLists.txt:45 (find_package):
  By not providing "FindQt5Gamepad.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "Qt5Gamepad", but CMake did not find one.

  Could not find a package configuration file provided by "Qt5Gamepad" with
  any of the following names:

    Qt5GamepadConfig.cmake
    qt5gamepad-config.cmake

  Add the installation prefix of "Qt5Gamepad" to CMAKE_PREFIX_PATH or set
  "Qt5Gamepad_DIR" to a directory containing one of the above files.  If
  "Qt5Gamepad" provides a separate development package or SDK, be sure it has
  been installed.

-- Configuring incomplete, errors occurred!

I install qt via apt with this commands
sudo apt-get install build-essential

sudo apt-get install qtcreator

sudo apt-get install qt5-default

but it`s not working. can you please help me with this problem.

I used the Qt online installer to install Qt 5.12 and it fixed this error.

I solved it by installing libqt5gamepad5-dev with sudo apt install -y libqt5gamepad5-dev