HBASE-27805 The chunk created by mslab may cause memory fragement and…

… lead to fullgc

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ master Compile Tests _

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

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

+1 :green_heart:
javadoc
2m 32s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
271m 28s
root in the patch passed.

304m 27s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux b5d47b5ab987 5.4.0-137-generic #154-Ubuntu SMP Thu Jan 5 17:03:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / f5ee958ead

Default Java
Eclipse Adoptium-11.0.17+8

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

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

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

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

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

_ master Compile Tests _

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

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

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

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

+0 :ok:
refguide
2m 29s
branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
spotless
0m 41s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
8m 42s
master passed

_ Patch Compile Tests _

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

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

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

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

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

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

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+0 :ok:
refguide
1m 58s
patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
hadoopcheck
13m  3s
Patch does not cause any errors with Hadoop 3.2.4 3.3.4.

+1 :green_heart:
spotless
0m 38s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
8m 50s
the patch passed

_ Other Tests _

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

63m 58s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac refguide spotless xml spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux dd353ace1e38 5.4.0-1094-aws #102~18.04.1-Ubuntu SMP Tue Jan 10 21:07:03 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 95f83cb8e2

Default Java
Eclipse Adoptium-11.0.17+8

refguide
https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-5193/2/yetus-general-check/output/branch-site/book.html

refguide
https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-5193/2/yetus-general-check/output/patch-site/book.html

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

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

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ master Compile Tests _

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

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

+1 :green_heart:
compile
2m 19s
master passed

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

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

_ Patch Compile Tests _

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

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

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

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

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

+1 :green_heart:
javadoc
2m 32s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
285m 24s
root in the patch passed.

318m 36s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux db7267f512f2 5.4.0-137-generic #154-Ubuntu SMP Thu Jan 5 17:03:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 95f83cb8e2

Default Java
Eclipse Adoptium-11.0.17+8

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

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

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

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ master Compile Tests _

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

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

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

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

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

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 47s
the patch passed

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

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

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

+1 :green_heart:
javadoc
2m 36s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
390m  6s
root in the patch passed.

418m 54s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 4c2712c26b3a 5.4.0-1094-aws #102~18.04.1-Ubuntu SMP Tue Jan 10 21:07:03 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 95f83cb8e2

Default Java
Temurin-1.8.0_352-b08

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

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

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

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

Oh, there is a problem that, what is the default value for G1HeapRegionSize? After googling, I think the default size is based on the heap size?

The G1 GC is a regionalized and generational garbage collector, which means that the Java object heap (heap) is divided into a number of equally sized regions. Upon startup, the Java Virtual Machine (JVM) sets the region size. The region sizes can vary from 1 MB to 32 MB depending on the heap size. The goal is to have no more than 2048 regions. The eden, survivor, and old generations are logical sets of these regions and are not contiguous.

For having 2048 regions, if we have 16GB heap size, it will have 8MB region size, then there is no problem for using 2MB chunk size. And if we have less than 8GB heap size, 2047KB will also make a lot of humongous objects...
So I think a better approach is to documentation this out? If you are using G1 GC, be careful about the chunk size and the heap region size...

The G1HeapRegionSize calculated by initial_heap_size and max_heap_size, here are some cases for better understand:
//xms=0,xmx=10g -> region size 2048K
//xms=10g,xmx=10g -> region size 4096K
//xms=0,xmx=20g -> region size 4096K
//xms=20,xmx=20g -> region size 8192K
//xms=0,xmx=30g -> region size 4096K
//xms=0,xmx=32g -> region size 8192K

The related jdk8 code shows below:
void HeapRegion::setup_heap_region_size(size_t initial_heap_size, size_t max_heap_size) {
  uintx region_size = G1HeapRegionSize;
  if (FLAG_IS_DEFAULT(G1HeapRegionSize)) {
    size_t average_heap_size = (initial_heap_size + max_heap_size) / 2;
    region_size = MAX2(average_heap_size / HeapRegionBounds::target_number(),
                       (uintx) HeapRegionBounds::min_size());
  }

  int region_size_log = log2_long((jlong) region_size);
  // Recalculate the region size to make sure it's a power of
  // 2. This means that region_size is the largest power of 2 that's
  // <= what we've calculated so far.
  region_size = ((uintx)1 << region_size_log);

  // Now make sure that we don't go over or under our limits.
  if (region_size < HeapRegionBounds::min_size()) {
    region_size = HeapRegionBounds::min_size();
  } else if (region_size > HeapRegionBounds::max_size()) {
    region_size = HeapRegionBounds::max_size();
  }

  // And recalculate the log.
  region_size_log = log2_long((jlong) region_size);

  // Now, set up the globals.
  guarantee(LogOfHRGrainBytes == 0, "we should only set it once");
  LogOfHRGrainBytes = region_size_log;

  guarantee(LogOfHRGrainWords == 0, "we should only set it once");
  LogOfHRGrainWords = LogOfHRGrainBytes - LogHeapWordSize;

  guarantee(GrainBytes == 0, "we should only set it once");
  // The cast to int is safe, given that we've bounded region_size by
  // MIN_REGION_SIZE and MAX_REGION_SIZE.
  GrainBytes = (size_t)region_size;

  guarantee(GrainWords == 0, "we should only set it once");
  GrainWords = GrainBytes >> LogHeapWordSize;
  guarantee((size_t) 1 << LogOfHRGrainWords == GrainWords, "sanity");

  guarantee(CardsPerRegion == 0, "we should only set it once");
  CardsPerRegion = GrainBytes >> CardTableModRefBS::card_shift;
}

So it's easy to get 4M.

If the chunk size is 2047KB and if the heapRegionSize is 2MB, we will just waste 1KB memory, its ok. But if the chunk size is 2047KB and if the heapRegionSize is 4MB, we will waste 2MB memory.

Every humongous object gets allocated as a sequence of contiguous regions in the old generation. The start of the object itself is always located at the start of the first region in that sequence. Any leftover space in the last region of the sequence will be lost for allocation until the entire object is reclaimed.

3.In practice, many users have little background knowledge about heapRegionSize and humongous objects and can easily run into problems, only document it seems not enough.

Let's post the new findings in the discussion thread in dev list to get more feedbacks? May also send to the user mailing list.
Changing the default may have big impact on performance so we should be careful...

Yeah, it really needs to be.

Personally I'm for documenting more than changing. If we need to make a change I think we should try to detect g1 region size. Otherwise leave it alone imo. It makes too much assumptions about user deployment to change default like this.
For us, we don't have this problem. Our region sizes are larger.

Personally I'm for documenting more than changing. If we need to make a change I think we should try to detect g1 region size. Otherwise leave it alone imo. It makes too much assumptions about user deployment to change default like this.
For us, we don't have this problem. Our region sizes are larger.

Ok, let's document it.
Thanks for the comment.

Ping. @Apache9 @bbeaudreault

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

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

_ master Compile Tests _

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

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

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

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

+0 :ok:
refguide
2m 36s
branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
spotless
0m 45s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
8m 51s
master passed

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 43s
the patch passed

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

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

+1 :green_heart:
checkstyle
1m  9s
the patch passed

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

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+0 :ok:
refguide
2m  3s
patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
hadoopcheck
10m 21s
Patch does not cause any errors with Hadoop 3.2.4 3.3.5.

+1 :green_heart:
spotless
0m 40s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
9m 20s
the patch passed

_ Other Tests _

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

60m  0s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac refguide spotless xml spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 02e6078b28a9 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 73ea43f5d7

Default Java
Eclipse Adoptium-11.0.17+8

refguide
https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-5193/3/yetus-general-check/output/branch-site/book.html

refguide
https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-5193/3/yetus-general-check/output/patch-site/book.html

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

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

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ master Compile Tests _

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

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

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

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

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

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 33s
the patch passed

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

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

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

+1 :green_heart:
javadoc
2m 31s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
280m 51s
root in the patch passed.

310m 42s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux a2e0cd408abd 5.4.0-148-generic #165-Ubuntu SMP Tue Apr 18 08:53:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 73ea43f5d7

Default Java
Eclipse Adoptium-11.0.17+8

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

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

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

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ master Compile Tests _

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

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

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

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

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

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 12s
the patch passed

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

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

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

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

_ Other Tests _

-1 :x:
unit
350m  0s
root in the patch failed.

376m 42s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 8adbf03f4539 5.4.0-1101-aws #109~18.04.1-Ubuntu SMP Mon Apr 24 20:40:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 73ea43f5d7

Default Java
Temurin-1.8.0_352-b08

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

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

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

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

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

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

_ master Compile Tests _

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

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

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

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

+0 :ok:
refguide
2m  6s
branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
spotless
0m 40s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
8m 54s
master passed

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 42s
the patch passed

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

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

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

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

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+0 :ok:
refguide
2m  1s
patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
hadoopcheck
10m  2s
Patch does not cause any errors with Hadoop 3.2.4 3.3.5.

+1 :green_heart:
spotless
0m 41s
patch has no errors when running spotless:check.

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

_ Other Tests _

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

58m 29s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac refguide spotless xml spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 29111dd02e59 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 73ea43f5d7

Default Java
Eclipse Adoptium-11.0.17+8

refguide
https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-5193/4/yetus-general-check/output/branch-site/book.html

refguide
https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-5193/4/yetus-general-check/output/patch-site/book.html

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

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

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ master Compile Tests _

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

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

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

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

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

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 30s
the patch passed

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

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

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

+1 :green_heart:
javadoc
2m 32s
the patch passed

_ Other Tests _

-1 :x:
unit
239m  6s
root in the patch failed.

268m 15s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 83246ff89a92 5.4.0-148-generic #165-Ubuntu SMP Tue Apr 18 08:53:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 73ea43f5d7

Default Java
Eclipse Adoptium-11.0.17+8

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5193/4/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-root.txt

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

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

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

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ master Compile Tests _

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

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
401m 30s
root in the patch passed.

428m 48s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux e50b75a03f92 5.4.0-1101-aws #109~18.04.1-Ubuntu SMP Mon Apr 24 20:40:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 73ea43f5d7

Default Java
Temurin-1.8.0_352-b08

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

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

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

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

This pr just update doc, the failure ut not related.


Can't install APIService that doesn't introduce a new Kind

Bug Report
What did you do?
Created CSV for operator that internally uses APIService object to extend k8s metrics.
Operator is using APIService listed below, relevant files such as ClusterRoles are located in this repo. Manual installation (oc apply -f deploy/) is working correctly and Operator is fully functional.
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
  name: v1beta1.external.metrics.k8s.io
spec:
  service:
    name: keda-operator
    namespace: keda
  group: external.metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100

Keda operator implements external metrics apiserver framework interface. Keda Operator is following the instructions and deployment recomendations (APIService, ClusterRole, etc) specified in the framework.
I tried to map APIService specified above to the respective fields in the CSV, this is the relevant part:
  apiservicedefinitions:
    owned:
    - group: external.metrics.k8s.io
      kind:
      version: v1beta1
      displayName: Metrics Server APIService
      description: Metrics Server APIService which is used internally by Keda.
      deploymentName: keda-operator
      containerPort: 6443
      specDescriptors: []

I am not sure what should I specify under kind and in fact, this is the part that is causing the problems after the deployment. This deployment doesn't introduce any new Kind, it is extending k8s metrics server. This operator is not defining a new extenstion. it is just providing an implementation to existing one.
CSV and package is located here
What did you expect to see?
Successful installation.
What did you see instead? Under which circumstances?
Operator is installed and fully functional, all objects are correctly created. But due to unsuccessful installation, OLM is trying to restart the operator periodically every few minutes, which results in redeployment of the operator pod.
Restarts happen because of problems in api discovery, caused by not specified kind in CSV.
Relevant log snippet from olm-operator pod:
time="2019-11-12T20:33:15Z" level=info msg="csv in operatorgroup" csv=keda.v0.0.4 id=vlRUk namespace=openshift-operators opgroup=global-operators phase=Installing
time="2019-11-12T20:33:15Z" level=info msg="couldn't find GVK in api discovery" group=external.metrics.k8s.io kind= version=v1beta1

Environment

operator-lifecycle-manager version:
4.2.0-0.nightly-2019-09-17-232025

Kubernetes version information:
v1.14.6+e353665

Kubernetes cluster kind:
OCP     4.2.0-0.nightly-2019-09-17-232025

Possible Solution
Allow users to disable discovery for specified resource, in this case APIService.
Additional context
https://github.com/kubernetes-incubator/custom-metrics-apiserver
https://kubernetes.io/docs/tasks/access-kubernetes-api/#register-apiservice-objects

Thanks for submitting this issue @zroubalik.
Your CSV is failing to reach the succeeded state because your apiservicedefinition is missing a KIND. OLM relies on GroupVersionKind (GVK) to ensure that the apiservice is working as expected and for dependency resolution
I looked into what KIND your CSV provides and found that when your operator is deployed and no HPA is created, an empty list of resources are defined:
$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq .
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "external.metrics.k8s.io/v1beta1",
  "resources": []
}

At this point, the installation fails because of this check in OLM because no resources exist.
When your operator is used it will eventually create an HPA which in turn defines a new resource:
$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "external.metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "lagThreshold",
      "singularName": "",
      "namespaced": true,
      "kind": "ExternalMetricValueList",
      "verbs": [
        "get"
      ]
    }
  ]
}

Now that a resource exists - updating your CSV's apiservicedefinitions to list a KIND and NAME will lead to a successful install:
apiservicedefinitions:
  owned:
  - containerPort: 6443
    deploymentName: keda-server
    description: Metrics Server APIService which is used internally by Keda.
    displayName: Metrics Server APIService
    group: external.metrics.k8s.io
    kind: ExternalMetricValueList
    name: externalmetricvaluelist
    version: v1beta1

At this point, OLM cannot remove the restraint on the GVK due to the fact that dependency resolution would be broken as a result.

This Issue also raises concerns given that the custom-metrics-apiserver seems to provide the same GroupVersion for all parties that use the library as this may impact dependency resolution. This is an area which we will need to investigate further.

@zroubalik  for completeness, this gist contains a number of yamls that will allow you to successfully install Keda with OLM.
I should note that the install may fail once or twice because the apiserver shipped with your operator takes awhile to server (and craps out occasionally)... see:
$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq
Error from server (ServiceUnavailable): the server is currently unable to handle the request

$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq
Error from server (ServiceUnavailable): the server is currently unable to handle the request

$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq
Error from server (ServiceUnavailable): the server is currently unable to handle the request

$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "external.metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "lagThreshold",
      "singularName": "",
      "namespaced": true,
      "kind": "ExternalMetricValueList",
      "verbs": [
        "get"
      ]
    }
  ]
}

@awgreene thank you for your time and work on this issue! I understand the root of the problem, but I am still looking for a solution how to install the operator via OLM, since I think that it is a valid use case.

@zroubalik for completeness, this gist contains a number of yamls that will allow you to successfully install Keda with OLM.

I understand what you are saying here, but to avoid confusion and a false assumption, that this could be used to install KEDA via OLM, it can not be. I'd like to note, that this gist expects installed and configured Kafka and Kafka Topic and this gist is deploying an operand that the operator should manage, ie. ScaledObject CR pointing to the the preconfigured Kafka. Which is something that can't be default behaviour, since users would like to create their own ScaledObject CRs with specific settings. And users would like to install KEDA without any CRs created for them during the installation.

At this point, OLM cannot remove the restraint on the GVK due to the fact that dependency resolution would be broken as a result.

Kind for this specific usecase is dynamically created and deleted so I understand that it is causing a problem with Dependency resolution as it is currently implemented in OLM. So I'd like to ask whether it is planned to change the dependecy resultion for APIService objects?
What is the recommended approach on getting the operator on OperatorHub?
Thanks!

I understand what you are saying here, but to avoid confusion and a false assumption, that this could be used to install KEDA via OLM, it can not be. I'd like to note, that this gist expects installed and configured Kafka and Kafka Topic and this gist is deploying an operand that the operator should manage, ie. ScaledObject CR pointing to the the preconfigured Kafka. Which is something that can't be default behaviour, since users would like to create their own ScaledObject CRs with specific settings. And users would like to install KEDA without any CRs created for them during the installation.

The provided gist was just meant to highlight that OLM could get the CSV to a succeeded state if certain constraints are met - it was not meant to be used as a serious installation.

Kind for this specific usecase is dynamically created and deleted so I understand that it is causing a problem with Dependency resolution as it is currently implemented in OLM. So I'd like to ask whether it is planned to change the dependecy resultion for APIService objects?

There are plans to improve dependency resolution but this use case is new to us and will require some additional investigation before we can commit to a timeline.

What is the recommended approach on getting the operator on OperatorHub?

A meta-operator may provide a quick workaround.

Creating an umbrella-operator that installs your operator may provide a work around to get your operator on OperatorHub.

Yeah, I was thinking about this from the beginning but wanted to avoid this. But will use this approach eventually if there's not a possibility how to improve OLM Dependency Resolution.


Remove unused cpp files from libraries/fc/src/*

Example thread.cpp is not built by cmake, there are probably other .cpp files that are not being included in the build.

Resolved by: https://github.com/EOSIO/eos/pull/309


Add abortKeyBinding to allow overloading keymaps

Hi.
I added abortKeyBinding to allow overloading key mapping.
Now, findDefinition method check condition that the grammar of source code is correct.
If not, the method quit silently and other keybindings which have same key-map can not know that.
Adding e. abortKeyBinding , others could know atom-racer did not handle the key-map.
So this PR may also ease problems like #43 .
http://flight-manual.atom.io/behind-atom/sections/keymaps-in-depth/#overloading-key-bindings
Regards,

Thanks for your contribution!


Nested feature branch support for git-ship

@charlierudolph @allewun @ricmatsui
Using the new infrastructure for a while leads to evolutionary improvements to it. So treat these PRs as previews of what's coming here, for architectural discussions. Once done, I will do a new set with the final code.
implements parts of #529

This PR is outdated, a newer one has been opened.


Elements appear repeatedly

Hi,
I noticed some scenarios on Material Frontend which provoke strange behaviours:
Scenario 1:

Click on a link to a detail of item.
 It redirects you to the items table.
Click on another item.
Go back
The toast appear repeatedly:

I can open each scenario in separate issues but it seems that the root of all evil is the same: turbolinks. I tried to remove it temporally and both issues disappeared.
Maybe turbolinks is not a good option at all for this kind of project which not seems to fit the requirements of SPA site.

Yep, it's need to be fixed. Elements just need to be destroyed on a turbolinks:before-cache event

While using material tabs I found a similar error: When the page is loaded with turbolonks the tabs apparently doesn't work and no content is displayed if you click on tabs but if you loaded without turbolinks everything works.

Generally speaking it happends with many of custom JS snippets inserted in pages. Agree with @marctc: turbolinks causes a lot of troubles in this project.

 Probably, you can fill a feature request to it.

Btw, tabs not working, b/c you didn't initialize it on turbolinks:load event


HBASE-24351 Backport HBASE-24302 to branch-1

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

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

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

_ branch-1 Compile Tests _

+1 :green_heart:
mvninstall
8m 44s
branch-1 passed

+1 :green_heart:
compile
0m 44s
branch-1 passed with JDK v1.8.0_252

+1 :green_heart:
compile
0m 47s
branch-1 passed with JDK v1.7.0_262

+1 :green_heart:
checkstyle
1m 37s
branch-1 passed

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

+1 :green_heart:
javadoc
0m 43s
branch-1 passed with JDK v1.8.0_252

+1 :green_heart:
javadoc
0m 40s
branch-1 passed with JDK v1.7.0_262

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

+1 :green_heart:
findbugs
2m 54s
branch-1 passed

_ Patch Compile Tests _

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

+1 :green_heart:
compile
0m 42s
the patch passed with JDK v1.8.0_252

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

+1 :green_heart:
compile
0m 48s
the patch passed with JDK v1.7.0_262

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

-1 :x:
checkstyle
1m 32s
hbase-server: The patch generated 7 new + 10 unchanged - 4 fixed = 17 total (was 14)

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

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

+1 :green_heart:
hadoopcheck
5m  2s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

+1 :green_heart:
javadoc
0m 32s
the patch passed with JDK v1.8.0_252

+1 :green_heart:
javadoc
0m 42s
the patch passed with JDK v1.7.0_262

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

_ Other Tests _

+1 :green_heart:
unit
126m 52s
hbase-server in the patch passed.

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

168m 30s

Subsystem
Report/Notes

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

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

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

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

Build tool
maven

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

git revision
branch-1 / 29c24e7

Default Java
1.7.0_262

Multi-JDK versions
/usr/lib/jvm/zulu-8-amd64:1.8.0_252 /usr/lib/jvm/zulu-7-amd64:1.7.0_262

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

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

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

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

_ branch-1 Compile Tests _

+1 :green_heart:
mvninstall
8m 32s
branch-1 passed

+1 :green_heart:
compile
0m 39s
branch-1 passed with JDK v1.8.0_252

+1 :green_heart:
compile
0m 44s
branch-1 passed with JDK v1.7.0_262

+1 :green_heart:
checkstyle
1m 38s
branch-1 passed

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

+1 :green_heart:
javadoc
0m 41s
branch-1 passed with JDK v1.8.0_252

+1 :green_heart:
javadoc
0m 41s
branch-1 passed with JDK v1.7.0_262

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

+1 :green_heart:
findbugs
2m 51s
branch-1 passed

_ Patch Compile Tests _

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

+1 :green_heart:
compile
0m 43s
the patch passed with JDK v1.8.0_252

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

+1 :green_heart:
compile
0m 45s
the patch passed with JDK v1.7.0_262

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

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

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

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

+1 :green_heart:
hadoopcheck
4m 50s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2.

+1 :green_heart:
javadoc
0m 31s
the patch passed with JDK v1.8.0_252

+1 :green_heart:
javadoc
0m 39s
the patch passed with JDK v1.7.0_262

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

_ Other Tests _

+1 :green_heart:
unit
123m 53s
hbase-server in the patch passed.

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

170m 18s

Subsystem
Report/Notes

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

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

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

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

Build tool
maven

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

git revision
branch-1 / 29c24e7

Default Java
1.7.0_262

Multi-JDK versions
/usr/lib/jvm/zulu-8-amd64:1.8.0_252 /usr/lib/jvm/zulu-7-amd64:1.7.0_262

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=1.9.1 maven=3.0.5 findbugs=3.0.1

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

This message was automatically generated.


Readd az-snp-vtpm verifier

Readded the az-snp-vtpm verifier to the default verifiers, so it will get built in kbs, also adjusted the paths that have been used in the tests to match the refactoring.
fixes #102

@mkulke @Xynnn007 Should we create a 0.6.1 AS release and try to sneak this into v0.6.0 or wait until v0.7.0?

@mkulke @Xynnn007 Should we create a 0.6.1 AS release and try to sneak this into v0.6.0 or wait until v0.7.0?

If it's tolerable effort it would be nice to have it in v0.6.

If it's tolerable effort it would be nice to have it in v0.6.


Added foss to db.json

Changes proposed
Added the abbreviation for Free Open Source Software.

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Hey! Can we try running the tests again.

Looks like it failed again, might need some guidance.
How about I Delete my fork and try a new PR?
Thank you for your time and advice!

Thank you for your time and advice!

Oh. It failed again. Deleting your fork is an option. But did you try pulling?

Thank you for your time and advice!

Oh. It failed again. Deleting your fork is an option. But did you try pulling?

Is this the option I should be looking for? I've tried "Update Branch" from "Sync Fork".

Is this the option I should be looking for? I've tried "Update Branch" from "Sync Fork".

Good thinking. That has updated your fork. Now in your terminal, in the working directory of your fork, run git pull

Is this the option I should be looking for? I've tried "Update Branch" from "Sync Fork".

Good thinking. That has updated your remote fork. Now in your terminal, in the working directory of your fork, run git pull

Doesn't seem to have made any changes


Composite keys are not working

In case your documents have composite keys, they don't work for "edit" and "delete".

Can you provide an example?

Hi,
Example document:
{
"_id": {
"topic": "events",
"partition": 0,
"clientId": "secevents"
},
"offsetValue": 14
}
Link created for Edit button:
http://mongo-manager/Mongo-X/technical/offset/edit/[object Object]?type=object
Observe the "[object Object]" in the path. Most probably this is the source of the problem.
Cheers,
Tamas

Thank for reporting. At this stage it is difficult to support documents indexed like this. Maybe in the future something can be worked out.
I'm happy to accept a pull request if you fix it.


Way to see how many tags and words you've written in a day

Should maybe go on the report page?

This sounds like something a lot of our 4tw fans would enjoy. I'd be happy to try making this happen.

The existing user#output page is probably related to this? At minimum you could probably borrow some code from that


Skip ad programmatically

Hello,
I have following case:

pre-roll + video
video
video
pre-roll + video
video
video

I have just one VMAP file where i have defined pre-roll. Everytime when i want to show pre-roll i am calling following functions:
this.player.ima.setContentWithAdTag(
    this.currentVideo.url,
    this.adData.video.ad.googleUrl,
    false);
this.player.ima.requestAds();

When i want to not show Ad i just don't run this code but on start and on end of video there is some timeout and player waiting for ad and loading spinner is shown.
Question: Is it possible somehow tell to ima plugin to not load any ad and just skip to another video ?

Hi @mihalikv ,
I wanted to check if you found a solution to your issue or if you wanted us to look into it.
Jackson
IMA SDK DevRel

Hi @Kiro705 ,
I am not sure how I solve this issue, it was year ago :(. So we can close this issue for now.


add Node.js to builder

Summary

Add Node.js to the Jammy Base builder.
Use Cases

Checklist

[X] I have viewed, signed, and submitted the Contributor License Agreement.
[X] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[X] I have added an integration test, if necessary.
[X] I have reviewed the styleguide for guidance on my code quality.
[X] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

@fg-j Should we make this a minor release?


Please update your documentation!

I opened a issue more than a year ago, asking how to use secure files in a custom task here.
I still need this functionality today, and your documentation STILL points to the common module, which is NOT available in custom tasks!

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

ID: 140dcb9a-2ed0-11d5-064b-068f863ed97f
Version Independent ID: 672d2aa3-cf0d-9207-c97c-e2eba14506b7
Content: Secure files for Azure Pipelines and Team Foundation Server - Azure Pipelines
Content Source: docs/pipelines/library/secure-files.md
Product: devops
Technology: devops-cicd
GitHub Login: @thomps23
Microsoft Alias: madhurig

@BiribiriJaNai I am sorry that this issue has persisted for so long, I am going to see if I can find the answer and get our documentation updated.


RequestError: Error: Invalid URI "api/v1/access_token"

RequestError: Error: Invalid URI "api/v1/access_token"     at new RequestError (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request-promise-core/lib/errors.js:14:15)     at Request.plumbing.callback (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request-promise-core/lib/plumbing.js:87:29)     at Request.RP$callback [as _callback] (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request-promise-core/lib/plumbing.js:46:31)     at self.callback (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/request.js:373:22)     at Request.emit (node:events:394:28)     at Request.init (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/request.js:443:17)     at Request.RP$initInterceptor [as init] (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request-promise-core/configure/request2.js:45:29)     at new Request (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/request.js:283:8)     at request (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/index.js:50:10)     at snoowrap. (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/index.js:141:14)     at snoowrap.credentialedClientRequest (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/snoowrap/dist/request_handler.js:217:47)     at snoowrap.updateAccessToken (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/snoowrap/dist/request_handler.js:264:17)     at /Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/snoowrap/dist/request_handler.js:83:18     at tryCatcher (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/util.js:16:23)     at Promise._settlePromiseFromHandler (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:547:31)     at Promise._settlePromise (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:604:18)     at Promise._settlePromise0 (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:649:10)     at Promise._settlePromises (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:729:18)     at Promise._fulfill (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:673:18)     at Promise._resolveCallback (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:489:14)     at Promise._settlePromiseFromHandler (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:559:17)     at Promise._settlePromise (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:604:18)     at Promise._settlePromise0 (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:649:10)     at Promise._settlePromises (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:729:18)     at Promise._fulfill (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:673:18)     at Timeout._onTimeout (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/timers.js:26:46)     at listOnTimeout (node:internal/timers:557:17)     at processTimers (node:internal/timers:500:7) {   cause: Error: Invalid URI "api/v1/access_token"       at Request.init (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/request.js:443:31)       at Request.RP$initInterceptor [as init] (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request-promise-core/configure/request2.js:45:29)       at new Request (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/request.js:283:8)       at request (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/index.js:50:10)       at snoowrap. (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/index.js:141:14)       at snoowrap.credentialedClientRequest (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/snoowrap/dist/request_handler.js:217:47)       at snoowrap.updateAccessToken (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/snoowrap/dist/request_handler.js:264:17)       at /Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/snoowrap/dist/request_handler.js:83:18       at tryCatcher (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/util.js:16:23)       at Promise._settlePromiseFromHandler (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:547:31)       at Promise._settlePromise (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:604:18)       at Promise._settlePromise0 (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:649:10)       at Promise._settlePromises (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:729:18)       at Promise._fulfill (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:673:18)       at Promise._resolveCallback (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:489:14)       at Promise._settlePromiseFromHandler (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:559:17)       at Promise._settlePromise (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:604:18)       at Promise._settlePromise0 (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:649:10)       at Promise._settlePromises (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:729:18)       at Promise._fulfill (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:673:18)       at Timeout._onTimeout (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/timers.js:26:46)       at listOnTimeout (node:internal/timers:557:17)       at processTimers (node:internal/timers:500:7),   error: Error: Invalid URI "api/v1/access_token"       at Request.init (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/request.js:443:31)       at Request.RP$initInterceptor [as init] (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request-promise-core/configure/request2.js:45:29)       at new Request (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/request.js:283:8)       at request (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/index.js:50:10)       at snoowrap. (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/request/index.js:141:14)       at snoowrap.credentialedClientRequest (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/snoowrap/dist/request_handler.js:217:47)       at snoowrap.updateAccessToken (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/snoowrap/dist/request_handler.js:264:17)       at /Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/snoowrap/dist/request_handler.js:83:18       at tryCatcher (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/util.js:16:23)       at Promise._settlePromiseFromHandler (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:547:31)       at Promise._settlePromise (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:604:18)       at Promise._settlePromise0 (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:649:10)       at Promise._settlePromises (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:729:18)       at Promise._fulfill (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:673:18)       at Promise._resolveCallback (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:489:14)       at Promise._settlePromiseFromHandler (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:559:17)       at Promise._settlePromise (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:604:18)       at Promise._settlePromise0 (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:649:10)       at Promise._settlePromises (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:729:18)       at Promise._fulfill (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/promise.js:673:18)       at Timeout._onTimeout (/Users/navdeepsharma/Desktop/Reddit Video Maker/node_modules/bluebird/js/release/timers.js:26:46)       at listOnTimeout (node:internal/timers:557:17)       at processTimers (node:internal/timers:500:7),   options: {     form: {       grant_type: 'password',       username: 'confidential',       password: 'confidential'     },     uri: 'api/v1/access_token',     method: 'POST',     baseUrl: 'https://www.reddit.com',     headers: { 'user-agent': 'PGamerX' },     auth: {       user: 'confidential',       pass: 'confidential'     },     json: true,     gzip: true,     callback: [Function: RP$callback],     tunnel: false,     transform: undefined,     simple: true,     resolveWithFullResponse: false,     transform2xxOnly: false   },   response: undefined }

@charlypoirier I havent changed the code a bit, it worked fine 1 month back.
Today I decided to rerun but it didnt

I just tried generating a video (been a while) and everything worked.
The error you're getting seems to come from snoowrap, the library Redditube uses to communicate with Reddit.
I found someone having the same issue (4 years ago) but without much more information. So I'm not sure why that happens.
What you can try

Make sure you have the correct credentials, there.
If you are using a refresh_token, try using your Reddit username and password instead.
Try reinstalling dependencies.

$ rm -r node_modules/
$ npm install

Try using another Node.js version (I use Node.js v16.6.0 now, but used older versions in the past without any problems).


Fix specifying of Kubernetes version from build scripts

This bug came about because of three issues that this change
corrects:

The CI scripts run on a pull request did not test building
Helm. This means that a failure to set a variable using LDFLAGS
had no opportunity to be caught.
#8608 provided a means to match the k8s version used in linting
and chartutil with the version of the package we pull in. With
one problem. It attempts to set a const as if it were a string.
This is ignored and everyone missed it.
#10325 moved those constants to vars so it could be set. This
looked good and passed tests but missed that you can't set an
int as if it were a string. See first bullet.

This change fixes this by moved the internal representation to
be a string. These are internal variables not exposed in the public
API which makes this change non-breaking to the API.
Closes #10367

What this PR does / why we need it: It fixes Helm on main being unable to be built right now.
Special notes for your reviewer: N/A
If applicable:

[ ] this PR contains documentation
[ ] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

I pulled down the branch with this PR and tested make locally. It built without errors and produced a plausible artifact:
$ bin/helm version
version.BuildInfo{Version:"v3.7+unreleased", GitCommit:"7838fb769d00f53c858d994a873f42c2960a7d25", GitTreeState:"clean", GoVersion:"go1.16.3"}

It looks like CodeQL ran but something stopped the status from updating. See https://github.com/helm/helm/actions/runs/1477452626

Odd... I'm okay with merging this. Feel free to merge when ready.

@bacongobbler thanks. I opened an issue with GitHub because rerunning CI didn't cause it to run and it never timed out. Giving them a short bit of time to look at this.


Docs : Added contributor section to README.md

[ Please outline your change here. Be sure to check the checkboxes below. ]
Summary: Added a Contributors section to the README.md file to acknowledge all project contributors. This improves visibility and gives credit to those supporting the project.
Documentation change checklist

[x] My documentation changes follow the docs style guide and any code examples follow the coding style guide.
[x] I tested that my change works before raising the PR (via running doxygen, and testing examples).
[x] I have not moved any existing pages or changed any existing URLs without strong justification as to why.
[x] I have not generated content using AI or a desktop utility such as grammarly.

@braindigitalis Could you kindly remove the spam label? This is my first time participating in Hacktoberfest, and I’ll make sure to follow the guidelines closely in the future. Thank you for your understanding.


Cannot enable dragging dynamically

I have a very simple code:
const EditableGridLayout = props => {
  const [drag, setDrag] = useState(false);

  return (
    <>
      <ResponsiveGridLayout {...props} isDraggable={drag}>
        ...
      </ResponsiveGridLayout>
      <button onClick={() => setDrag(drag => !drag)}>Toggle DnD</button>
    </>
  );
}

However, the item does not become draggable. I went into React DevTools and the GridItem component receives the correct isDraggable prop; however, in DraggableCore component, the prop disabled is true.
Weirdly, when I changed the disabled prop manually from DevTools for one grid item, the dragging started working for all items.
How can enable dragging dynamically?
CodeSandbox: https://codesandbox.io/s/serene-dubinsky-16q9r
EDIT: It looks like it is not working because I am "decorating" the responsive grid.

@GasimGasimzada
Set the isDraggable property on each item - it overrides the global isDraggable property:
https://codesandbox.io/s/patient-star-7bsy7


ROS Version

It is mentioned that this simulator is developed using ROS Melodic. I have ROS Noetic on my device. Will it work on ROS Noetic or will I need to change my version of ROS?

If you're willing to wait two months or so we're planning to update vrx to Gazebo 11 and ROS Noetic. If you need it right now, the safest bet is to use ROS Melodic.


Artifacts and issues with Samsung Galaxy A15

Hello,
While using the latest version of the app (2.5.1 - unmodified), I have come across some issues, specifically with my Samsung Galaxy A15 device (I've used my older A40 as well and seems to work better, but not perfectly either.
On the A15, using "Rotation" mode with video source "CameraUVC", I'm getting some artifacts on the feed, depicted in the screenshot below. The A40 seems to work just fine. The external camera I'm using is "Creative Live! Cam Sync 1080p V2".
When I say "artifacts" I mean the gray horizontal lines and the fact that the image looks to be splitted between 3 sections in a row.

I have seen similar artifacts in other external camera feed capturing apps as well (in some cases more severe), but there are other apps that display a clean view on this device.
Also I've tried with Eachine White Snake FPV Camera, but it doesn't work at all.
BTW I'm using an OTG cable adapter (usb-c to usb-a).
Samsung Galaxy A15:

Android version: 14
One UI version: 6.1

Samsung Galaxy A40:

Android version: 11
One UI version: 3.1

Hello,
I just do a fix related with UVC camera:
https://github.com/pedroSG94/RootEncoder/commit/e53214690b917042989e45dd108bb8e17f98cf64
Try update master branch and let me know if the problem persist. If you still have problems, try to open the camera using this project (this is the dependency used to add UVC camera support):
https://github.com/shiyinghan/UVCAndroid

No changes with e532146... Will try the UVCAndroid repo, thanks


Assessment<2>

Metric
Value

alert_status
:white_check_mark: OK

bugs
0

code_smells
13

reliability_rating
A (0 Bugs)Note: A being best, E being worst

security_rating
A (0 Vulnerabilities)Note: A being best, E being worst

vulnerabilities
0


Update to 2.031

Add support for various upgrades and achievements in sim gains calculations up to v2.031.
Upgrades
Add support for the following upgrades:

Dragon scale
Milkhelp® lactose intolerance relief tablets

Achievements
Add support for the following achievements:

Quincentennial and a half
Sexcentennial
Grand design
Ecumenopolis
The full picture
When there's nothing left to add
Gotta hand it to you
The devil's workshop

Fix numbers for the following achievements:

Polymath
Renaissance baker

This closes #302, closes #310, and closes #317

I'm still having some negative numbers displayed at some point, so I'm closing this for now until I fix it.


chore(Topology): replace even more refine' by refine

(or, in one case, apply since this worked where refine didn't).

We can take care of terminal refine in another PR (since sometimes exact is slower this is not completely trivial). Thanks!
bors merge


Testcafe doesn't work with Hellosign

Are you requesting a feature or reporting a bug?
Bug
What is the current behavior?
Our original problem was that Testcafe could not click on any elements in an iframe created by Hellosign even after switching to that iframe.
To demonstrate the issue, I asked Hellosign for a test page. I recorded a test against it using Test Cafe but it errors immediately when trying to replay. I modified the code to test simple selectors and even those fail.
I suspect there is something block testing of this iframe as a whole. Test Cafe otherwise works well for us.
What is the expected behavior?
Can find selectors, click on items, and sign document
How would you reproduce the current behavior (if this is a bug)?
Run the below code
Provide the test code and the tested page URL (if applicable)
Tested page URL: https://app.hellosign.com/api/embeddedTest
Test code
import { Selector } from "testcafe";

fixture`Hellosign Embed Test`.page`https://app.hellosign.com/api/embeddedTest`;

test("hellosign modal", async t => {
    await t
        // A few obvious selectors that didn't work:
        // .expect(Selector("div").withText("Embedded Testing Tool").exists) // doesn't work
        // .expect(Selector("h3").withText("Embedded Url").exists); // doesn't work either

        // Everything below was generated by Testcafe Record, still doesn't work
        // .click(Selector("span").withText("GET A SAMPLE DOCUMENT")); // tried lowercase as well, doesn't work
        .switchToIframe(Selector("#hsEmbeddedFrame"))
        // .wait(5000)
        .click(Selector("span").withText("GET STARTED"))
        .click(
            Selector("#component_1721320110_1")
                .find("span")
                .withText("Click to sign")
        )
        .click(
            Selector(".m-sign-modal--menu--item--label")
                .nth(1)
                .find("span")
                .withText("Type it in")
        )
        .click(Selector("#insertButton"))
        .click(
            Selector(".l-nowrap")
                .find("span")
                .withText("CONTINUE")
        )
        .click(
            Selector(".l-nowrap")
                .find("span")
                .withText("I AGREE")
        )
        .click(
            Selector(".l-nowrap")
                .find("span")
                .withText("CLOSE")
        );
});

Specify your

operating system: Chrome 69.0.3497 / Mac OS X 10.13.6
testcafe version: 0.3.0
node.js version: v10.8.0

I've modified your testcode and it works now:
import { Selector } from 'testcafe';

fixture`Hellosign Embed Test`.page`https://app.hellosign.com/api/embeddedTest`;

test('hellosign modal', async t => {
    await t.wait(1000);
    await t.click(Selector('span').withText('GET A SAMPLE DOCUMENT'));
    await t.click(Selector('span').withText('LAUNCH EMBEDDED PAGE'));

    await t.expect(Selector('div').withText('Embedded Testing Tool').exists).ok();
    await t.expect(Selector('h3').withText('Embedded URL').exists).ok();

    await t.switchToIframe(Selector('#hsEmbeddedFrame'));
    await t.setNativeDialogHandler(() => true);
    await t.click(Selector('span').withText('GET STARTED'));
});

I also noticed several mistakes:

.expect(Selector("div").withText("Embedded Testing Tool").exists) - use ok() as in my code.
.expect(Selector("h3").withText("Embedded Url").exists); - the withText argument is case-sensitive.
I've found that some errors occur on the test page. To ignore them, please add the -e param to the cli command.


Setup github actions

Coverage remained the same at 95.69% when pulling e1ecdfbb3f7237e3be965bed9f8641c89bb92619 on github-actions into 3d934435edc8094346efd9bac490235b299f94ab on master.


Recovering Bch

I’m using the latest version of Copay on my phone. I don’t have the “bitcoin-cash support” tab in settings instead it just says “bitcoin cash”. I would like to recover Bch from the fork last year. I’m certain I had btc in there at the time

Tap in "bitcoin cash", then in "Duplicate for BCH"

I've sent bch to my btc copay wallet, when I tap settings > bitcoin cash it says that my bch are there, the exact amount. When I tab on duplicate a bch wallet is created but no sign of the bch, I already tried the recovery tool. It says 0 bch. I already checked the transaction, it has been confirmed 2 days ago.
Could anyone please help me? It's a descent amount and I've worked hard for it :(

This is insane, copay isn't fixing this? I just sent another 0.1 to the address as a test, transaction was completed. But also the 0.1 is lost now. When I click on duplicate it shows 0.0 bch, scanning the wallet results in 0.0 bch to. But before I click on duplicate it says 8.23 bch?

For further info follow #8460
Thanks, regards.

@JohnJJJ
I can recover your wallet if you want need help send me email<EMAIL_ADDRESS>


❓ [Paperless] How to run document_renamer command

Hello, I've recently updated the filename format for my documents and now I want to use the document_renamer command from paperless through the Home Assistant addon to organize all documents into the new format. Could you guide me on how to execute this command with the Home Assistant addon?

Hi, you can execue custom commands using portainer : https://github.com/alexbelgium/hassio-addons/wiki/Portainer

Thanks, that worked 👍🏼


version bump to <IP_ADDRESS>

Change to instance rename logic in gce/sysprep/instance_setup.ps1

LGTM.


[cxx-interop] Fix namespace lookup

If a namespace has redecls in different modules, Swift sometimes picked a redecl which is not visible from the requested module, and wrongly removed the namespace from lookup results.
This resulted in errors like this:
*** DESERIALIZATION FAILURE ***
Could not deserialize type for 'init(cxxString:)'
Caused by: top-level value not found (std)
Cross-reference to module '__ObjC'
... std

We'll need one more lookup fix before we can properly test this.
This is a requirement for https://github.com/apple/swift/pull/58452.


Fix source php version check

Recipe source php version check is wrong and causes download and build steps to always run.

Nice catch. Thanks


Issue 1085 tf widget performance

Incorporated a stride into our histogram generation, as well as calls to DataMgr::GetVariableRange().  Also now changing the histogram color to grey when it's out of date.

@shaomeng I don't know if you received a notification, but this PR needs your review.
thanks - jc

Sorry, I saw myself became an "assignee" and wasn't sure what that is...
I'll review it soon!
On Mon, Dec 17, 2018 at 4:12 PM clyne<EMAIL_ADDRESS>wrote:

@shaomeng https://github.com/shaomeng I don't know if you received a
notification, but this PR needs your review.
thanks - jc
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NCAR/VAPOR/pull/1095#issuecomment-448034378, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxvJQ_X07TgtpTaxh_fWZ-cOaT5Ls3pks5u6CTegaJpZM4ZWrcX
.

Which part of the code calculates the histogram with full accuracy? Or we lost this capability permanently?

Correct, we are no longer using full accuracy.

@sgpearse If we don't support full accuracy histograms, and always calculate it with a hard-coded stride number, then why do we create a params entry for stride?

Think about it twice, should we have a more intelligent logic to choose the stride value, instead of hard-code a sixteen? This logic could be pretty simple, like when the total grid point number is greater than a threshold, we set stride = 16, otherwise no stride. We could even use stride=32 for very large grids. This simple logic could make our approach much more applicable in various cases. What do you think @clyne ?

@clyne and @shaomeng,
Sam, your change requests are in.  Note that there's a workaround in the RenderParams, which has duplicate code for calculating the stride (copied from TFWidget).  This is going to be fixed during a refactorization of RenderParams (and maybe ParamsBase?) so that their responsibilities are lessened, but we're just a band-aid for now.

@sgpearse Scott, could you double check the delta calculation in MappingFrame.cpp?
The following lines, are they correct?
    double dx = (maxExts[X]-minExts[X])/(1+SAMPLE_RATE);
    double dy = (maxExts[Y]-minExts[Y])/(1+SAMPLE_RATE);
    double dz = (maxExts[Z]-minExts[Z])/(1+SAMPLE_RATE);

Yes, that is correct.

My understanding is that for stride values, when they're small (likely 1, 2, 3, 4, etc), it's a lot slower to have a statement itr += stride than ++itr. It's only when the stride is large enough, the former use has performance advantage. Is it true? If so, have we taken this into consideration? @sgpearse

Your delta calculation, double dx = (maxExts[X]-minExts[X])/(1+SAMPLE_RATE); still confuses me. I'll need some clarification from @sgpearse later today.

@sgpearse Scott, could you double check the delta calculation in MappingFrame.cpp?
The following lines, are they correct?
    double dx = (maxExts[X]-minExts[X])/(1+SAMPLE_RATE);
    double dy = (maxExts[Y]-minExts[Y])/(1+SAMPLE_RATE);
    double dz = (maxExts[Z]-minExts[Z])/(1+SAMPLE_RATE);

Doesn't look correct to me either. If SAMPLE_RATE is the total number of samples you should divide by SAMPLE_RATE-1

Line 341 of MappingFrame.cpp is the following:
for (int k=0; k<=kSamples; k++) {
This means when you have a value in variable kSamples, you actually sample one more value along that axis. Not a good coding practice. Can you either change the name of the variable, or change the loop termination condition so that the variable name does reflect the number of samples?

Ok, I've changed the variable names to more accurately reflect count and incrementation.

My understanding is that for stride values, when they're small (likely 1, 2, 3, 4, etc), it's a lot slower to have a statement itr += stride than ++itr. It's only when the stride is large enough, the former use has performance advantage. Is it true? If so, have we taken this into consideration? We will likely need to run some timing numbers to decide what stride number is big enough to give us a performance gain.

I think you're most likely correct, and that this would probably improve our performance.  I'm apprehensive on implementing it right now for a few reasons.

There's a pretty high priority bug that I need to address.

Our performance improvements over the past few weeks seem to have given Vapor a satisfactory response time.  Without more evidence, I think there's more of a risk to introduce regressions with more modifications to the stride calculation than there are rewards.

I know that the iterator stride is used in other places in the code base, not just here.

I think we should make a feature request of this and revisit.

For some reason won't let me provide an in-line response to Sam's comment:
"My understanding is that for stride values, when they're small (likely 1, 2, 3, 4, etc), it's a lot slower to have a statement itr += stride than ++itr. It's only when the stride is large enough, the former use has performance advantage. Is it true? If so, have we taken this into consideration? We will likely need to run some timing numbers to decide what stride number is big enough to give us a performance gain."
@shaomeng is correct. For a stride of 1 the ++ operator is faster than +=. For larger strides the += is faster. Mileage will varying on where the break even point is. I don't think we should do an analysis now. Let's move on.

@clyne @sgpearse  Mileage will varying on where the break even point is, but it's definitely not 1. In other words, we choose any reasonable value greater than one, could be 3, 4, 5, it'll be better than what is currently there right now, before we run a precise analysis.
Regarding the time to revisit it, I think right now is the best time, since this feature isn't in the master yet. It'll be much more difficult to come back and address it once it got merged, both psychologically and according to how we used to deal with similar situations. I would agree that a precise analysis is optional, but choosing a number and implement the logic is necessary.

Doesn't look correct to me either. If SAMPLE_RATE is the total number of samples you should divide by SAMPLE_RATE-1

The division actually needs to just be by SAMPLE_RATE (not SAMPLE_RATE-1 as sam has emphasized).  We are nudging the first sample by delta/2 so that we are slightly within the bounds of the domain.  This avoids retrieving missing values at the edge.

Then you should probably add some comments to that effect because as it stands the code looks wrong.

On Dec 21, 2018, at 11:59 AM, sgpearse<EMAIL_ADDRESS>wrote:
Doesn't look correct to me either. If SAMPLE_RATE is the total number of samples you should divide by SAMPLE_RATE-1
The division actually needs to just be by SAMPLE_RATE (not SAMPLE_RATE-1 as sam has emphasized). We are nudging the first sample by delta/2 so that we are slightly within the bounds of the domain. This avoids retrieving missing values at the edge.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

John Clyne
National Center for Atmospheric Research
303.497.1236 (w),<PHONE_NUMBER> (c)
<EMAIL_ADDRESS>

Sam, I would like to get this rather large branch merged before Scott and I both disappear for the holiday. The code is correct. There are only minor performance considerations. They are minor, because the way the stride is calculated unit stride will only result for very small data sets, in which case the performance penalty will be negligible.

On Dec 21, 2018, at 11:53 AM, Samuel Li<EMAIL_ADDRESS>wrote:
@clyne @sgpearse Mileage will varying on where the break even point is, but it's definitely not 1. In other words, we choose any reasonable value greater than one, could be 3, 4, 5, it'll be better than what is currently there right now, before we run a precise analysis.
Regarding the time to revisit it, I think right now is the best time, since this feature isn't in the master yet. It'll be much more difficult to come back and address it once it got merged, both psychologically and according to how we used to deal with similar situations. I would agree that a precise analysis is optional, but choosing a number and implement the logic is necessary.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

John Clyne
National Center for Atmospheric Research
303.497.1236 (w),<PHONE_NUMBER> (c)
<EMAIL_ADDRESS>

@clyne The current code will result in a stride of 1 with 125^3 cubes, and stride of 2 with 158^3 cubes, and 3 with 181^3 cubes. They sure look small, but I remember we used to spend seconds to calculate the histogram with similar sizes. If  the break even point is bigger than 3, then we're degrading performance at 181^3 scale.

@shaomeng By my calculations a non-unit strides results for grids over 1,000,000 grid points (100^3), which is what Scott and I agreed upon. This is ~32 times smaller than Leigh’s data (371x401x201) where I did my benchmarking before doing any optimizations and found the histogram calculation to take ~2.5 seconds. Moreover, I’ve already benchmarked this branch and found the performance to be reasonable. Let’s close this issue and move on.
Scott, if there are no further code correctness issues I’m prepared to accept this PR.
thanks -jc

On Dec 21, 2018, at 12:18 PM, Samuel Li<EMAIL_ADDRESS>wrote:
@clyne The current code will result in a stride of 1 with 125^3 cubes, and stride of 2 with 158^3 cubes, and 3 with 181^3 cubes. They sure look small, but I remember we used to spend seconds to calculate the histogram with similar sizes. If the break even point is bigger than 3, then we're degrading performance at 181^3 scale.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

John Clyne
National Center for Atmospheric Research
303.497.1236 (w),<PHONE_NUMBER> (c)
<EMAIL_ADDRESS>

@clyne I'm OK with moving on, but a quick correction, a grid size of 1,999,999 (~2Million) will result in a stride size one.
(Line 329-330 in TFWidget.cpp)


Better docs and errors about expand_dims() view

[x] Closes #2891
[x] Tests added
[x] Fully documented, including whats-new.rst for all changes and api.rst for new API

Hello @DavidMertz! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file xarray/core/dataarray.py:

Line 1275:75: W291 trailing whitespace

In the file xarray/core/dataset.py:

Line 2519:76: W291 trailing whitespace

In the file xarray/tests/test_indexing.py:

Line 148:41: E231 missing whitespace after ','
Line 148:45: W291 trailing whitespace
Line 149:71: W291 trailing whitespace
Line 150:68: W291 trailing whitespace
Line 151:44: E261 at least two spaces before inline comment

Thanks!


Fixes histogram normalisation bug

This PR introduces a change that allows to calculate and store the original vertical scale (yScale), fixing a bug with the representation of data.
Now the yScale is calculated once and stored. The calls to retrieve more data are represented based on the original scale. The scale can be updated (using the updateYScale method) or reverted to its original values (with resetYScale).
CR: @javisantana

:es:


Improve the way we consume collection(s) to avoid sending all metadata in all pages

Related to trimming down the window.collection.  #712
When you add in new custom meta (like in this blog post example) all those extra fields are also added to the window.collection data. This could potentially make it HUGE
Example:

---
layout: Post
title: 'Defining Serverless and Why It Matters to Developers'
date: 2016-09-01
description: "You’ve probably heard the term _serverless._ But what does it actually mean? And more importantly, as a developer, why should you care?"
author:
  name: Serverless
  url: http://twitter.com/goServerless
  avatar: https://avatars3.githubusercontent.com/u/13742415?v=3&s=60
tags:
- serverless

---

```json
// printed in window.collection, notice the custom meta values
{
    "layout": "Post",
    "comments": true,
    "title": "Defining Serverless and Why It Matters to Developers",
    "date": "2016-09-01T00:00:00.000Z",
    "description": "You’ve probably heard the term _serverless._ But what does it actually mean? And more importantly, as a developer, why should you care?",
    "author": {
        "name": "Serverless",
        "url": "http://twitter.com/goServerless",
        "avatar": "https://avatars3.githubusercontent.com/u/13742415?v=3&s=60"
    },
    "tags": ["serverless"],
    "__filename": "blog/defining-serverless-and-why-it-matters-to-developers.md",
    "__url": "/blog/defining-serverless-and-why-it-matters-to-developers/",
    "__resourceUrl": "/blog/defining-serverless-and-why-it-matters-to-developers/index.html",
    "__dataUrl": "/blog/defining-serverless-and-why-it-matters-to-developers/index.html.bf1d5e0db467ef721b8508992749379b.json"
}

All the data also exists in the index.html.bf1d5e0db467ef721b8508992749379b.json file.
So the question is, would it be possible/worth it to remove the additional custom fields from outputting into window.collection and just have the .json files for the individual pages handle that additional data?

would it be possible/worth it to remove the additional custom fields from outputting into window.collection

It depends on use cases. If user doesn't require any of these field in their codebase for generating a list of posts, it's possible to remove them. See collections API https://phenomic.io/docs/usage/collections/
Does it worth it? I don't know. In the huge site of yours, if you remove all of these custom fields how much bytes do you gain ?

I am currently discussing with @bloodyowl to improve Phenomic collection API in order to stop sending almost all data into all pages. The idea is mainly to only put in the pages the data used (minimal json) and create json for each possibles pages.
For now I don't plan to add a custom way to retrieve only some fields, because if we choose the solution above, it won't be a big deal (tell me if I am wrong) to get all fields for, let's say, the 10 pages you are listing.
Again I repeat the idea we are working on: only put in the html (& json files for client nav) the data requested by a page. So no more extra unused json.
To achieve that, in order to keep an API simple (not by adding a graphql server - please @bloodyowl and others, take a look to this & tell me what you think, I personally thing it's a bit crazy to go this path, but I may be wrong) the idea is to provides HoC.
Here is some pseudo code we have in mind (API subject to changes):
class YouPageThatListContent extends ...

export default Phenomic.createContainer(
  YouPageThatListContent,
  (store) => ({
     pages: store.get("pages", { sortBy: "date", order: "DESC", limit: 5})
   })
)

// alternative
export default Phenomic.createContainer(
  YouPageThatListContent,
  (state) => ({
     pages: Phenomic.queryCollection(state.pages, { sortBy: "date", order: "DESC").slice(0, 5)
   })
)

Now you are going to ask: what about pagination? Imo this should be in core, not in a plugin...
Ok then here is an idea:
<Route
  path="/tag/:tag(/:page??)" component={ YouPageComponent }
  collection="posts" pageSize={20} sortBy="date" order="DESC"
  filter={ (item, routeParams) => item.tags.indexOf(routeParams.tag) > 0) }
/>

// ...

// YouPageComponent
export default Phenomic.createContainer(
  YouPageThatListContent,
  (state, page) => ({
     taggedPosts: pages.items,
     // you can send any kind of data, injected as props into YouPageThatListContent
     totalPages: pages.numberOfItems,

     // while pagination is allowed for one resource at a time, you might get other data as well
     authors: Phenomic.queryCollection(state.authors, { sortBy: "commits", order: "DESC").slice(0, 5)
    someRandomPosts: Phenomic.queryCollection(state.posts).randomMethodToImplement(5)
   })
)

Not that the code above assume that we will introduce a new way to register collectionS (yes multiple collections, instead of having to filter via layout or something else)
By doing that, we will be able to statically retrieve collections fraction and only inject that in the html (& as well create json fragments, for client navigation).
Any thoughts on this approach?

Totally agree with this approach. Filter with js runtime can be slow especially if you have a lot of pages.

Added a few changes to my proposal:
Content definition
import Phenomic from "phenomic"

// I think that we should accept:
// type Data = { [key: string]: any | Promise<any> }
// Data | Promise<Data>
module.exports = {
  // See: https://gist.github.com/bloodyowl/27e159aa9e02c5ac40fd6ff5c2bb93e8
  posts: Phenomic.createCollection(
    requireAll(require.context("markdown!./posts", true, /\.md/)),
    { indexes: ["id", "url"] } // will create JS Maps to improve query time on build & dev server
  ),
  authors: requireAll(require.context("json!./authors", true, /\.json/)),
  // accept promises
  someExternalData: require("isomorphic-fetch")(someURL),
}

Consuming the data
Indexed queries
import React from "react"
import Phenomic from "phenomic"

const PostRoute = (props) => (

{props.post.title}

{props.post.content}

)

export default Phenomic.createContainer(PostRoute, {
  queries: (state, params) => ({
    // O(1) if indexed, O(N) otherwise
    post: state.posts.getBy("id", params.id),
  })
})

"Special" queries
import React from "react"
import Phenomic from "phenomic"

const HomepageRoute = (props) => (

      {props.posts.map((post) =>

{post.title}

      )}

      {props.authors.forEach((author) =>

{author.username}

      )}

)

export default Phenomic.createContainer(HomepageRoute, {
  queries: (state, params) => ({
    posts: state.posts.queryCollection({ sortBy: "date", order: "DESC" }).slice(0, 5),
    authors: state.authors.slice(0, 5),
  })
})

Pagination
import React from "react"
import { Router, Route } from "react-router"

import PostRoute from "./PostRoute"
import HomepageRoute from "./HomepageRoute"

export default (
  <Router>
    <Route path="/" component={HomepageRoute} />
    <Route path="/post/:id" component={PostRoute} collection="posts"/>
    <Route path="/posts/page/:page" component={PostList} collection="posts" pageSize={20} />
  </Router>
)

This configuration leaves us enough information to just generate Math.ceil(collection.length / props.pageSize) pages at build time.
Phonemic.createContainer(Component, {
  queries: (state, routeParams, page) => ({
    hasNextPage: page.hasNextPage,
    posts: page.items,
  }),
})

Configuration
You basically provide your content and an instance of ReactRouter, we do the rest.
module.exports = {
  content: require("./content"),
  router: require("./web/routes/Router"),
}

Build configuration
I think that in order to prevent colliding stuff and forcing us to provide stuff for all configurations, the webpack.config.js should remain in user-land.
If you don't use the development server, webpack shouldn't even be mandatory (e.g. you get the data from an external API).
var webpack = require("webpack")
var path = require("path")

module.exports = {
  // maybe autofill entry & output, not quite sure about this yet
  entry: {
    bundle: "phenomic/lib/entry",
  },
  output: {
    path: path.join(__dirname, "./.phenomic"),
    filename: "[name].js",
  },
  module: {
    loaders: [
      {
        test: /\.js$/,
        ignore: /node_modules/,
        loader: "babel",
        query: {
          presets: ["es2015", "react"],
        },
      },
    ],
  },
  plugins: [
    new webpack.DefinePlugin({
      "process.env": {
        NODE_ENV: JSON.stringify(process.env.NODE_ENV),
      },
    })
  ],
}

What can I do to help with this? Do you have any POC?

I'm working on a POC, just need to add the PhenomicCollection and the pagination mechanism and I'll share it, that should be a good starting point 😊

Nice !

I wanted to follow up on this thread.
What do you guys think about normalizing the collection by perhaps URL?
This way we can have a constant lookup time
{
    "url/xyz/lolz": {
        "__dataUrl": "/blog/defining-serverless-and-why-it-matters-to-developers/index.html.bf1d5e0db467ef721b8508992749379b.json"
    },
    "url/two": {
        "__dataUrl": "/blog/defining-serverless-and-why-it-matters-to-developers/index.html.bf1d5e0db467ef721b8508992749379b.json"
    }
}

You could still map over the data with Object.keys if you want =)
Maybe even going a step further with https://github.com/paularmstrong/normalizr
I can probably just do this in user land but I wanted to float the idea around here as well.

With the idea we have, there's not really a need for this. But if you want to create a "static API" from your contents, that should be totally possible in user-space 😃

@bloodyowl any progress on this?

I am thinking about the fact that currently we use the entire collection to know if a click must be done using browser push + preventDefault :/

@MoOx I was thinking about this too.
Perhaps it could be solved with a 'smarter' link component.
Where each link component gets additional data attributes added to it on build. Then the link listener wouldn't need to check the collection it could just use the inline data-attr on the a tag.
example:

Local link

This might even let us remove the need for the entire collection to be placed on the window?

Newcomer to Phenomic ... Apologies for interjecting but I hope this can help others too.

Should one expect major changes to how collections are handled within the next month?
If not, it would be super helpful with another practical example in the docs on how to use the current context-based system. For example, what are the steps required to list a bunch of 'recipes' on a recipes page ... :)

@lapidus you can expect a major change in the coming weeks! ;)

Going to be fixed with #925

@bloodyowl awesome!
How is it being approached? I didn't see it mentioned in https://github.com/MoOx/phenomic/issues/925

in 1.0.0, parses output partial (to be used in lists) & data (used when fetching the item itself) + the window.collection disappears completely

@bloodyowl Cool.
A couple questions:

is all the site data still output into the DOM? Or referenced via script tag
are .json files still nested in their respective /url/path/blah/index.json folders or centralized in a single location? ref

My main concerns are making phenomic a viable option for larger website implementations =). There are certain things in the current setup that make it not an option for sites with 1000+ pages.

No, HTML will only contains relevant data for its own page
That's not really a problem. For not we are creating a sort of "static" api, so files are not just hashes, but I guess we could improve that in the future.

The goal of 1.0 is really to make something scalable by default. We are having the same concerns as you do :)
@bloodyowl tell me if it's incorrect

yeah, basically the JSON files are put in dist/phenomic and organised with the same shape they have in the dev server API


Indicate that SubTitle is a plugin in TS types

May be related to #9383

Shouldn't there also be SubTitle options too or does it take the Title options since you use the Title plugin as a basis?

You're right @LeeLenaleee. I've added that