[BACKLOG-22287] Lazy loading of folders in Repository Explorer

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'ui' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseController.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectory.java
  ui/src/main/resources/org/pentaho/di/ui/repository/repositoryexplorer/xul/explorer-layout.xul

Newly Broken Tests:
org.pentaho.di.ui.repository.repositoryexplorer.controllers.BrowseControllerTest.testInit:
:red_circle: org.pentaho.di.ui.repository.repositoryexplorer.ControllerInitializationException
org.pentaho.di.ui.repository.repositoryexplorer.ControllerInitializationException: java.lang.NullPointerException
	at org.pentaho.di.ui.repository.repositoryexplorer.controllers.BrowseControllerTest.testInit(BrowseControllerTest.java:178)
Caused by: java.lang.NullPointerException
	at org.pentaho.di.ui.repository.repositoryexplorer.controllers.BrowseControllerTest.testInit(BrowseControllerTest.java:178)

org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testGetRepositoryObjectsFilled:
:red_circle: java.lang.AssertionError
java.lang.AssertionError: expected:<1> but was:<2>
	at org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testGetRepositoryObjectsFilled(UIRepositoryDirectoryTest.java:61)

org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testGetRepositoryObjectsNulled:
:red_circle: java.lang.AssertionError
java.lang.AssertionError: expected:<1> but was:<2>
	at org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testGetRepositoryObjectsNulled(UIRepositoryDirectoryTest.java:86)

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes: +16.3% (click to expand)
:new: org.pentaho.di.trans.step.mqtt.MQTTConstants

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumer

Line Coverage: 78.6% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumerDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumerMeta

Branch Coverage: 50% :exclamation:
Complexity Coverage: 58.2% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MqttDialogOptionsLayout

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MqttDialogSecurityLayout

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducer

Branch Coverage: 66.7% :exclamation:
Complexity Coverage: 56.3% :exclamation:
Method Coverage: 71.4% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducerDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducerMeta

Branch Coverage: 50% :exclamation:
Complexity Coverage: 63.6% :exclamation:
Instruction Coverage: 74.7% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTStreamSource

Branch Coverage: 50% :exclamation:

:new: org.pentaho.di.trans.steps.aggregaterows.AggregateRows

Branch Coverage: 36.2% :exclamation:
Complexity Coverage: 30.3% :exclamation:
Instruction Coverage: 55.2% :exclamation:
Line Coverage: 60.5% :exclamation:

:new: org.pentaho.di.trans.steps.aggregaterows.AggregateRowsMeta

Branch Coverage: 0% :exclamation:
Complexity Coverage: 2.2% :exclamation:
Instruction Coverage: 10.4% :exclamation:
Line Coverage: 7.6% :exclamation:
Method Coverage: 4.5% :exclamation:

:new: org.pentaho.di.ui.trans.steps.aggregaterows.AggregateRowsDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.steps.rules.Rules

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.steps.rules.Rules.Column

Complexity Coverage: 50% :exclamation:
Instruction Coverage: 42.4% :exclamation:
Line Coverage: 46.4% :exclamation:
Method Coverage: 50% :exclamation:

Note: The list of offending coverage changes extends beyond the presented results and was truncated to prevent reaching the comment size limit.

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectory.java. Found 2017. Was expecting 2018

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'ui' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseController.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectory.java
  ui/src/main/resources/org/pentaho/di/ui/repository/repositoryexplorer/xul/explorer-layout.xul

Newly Broken Tests:
org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UIEERepositoryDirectoryTest.testSetName:
:red_circle: java.lang.NullPointerException
java.lang.NullPointerException
	at org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UIEERepositoryDirectoryTest.testSetName(UIEERepositoryDirectoryTest.java:172)

org.pentaho.di.ui.repository.repositoryexplorer.controllers.BrowseControllerTest.testInit:
:red_circle: org.pentaho.di.ui.repository.repositoryexplorer.ControllerInitializationException
org.pentaho.di.ui.repository.repositoryexplorer.ControllerInitializationException: java.lang.NullPointerException
	at org.pentaho.di.ui.repository.repositoryexplorer.controllers.BrowseControllerTest.testInit(BrowseControllerTest.java:178)
Caused by: java.lang.NullPointerException
	at org.pentaho.di.ui.repository.repositoryexplorer.controllers.BrowseControllerTest.testInit(BrowseControllerTest.java:178)

org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testGetRepositoryObjectsFilled:
:red_circle: java.lang.AssertionError
java.lang.AssertionError: expected:<1> but was:<2>
	at org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testGetRepositoryObjectsFilled(UIRepositoryDirectoryTest.java:61)

org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testGetRepositoryObjectsNulled:
:red_circle: java.lang.AssertionError
java.lang.AssertionError: expected:<1> but was:<2>
	at org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testGetRepositoryObjectsNulled(UIRepositoryDirectoryTest.java:86)

org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testRefresh:
:red_circle: org.mockito.exceptions.verification.WantedButNotInvoked
org.mockito.exceptions.verification.WantedButNotInvoked:

Wanted but not invoked:
repositoryExtended.loadRepositoryDirectoryTree(
    "/",
    "*.ktr|*.kjb",
    -1,
    true,
    true,
    true
);
-> at org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectoryTest.testRefresh(UIRepositoryDirectoryTest.java:109)

However, there were other interactions with this mock:
repositoryExtended.getJobAndTransformationObjects(
    0,
    false
);
-> at org.pentaho.di.ui.repository.repos

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes: +14.4% (click to expand)
:new: org.pentaho.di.trans.step.mqtt.MQTTConstants

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumer

Line Coverage: 78.6% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumerDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumerMeta

Branch Coverage: 50% :exclamation:
Complexity Coverage: 58.2% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MqttDialogOptionsLayout

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MqttDialogSecurityLayout

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducer

Branch Coverage: 72.2% :exclamation:
Complexity Coverage: 64.7% :exclamation:
Method Coverage: 75% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducerDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducerMeta

Branch Coverage: 50% :exclamation:
Complexity Coverage: 63.6% :exclamation:
Instruction Coverage: 75.4% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTStreamSource

Branch Coverage: 75% :exclamation:

:new: org.pentaho.di.trans.steps.aggregaterows.AggregateRows

Branch Coverage: 36.2% :exclamation:
Complexity Coverage: 30.3% :exclamation:
Instruction Coverage: 55.2% :exclamation:
Line Coverage: 60.5% :exclamation:

:new: org.pentaho.di.trans.steps.aggregaterows.AggregateRowsMeta

Branch Coverage: 0% :exclamation:
Complexity Coverage: 2.2% :exclamation:
Instruction Coverage: 10.4% :exclamation:
Line Coverage: 7.6% :exclamation:
Method Coverage: 4.5% :exclamation:

:new: org.pentaho.di.ui.trans.steps.aggregaterows.AggregateRowsDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.steps.rules.Rules

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.steps.rules.Rules.Column

Complexity Coverage: 50% :exclamation:
Instruction Coverage: 42.4% :exclamation:
Line Coverage: 46.4% :exclamation:
Method Coverage: 50% :exclamation:

Note: The list of offending coverage changes extends beyond the presented results and was truncated to prevent reaching the comment size limit.

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectory.java. Found 2017. Was expecting 2018

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'ui,plugins/pur/core' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui,plugins/pur/core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  plugins/pur/core/src/main/java/org/pentaho/di/repository/pur/LazyUnifiedRepositoryDirectory.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseController.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectory.java
  ui/src/main/resources/org/pentaho/di/ui/repository/repositoryexplorer/xul/explorer-layout.xul
  ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseControllerTest.java
  ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectoryTest.java

Newly Broken Tests:
org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UIEERepositoryDirectoryTest.testSetName:
:red_circle: java.lang.NullPointerException
java.lang.NullPointerException
	at org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UIEERepositoryDirectoryTest.testSetName(UIEERepositoryDirectoryTest.java:172)

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes: -1.2% (click to expand)
:new: org.pentaho.di.trans.step.mqtt.MQTTConstants

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumer

Line Coverage: 78.6% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumerDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumerMeta

Branch Coverage: 50% :exclamation:
Complexity Coverage: 58.2% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MqttDialogOptionsLayout

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MqttDialogSecurityLayout

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducer

Branch Coverage: 72.2% :exclamation:
Complexity Coverage: 64.7% :exclamation:
Method Coverage: 75% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducerDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducerMeta

Branch Coverage: 50% :exclamation:
Complexity Coverage: 63.6% :exclamation:
Instruction Coverage: 75.4% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTStreamSource

Branch Coverage: 75% :exclamation:

:new: org.pentaho.di.trans.steps.aggregaterows.AggregateRows

Branch Coverage: 36.2% :exclamation:
Complexity Coverage: 30.3% :exclamation:
Instruction Coverage: 55.2% :exclamation:
Line Coverage: 60.5% :exclamation:

:new: org.pentaho.di.trans.steps.aggregaterows.AggregateRowsMeta

Branch Coverage: 0% :exclamation:
Complexity Coverage: 2.2% :exclamation:
Instruction Coverage: 10.4% :exclamation:
Line Coverage: 7.6% :exclamation:
Method Coverage: 4.5% :exclamation:

:new: org.pentaho.di.ui.trans.steps.aggregaterows.AggregateRowsDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.steps.rules.Rules

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.steps.rules.Rules.Column

Complexity Coverage: 50% :exclamation:
Instruction Coverage: 42.4% :exclamation:
Line Coverage: 46.4% :exclamation:
Method Coverage: 50% :exclamation:

Note: The list of offending coverage changes extends beyond the presented results and was truncated to prevent reaching the comment size limit.

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseControllerTest.java. Found 2017. Was expecting 2018

:heavy_exclamation_mark: Copyright year is not the current year on ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectoryTest.java. Found 2017. Was expecting 2018

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'ui,plugins/pur/core' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui,plugins/pur/core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  plugins/pur/core/src/main/java/org/pentaho/di/repository/pur/LazyUnifiedRepositoryDirectory.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseController.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectory.java
  ui/src/main/resources/org/pentaho/di/ui/repository/repositoryexplorer/xul/explorer-layout.xul
  ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseControllerTest.java
  ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectoryTest.java

Newly Broken Tests:
org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UIEERepositoryDirectoryTest.testSetName:
:red_circle: java.lang.NullPointerException
java.lang.NullPointerException
	at org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UIEERepositoryDirectoryTest.testSetName(UIEERepositoryDirectoryTest.java:172)

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes: -1.2% (click to expand)
:new: org.pentaho.di.trans.step.mqtt.MQTTConstants

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumer

Line Coverage: 78.6% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumerDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTConsumerMeta

Branch Coverage: 50% :exclamation:
Complexity Coverage: 58.2% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MqttDialogOptionsLayout

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MqttDialogSecurityLayout

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducer

Branch Coverage: 72.2% :exclamation:
Complexity Coverage: 64.7% :exclamation:
Method Coverage: 75% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducerDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTProducerMeta

Branch Coverage: 50% :exclamation:
Complexity Coverage: 63.6% :exclamation:
Instruction Coverage: 75.4% :exclamation:

:new: org.pentaho.di.trans.step.mqtt.MQTTStreamSource

Branch Coverage: 75% :exclamation:

:new: org.pentaho.di.trans.steps.aggregaterows.AggregateRows

Branch Coverage: 36.2% :exclamation:
Complexity Coverage: 30.3% :exclamation:
Instruction Coverage: 55.2% :exclamation:
Line Coverage: 60.5% :exclamation:

:new: org.pentaho.di.trans.steps.aggregaterows.AggregateRowsMeta

Branch Coverage: 0% :exclamation:
Complexity Coverage: 2.2% :exclamation:
Instruction Coverage: 10.4% :exclamation:
Line Coverage: 7.6% :exclamation:
Method Coverage: 4.5% :exclamation:

:new: org.pentaho.di.ui.trans.steps.aggregaterows.AggregateRowsDialog

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.steps.rules.Rules

Coverage: 0% :exclamation:

:new: org.pentaho.di.trans.steps.rules.Rules.Column

Complexity Coverage: 50% :exclamation:
Instruction Coverage: 42.4% :exclamation:
Line Coverage: 46.4% :exclamation:
Method Coverage: 50% :exclamation:

Note: The list of offending coverage changes extends beyond the presented results and was truncated to prevent reaching the comment size limit.

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseControllerTest.java. Found 2017. Was expecting 2018

:heavy_exclamation_mark: Copyright year is not the current year on ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectoryTest.java. Found 2017. Was expecting 2018

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'ui,plugins/pur/core' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui,plugins/pur/core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  plugins/pur/core/src/main/java/org/pentaho/di/repository/pur/LazyUnifiedRepositoryDirectory.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseController.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectory.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryObject.java
  ui/src/main/resources/org/pentaho/di/ui/repository/repositoryexplorer/xul/explorer-layout.xul
  ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseControllerTest.java
  ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectoryTest.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.trans.steps.gpload.GPLoadMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.repository.pur.LazyUnifiedRepositoryDirectory

Instruction Change: -0.6% :small_red_triangle_down:
Line Change: -0.8% :small_red_triangle_down:

org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UISecurityRole

Branch Change: -1.8% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.5% :small_red_triangle_down:

org.pentaho.di.ui.repository.repositoryexplorer.controllers.BrowseController

Branch Change: -1% :small_red_triangle_down:
Complexity Change: -1.4% :small_red_triangle_down:
Instruction Change: -4.7% :small_red_triangle_down:
Line Change: -5% :small_red_triangle_down:
Method Change: -3.6% :small_red_triangle_down:

org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectory

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -2.7% :small_red_triangle_down:
Instruction Change: -6.6% :small_red_triangle_down:
Line Change: -6.5% :small_red_triangle_down:
Method Change: -6.5% :small_red_triangle_down:

org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryObject

Complexity Change: -1.2% :small_red_triangle_down:

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryObject.java. Found 2017. Was expecting 2018

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'ui,plugins/pur/core' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui,plugins/pur/core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  plugins/pur/core/src/main/java/org/pentaho/di/repository/pur/LazyUnifiedRepositoryDirectory.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseController.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectory.java
  ui/src/main/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryObject.java
  ui/src/main/resources/org/pentaho/di/ui/repository/repositoryexplorer/xul/explorer-layout.xul
  ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/controllers/BrowseControllerTest.java
  ui/src/test/java/org/pentaho/di/ui/repository/repositoryexplorer/model/UIRepositoryDirectoryTest.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.trans.steps.gpload.GPLoadMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.repository.pur.LazyUnifiedRepositoryDirectory

Instruction Change: -0.6% :small_red_triangle_down:
Line Change: -0.8% :small_red_triangle_down:

org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UISecurityRole

Branch Change: -1.8% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.5% :small_red_triangle_down:

org.pentaho.di.trans.steps.salesforceupsert.SalesforceUpsertMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.ui.repository.repositoryexplorer.controllers.BrowseController

Branch Change: -1% :small_red_triangle_down:
Complexity Change: -1.4% :small_red_triangle_down:
Instruction Change: -4.7% :small_red_triangle_down:
Line Change: -5% :small_red_triangle_down:
Method Change: -3.6% :small_red_triangle_down:

org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryDirectory

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -2.7% :small_red_triangle_down:
Instruction Change: -6.6% :small_red_triangle_down:
Line Change: -6.5% :small_red_triangle_down:
Method Change: -6.5% :small_red_triangle_down:

org.pentaho.di.ui.repository.repositoryexplorer.model.UIRepositoryObject

Complexity Change: -1.2% :small_red_triangle_down:

@ddiroma


[HUDI-5495] add some property to table config

Change Logs
add some property to table config
OperationField, hoodie.index.type,hoodie.bucket.index.num.buckets,hoodie.bucket.index.hash.field
Impact
NA
Risk level (write none, low medium or high below)
None
Documentation Update
None
Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

@hudi-bot run azure


Escaping Jail Error

I would have expected this to throw an error:
    #[test]
    fn test_escape_figment_jail() {
        Jail::expect_with(|jail| {
            let path = jail.directory();
            let escaped = jail.create_dir("../../escaped");
            assert!(escaped.is_err());
        });
    }

The dedot method is applied before the escape test.

This is working correctly.
Inside a jail, you can't go beyond the root of the jail. Thus, any number of ../../../ will be treated as /, and thus the relative path from the root of the jail to ../../../../foo is foo. This is the way paths work in general: if you cd .../../../../../../../../../../../../../../foo, you'll just end up in foo.


Adds command line option for divergence damping factor.

This makes the divergence damping coefficient consistent with other diffusive parameters
being used in the model.
modified:   examples/hybrid/cli_options.jl
modified:   src/utils/model_getters.jl

bors r+


[DOCFIX] Docfix in docs/cn/Configuring-Alluxio-with-GCS.md

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/17680/
Test PASSed.


Enable tabbing between items in Endpoint Aliases page

Is your feature request related to a problem? Please describe.
A user can tab between items in a single array element, but cannot tab to a different alias control.
Describe the solution you'd like
Tab should move left to right in a single array element and a tab after the last item in that cluster element should move to the next array element.
Shift+Tab should also work go backward through the items.

We might also want to consider if being able to tab onto the delete row button is helpful; @csjall and I ran into issues where we were unintentionally deleting rows immediately after creating them.


Cmd froze upon running

Nothing is happening upon running "py -3 download.py"

So I had to fix the REGEX to get it to  run at all. For whatever reason the current one in the project doesn't work.
On line 42 of download.py change findstr to be
findstr = r'\"assets\":\[.*?\]'

@mitjmcc  Sounds awesome. Maybe you can put a PR ? It seems like the codebase is not actively managed.


Support additional end-user types

Introduction
As of now, we expect a 11-digit pid claim to be present on all end-users endpoints in order to utilize Altinn Authorization.
This will need to be generalized in order to support other users, such as legacy enterprise users (virksomhetsbrukere) and the new system users; or put in more general terms, be able to map more claims from the authenticated principal to subject attributes in the XACML request, and offload the authorization decision more fully to Altinn Authorization, leaving us with just authenticating tokens (against trusted issuers) and checking scopes.
An implication of this could be that also "pure" Maskinporten-authenticated parties (ie. we only get a claim for a authenticated organization number) should be accepted on enduser endpoints, as the org. number alone could be mapped to a XACML subject claim and used against Altinn Authorization. However, this is not supported by the delegation model, and will require that organization numbers are added directly into the XACML policy, which is way of doing things we're not really supporting. This might also cause confusion with service owner-authenticated users. Therefore, we will be requiring some additional claims to the org.number in order to accept them as a "end user".
Implementation
We need to introduce the concept of "user types", which for now would be:

Persons (having a pid-claim)
Legacy enterprise users (having a urn:altinn:userid claim and urn:altinn:authenticationmethod set to "virksomhetsbruker"
System user
Service Owner (supplying a dialogporten.serviceprovider scope)
Person via Service Owner (service owner authenticated, but supplying user pid in request)

This will have impact of eg. the seen log implementation, where we assume the identifier to be a norwegian PID. Name resolution will also be different based on the user type.
This will also entail that we perform some sort of refactoring of the "User" services/externals in the application to better reflect what they're actually doing.
See https://github.com/digdir/dialogporten/tree/feature/support-legacy-enterprise-users for an initial implementation, as well as https://github.com/digdir/dialogporten/tree/feature/support-legacy-enterprise-users-refactor
### Tasks
- [x] Implement user type authorization middleware
- [x] Refactor name resolution for seen log
- [ ] Figure out how to get something human readbable for seen-log for [system users](https://docs.altinn.studio/authentication/systemauthentication/)
- [ ] Prepare documentation (if relevant - either update working document, or add a new file in `docs`)
- [ ] Add e2e-test (if relevant)

"Figure out how to get something human readbable for seen-log for system users"
@elsand , GetCurrentUserInformation just returns "System User" for system users atm.
Is it this name that we're talking about here?
            case UserIdType.SystemUser:
                // TODO: Implement when SystemUsers are introduced?
                name = "System User";
                break;

Is it this name that we're talking about here?
Yes. This name will probably be made available as a separate claim in the token, but that functionality is yet to be implemented in Altinn Autorisasjon/Maskinporten. We should just make a issue for it for now.


Implement integration tests for bigtable::Filter::* functions.

This PR introduces an integration test for bigtable::Filter, and it has some of the fixes for #84.
The PR does not have all the integration tests, but it was getting too large, in fact, it might be too large already.

Thanks for reviewing the gigantic PR.  I have rebased and addressed your comments.  PTAL.

Fixed the conflict by rebasing to master.


Share target directory with sub-crates

This gets us as close to workspaces as we can do without actually
building a workspace. That isn't possible as currently there is no
support for nested workspaces, and cargo is included into
rustc's workspace.
The benefit of this PR is a shared dependency cache.

r? @ehuss
(rust_highfive has picked a reviewer for you, use r? to override)

I'm not sure how it affects people who have a global target dir. Does this override their choice? IDK, if yes this probably shouldn't be merged.

It does override if there is a global setting in CARGO_HOME.  I'm not sure how common that is, though.
I also think this may not work terribly well, since each crate will have a separate lock file, it will quickly get out of sync, and end up not sharing any artifacts.

Oh right that's another issue... Well I guess it should be closed then.


Fix: SMS delivery failure sign in flow in homepage

Explanation of Change

Fixed Issues

$ https://github.com/Expensify/App/issues/52086
PROPOSAL:
Tests
Same as QA Steps

[x] Verify that no errors appear in the JS console

Offline tests
Same as QA Steps
QA Steps

Log in with an existing account.
On the login page with the magic code request, type Onyx.merge("account", {smsDeliveryFailureStatus: {hasSMSDeliveryFailure: true, message: "Please try again in 23 hours and 59 minutes"}}); in the console.
Verify that the smsDeliveryFailureMessage is displayed correctly.
Click the "Got it" button.
Verify that the user is navigated to the beginning of the sign-in flow.
Repeat steps 1-3.
Click the "Go Back" button.
Verify that the user is navigated to the beginning of the sign-in flow.
Repeat steps 1-3.
On the login page with the magic code request, type Onyx.merge("account", {smsDeliveryFailureStatus: {hasSMSDeliveryFailure: false}}); in the console.
Verify that the user was able to continue the sign-in flow.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/user-attachments/assets/ce9fd028-64de-4253-8e8f-9b67915d0365

Android: mWeb Chrome
https://github.com/user-attachments/assets/0ad3f43c-cc0f-49e7-b948-2d09cb5ac9ea

iOS: Native
https://github.com/user-attachments/assets/a2be4958-6c8b-4415-9053-2e1583fb01fe

iOS: mWeb Safari
https://github.com/user-attachments/assets/b750801d-1608-4da2-8378-5524f2a58bba

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/54ec645d-5cb7-4af0-9f27-d856cc8212bf

MacOS: Desktop
https://github.com/user-attachments/assets/ba2d509a-8086-4934-b5c6-a983b8a40f2a

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.


[FEATURE] [SSH Logs] Adapt for usage with systemd

Dashboard Improvement Suggestion Template
Dashboard Name: SSH Logs
Improvement Details
Description:
Starting with Debian 12, SSH logs are written to a systemd journal, and can be viewed with journalctl -u ssh. The log file in /var/log/auth.log does not exist anymore.
I already adapted the Promtail configuration from your tutorial (see below), but I don't get any results from the Dashboard queries.
Use Case: Allow monitoring the SSH logs of any system that uses systemd journal for ssh logs
Proposed Changes
Change Description:
Update the tutorial to show a Promtail configuration to read SSH logs from systemd journal:
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
- url: http://<loki-url>:3100/loki/api/v1/push

scrape_configs:
- job_name: systemd_journal_ssh
  journal:
    path: /var/log/journal
    matches: _SYSTEMD_UNIT=ssh.service
    labels:
      instance: my.instance.com
      env: prod
      job: ssh
  relabel_configs:
    - source_labels: ['__journal__systemd_unit']
      target_label: 'unit'

Reading a line like this from the journal:
Oct 29 14:49:47 proxmox sshd[549136]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
results in the following line in Loki:
2024-10-29 14:49:47.846 pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
So somehow the queries need to be changed, because they try to match |="sshd[", which is not contained in the resulting line. Or do I just need to change something in the Promtail config to still receive the full line in Loki? I am quite new to this.
Example of a current query:
sum by(instance) (count_over_time({$label_name=~"$label_value", job=~"$job", instance=~"$instance"} |="sshd[" |=": session opened for" | __error__="" [$__interval]))
Rationale
Why is this Improvement Important:
journalctl is the default for ssh logs in Debian starting with version 12
Checklist
Please ensure that you have completed the following tasks before submitting your improvement suggestion:

[x] Checked existing dashboards and features to confirm that the improvement is not already available.
[x] Reviewed any related documentation or resources to ensure your suggestion aligns with best practices.
[x] Considered the impact of your suggestion on the overall user experience.

Thank you for taking the time to suggest improvements to our Grafana dashboards! Your feedback is valuable in helping us enhance the usability and effectiveness of our monitoring and visualization tools.

The first concern I see is that you’re using Debian, while I have only tested and officially support RedHat-based systems at this time. If you decide to proceed with Debian, you'll need to fork the dashboard and adjust it for compatibility with your Debian environment.
Additionally, the dashboard is built to expect log file and not systemd directly. So for example for RedHat you can use /var/log/secure and it parses sshd specific log entries.
In your case, you can try to remove |="sshd[" from all panels.

Thanks for your reply! I did not see RedHat mentioned anywhere in the repository, so sorry if I assumed incorrectly that Debian is supported. I removed the sshd part from the queries, and for now it works for me. Feel free to close the issue if there are no plans to support systemd :)


I'd like to join this project's community

Your public repo
https://github.com/jason-entenmann/gov4git-identity-public.git
Your public branch
main

approve

 Follow up
On Wednesday, 17-Jan-24 21:30:41 UTC by Gov4Git dev
@jason-entenmann was added to the community.


Added tags to EventBridge (Events) Rule resource and fixed an error in CONTRIBUTING.md

Per https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-tagging.html, only two EventBridge resources support tags:  event buses and rules.   The Troposphere EventBus resource had a field for tags, but Rules was missing it, probably because the Cloudformation Resource Specification was missing it.  This is issue https://github.com/cloudtools/troposphere/issues/2151.
This PR adds a jsonpatch to plug Tags for the Events::Rules resource into the resource specification and adds Tags to the Rules class. Also, the example for running scripts/gen.py included the cloudformation spec file as an argument, which causes gen.py to treat it as a service name and build a corrupted file.  This patch removes the cloudformation spec file from the example.

Thanks!

Needed to revert this commit since it is not implemented yet and causes rollbacks.

Yeah, sorry.  I missed that it wasn't supported in CloudFormation.


feat: temporary resources no longer use BigQuery Sessions

This allows multiple queries to run in parallel.
Draft because this is blocked by:

Updating models to no longer use session, issue 308813632.
Updating read_pandas to no longer use session, issue 309108590.
Updating read_gbq_table to no longer use session, 309109254.

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[ ] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[ ] Ensure the tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

Fixes internal issue 303953103
🦕

The following tests failed:
FAILED tests/system/large/ml/test_ensemble.py::test_randomforestclassifier_default_params
FAILED tests/system/large/ml/test_ensemble.py::test_randomforestclassifier_multiple_params
FAILED tests/system/large/ml/test_ensemble.py::test_xgbregressor_dart_booster_multiple_params

I'll investigate this morning.

@GarrettWu Please take a look, as this modifies the bigframes.ml module to use anonymous dataset instead of session model.


added support for macos-aarch binaries

Versions prior to v0.8.24 would not work on macos with M1/2/3 cpu unless Rosetta was used. This change allows the use of native binaries up until v0.8.5.
The helper scripts were updated accordingly and the listing extended.

Thanks @tolbrino! I will give it a try locally asap!

Now included in the master!


⚠ Bofrost.be has degraded performance

In 1bf3467, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1632 ms

Resolved: Bofrost.be performance has improved in a3f5faf.


Fix #432 - Add the ModuleInitializer attribute also for .NET Frameworks

Fix #432 - Added ModuleInitializer attribute also for .NET Frameworks instead of considering only .NET Core below 5
When using the .NET Framework (x64) or (x86), the Platform.FrameworkVersion object is null
Therefore, the ModuleInitializer attribute is not added but we need it to avoid throwing an exception
This is why I added the condition "if Platform.IsFramework" in addition
Platform.IsFramework is only true for .NET versions and is false for .NET Core versions (and consequently also for .NET 5 and .NET 6 ;) )

Thanks for the fix!


⚠ Bofrost.be has degraded performance

In 26dde6c, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1884 ms

Resolved: Bofrost.be performance has improved in 862b690.


feat(dom): add ability to polyfill offsetParent access

This enables the ability to add a composedOffsetParent polyfill, which can also be used conditionally when perf problems arise.
Polyfill
function getWindow(node) {
  return node.ownerDocument?.defaultView || window;
}

function isShadowRoot(node) {
  return node instanceof getWindow(node).ShadowRoot;
}

/**
 * Polyfills the old offsetParent behavior from before the spec was changed:
 * https://github.com/w3c/csswg-drafts/issues/159
 */
function composedOffsetParent(element) {
  let {offsetParent} = element;
  let ancestor = element;
  let foundInsideSlot = false;

  while (ancestor && ancestor !== offsetParent) {
    const {assignedSlot} = ancestor;

    if (assignedSlot) {
      let newOffsetParent = assignedSlot.offsetParent;

      if (getComputedStyle(assignedSlot).display === 'contents') {
        const hadStyleAttribute = assignedSlot.hasAttribute('style');
        const oldDisplay = assignedSlot.style.display;
        assignedSlot.style.display = getComputedStyle(ancestor).display;

        newOffsetParent = assignedSlot.offsetParent;

        assignedSlot.style.display = oldDisplay;
        if (!hadStyleAttribute) {
          assignedSlot.removeAttribute('style');
        }
      }

      ancestor = assignedSlot;
      if (offsetParent !== newOffsetParent) {
        offsetParent = newOffsetParent;
        foundInsideSlot = true;
      }
    } else if (isShadowRoot(ancestor) && ancestor.host && foundInsideSlot) {
      break;
    }
    ancestor = ((isShadowRoot(ancestor) && ancestor.host) ||
      ancestor.parentNode);
  }

  return offsetParent;
}

Usage
computePosition(a, b, {
  platform: {
    ...platform,
    getOffsetParent: element => platform.getOffsetParent(element, composedOffsetParent)
  }
});

@atomiks I can't understand your polyfill.
I write another simple version, it works fine with shadow dom in my project.
I have performance issues with your polyfill, but so far this one doesn't
function composedOffsetParent(element: HTMLElement) {
  let ancestor: Node | null = element
  while (ancestor) {
    if (ancestor === document.documentElement || ancestor === document.body) {
      return null
    } else if (ancestor instanceof Element) {
      const style = getComputedStyle(ancestor)
      if (style.display === 'none' || style.position === 'fixed') {
        return null
      } else if (ancestor !== element && style.position !== 'static') {
        return ancestor
      }
    }

    ancestor = getParentNode(ancestor)
  }

  return null
}

function getParentNode(current: Node) {
  return current instanceof ShadowRoot ? current.host : (current as Element).assignedSlot || current.parentNode
}

I don't understand it either as I didn't really write it. I think that one may fail in some cases with display: contents; ancestors, but if it works for you then that's good. To handle iframes it needs to use the getWindow function I provided above. Consider publishing it as a package for others to use 🙏

@zengguirong @atomiks Unfortunately, I confirmed that the above polyfill doesn't cover all of our use cases (namely this one).
TL;DR: I published https://www.npmjs.com/package/composed-offset-position with ponyfills that can be passed into platform.getOffsetParent(element, composedOffsetParent)
On the bright side, I did spend some time today testing  offsetParentPolyfill (from https://bugs.chromium.org/p/chromium/issues/detail?id=1331803#c9 and also mentioned in https://github.com/shoelace-style/shoelace/issues/1135) and it's working great (thanks @josepharhar!). I know there were concerns about the polyfill patching HTMLElement's prototype, so I went ahead and converted them into ponyfills, which fit perfectly with the changes made in this PR. The ponyfills are published on NPM for further testing and feedback. I still need to add usage doc, but for now the test page is the closest thing.

Thanks @jcfranco I added this to the docs and edited the OP


add cmdline to cbfs

the cmdline was missed in cbfs, which lead to no console output in logs

LGTM


fetch-mock: No fallback response defined for GET to https://jsonmock.hackerrank.com/api/stocks/?date=1-January-2002

CodeSandbox: https://codesandbox.io/s/quizzical-carlos-k5i4en?file=/src/App.test.js
Stackoverflow: https://stackoverflow.com/questions/71455887/react-fetch-mock-no-fallback-response-defined-for-get
Not able to figure out the below error message. It fails on the three test cases written by hackerrank team so I am assuming they are supposed to be passed. At least they must have tested their test cases. I tested for different versions, 7.0.0, 7.3.1, 9.0.0-beta.2. It's still failing
Test Case: Search is made on by clicking on search button and no results found
fetch-mock: No fallback response defined for GET to https://jsonmock.hackerrank.com/api/stocks/?date=1-January-2002

  14 |   const fetchData = () => {
  15 |     const Url = 'https://jsonmock.hackerrank.com/api/stocks/?date=' + date;
> 16 |     fetch(Url)
     |     ^
  17 |       .then(res => res.json())
  18 |       .then((result) => {
  19 |         if (result.data[0]) {

  at Object.<anonymous>.FetchMock.executeRouter (node_modules/fetch-mock/src/lib/fetch-handler.js:106:9)
  at Object.fetch [as fetchHandler] (node_modules/fetch-mock/src/lib/fetch-handler.js:56:21)
  at fetchData (src/components/stock-data/index.js:16:5)
  at HTMLUnknownElement.callCallback (node_modules/react-dom/cjs/react-dom.development.js:188:14)
  at Object.invokeGuardedCallbackDev (node_modules/react-dom/cjs/react-dom.development.js:237:16)
  at invokeGuardedCallback (node_modules/react-dom/cjs/react-dom.development.js:292:31)
  at invokeGuardedCallbackAndCatchFirstError (node_modules/react-dom/cjs/react-dom.development.js:306:25)
  at executeDispatch (node_modules/react-dom/cjs/react-dom.development.js:389:3)
  at executeDispatchesInOrder (node_modules/react-dom/cjs/react-dom.development.js:414:5)
  at executeDispatchesAndRelease (node_modules/react-dom/cjs/react-dom.development.js:3278:5)
  at executeDispatchesAndReleaseTopLevel (node_modules/react-dom/cjs/react-dom.development.js:3287:10)
  at forEachAccumulated (node_modules/react-dom/cjs/react-dom.development.js:3259:8)
  at runEventsInBatch (node_modules/react-dom/cjs/react-dom.development.js:3304:3)
  at runExtractedPluginEventsInBatch (node_modules/react-dom/cjs/react-dom.development.js:3514:3)
  at handleTopLevel (node_modules/react-dom/cjs/react-dom.development.js:3558:5)
  at batchedEventUpdates$1 (node_modules/react-dom/cjs/react-dom.development.js:21871:12)
  at batchedEventUpdates (node_modules/react-dom/cjs/react-dom.development.js:795:12)
  at dispatchEventForLegacyPluginEventSystem (node_modules/react-dom/cjs/react-dom.development.js:3568:5)
  at attemptToDispatchEvent (node_modules/react-dom/cjs/react-dom.development.js:4267:5)
  at dispatchEvent (node_modules/react-dom/cjs/react-dom.development.js:4189:19)
  at unstable_runWithPriority (node_modules/scheduler/cjs/scheduler.development.js:653:12)
  at runWithPriority$1 (node_modules/react-dom/cjs/react-dom.development.js:11039:10)
  at discreteUpdates$1 (node_modules/react-dom/cjs/react-dom.development.js:21887:12)
  at discreteUpdates (node_modules/react-dom/cjs/react-dom.development.js:806:12)
  at dispatchDiscreteEvent (node_modules/react-dom/cjs/react-dom.development.js:4168:3)
  at node_modules/@testing-library/dom/dist/events.js:25:20
  at node_modules/@testing-library/react/dist/pure.js:65:16
  at batchedUpdates$1 (node_modules/react-dom/cjs/react-dom.development.js:21856:12)
  at act (node_modules/react-dom/cjs/react-dom-test-utils.development.js:929:14)
  at Object.eventWrapper (node_modules/@testing-library/react/dist/pure.js:64:28)
  at fireEvent (node_modules/@testing-library/dom/dist/events.js:16:35)
  at Function.fireEvent.<computed> [as click] (node_modules/@testing-library/dom/dist/events.js:124:36)
  at Function.click (node_modules/@testing-library/react/dist/fire-event.js:18:52)
  at Object.<anonymous> (src/App.test.js:32:13)

Closing due to inactivity


Migrate to new protobuf implementation

Significant changes:

Remove common types
Protobuf fields are private, so we use getters and setters in paging descriptor instead of field access
Repeated and map fields use different getters and setters

This PR should not be merged until changes in toolkit and google-cloud-php are also ready (see https://github.com/googleapis/toolkit/pull/1281)
@shinfan @garrettjonesgoogle If it would be useful, I can break this PR into multiple changes.

Codecov Report

Merging #66 into master will decrease coverage by 0.2%.
The diff coverage is 95.52%.

@@            Coverage Diff             @@
##           master      #66      +/-   ##
==========================================
- Coverage   90.54%   90.34%   -0.21%
==========================================
  Files          27       30       +3
  Lines        1661     1709      +48
==========================================
+ Hits         1504     1544      +40
- Misses        157      165       +8

Impacted Files
Coverage Δ

src/FixedSizeCollection.php
83.01% <0%> (ø)
:arrow_up:

src/PageStreamingDescriptor.php
100% <100%> (ø)
:arrow_up:

src/Testing/GeneratedTest.php
100% <100%> (ø)

src/Testing/MockBidiStreamingCall.php
82.92% <100%> (-0.8%)
:arrow_down:

src/Testing/MockUnaryCall.php
100% <100%> (ø)
:arrow_up:

src/OperationResponse.php
100% <100%> (ø)
:arrow_up:

src/Testing/MockStubTrait.php
90.38% <100%> (+1.02%)
:arrow_up:

src/ServerStream.php
100% <100%> (ø)
:arrow_up:

src/Testing/MockServerStreamingCall.php
87.5% <100%> (-2.5%)
:arrow_down:

src/PagedListResponse.php
97.43% <100%> (ø)
:arrow_up:

... and 11 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c642f11...a4cdbe7. Read the comment docs.

This PR just got a lot harder to review due to the new proto3 common types. We can discuss how to break this into sub-PRs for review.

Replaced by https://github.com/googleapis/gax-php/pull/76


Running TFlite on mobile device GPU fails  - Ops not supported

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
TensorFlow installed from (source or binary): source
TensorFlow version (or github SHA if from source):
nightly

.
.
INFO: Created TensorFlow Lite delegate for GPU.
ERROR: Following operations are not supported by GPU delegate:
DELEGATE TfLiteFlexDelegate: Operation is not supported.
EQUAL: Operation is not supported.
SPLIT: Operation is not supported.
WHILE: Operation is not supported.
62 operations will run on the GPU, and the remaining 907 operations will run on the CPU.
ERROR: TfLiteGpuDelegate Prepare: No shader implementation for transpose
ERROR: Node number 1001 (TfLiteGpuDelegate) failed to prepare.
ERROR: Regular TensorFlow ops are not supported by this interpreter. Make sure you apply/link the Flex delegate before inference.
ERROR: Node number 813 (FlexTensorScatterUpdate) failed to prepare.
.
.
unfortunately can't send the code.

@shlomi-amitai
Please, fill issue template.Please, let us know which TF version you are using?
Request you to share colab link or simple standalone code to reproduce the issue in our environment.It helps us in localizing the issue faster. Thanks!

I'm working on tf nightly build.
attached is my model with a python tester.
c++ execution code is more problematic for me to send.
modelWrapper.zip

DELEGATE TfLiteFlexDelegate: Operation is not supported.
Of course, GPU cannot handle the flex delegate.  I'm not even sure why this is fed into the GPU delegate's prepare.  @srjoglekar246

EQUAL: Operation is not supported.
I think there's some plan to bring this in.  No ETAs though.

SPLIT: Operation is not supported.
This is not difficult to implement, but not prioritized because there was no use case.  Can this be rewritten with STRIDED_SLICE?  @renjie-liu Is this applicable for tac?

WHILE: Operation is not supported.
Control flows are not available on the GPU delegate.  This is gonna be quite difficult, and probably can't be easily supported.  It would have to fall back to the CPU when control flow comes into play.

ERROR: Regular TensorFlow ops are not supported by this interpreter. Make sure you apply/link the Flex delegate before inference.
ERROR: Node number 813 (FlexTensorScatterUpdate) failed to prepare

Using Select TF operators (aka Flex) requires some additional changes to your BUILD, to pull in TF dependencies. See here.

ERROR: TfLiteGpuDelegate Prepare: No shader implementation for transpose

@impjdi Any idea why this would occur?
@shlomi-amitai In general, if performance is important, see if you can change your model authoring logic (in TensorFlow) to have ops that TFLite supports. Looks like the only op that requires Flex here is scatter and update.

Yes, split can be unrolled into slice op.

Thank you guys for your help.
@impjdi, regarding the split operation.
I'm converting a model from pytorch so these split operations are automatically added when generating the protobuffer (.pb)  from .onnx. I have no way, I assume, to control these additions. if it helps, I can send you the .onnx model.

Basically, all I care now is to make this pass and run (even partly) on the device's gpu.
I would like that parts of the NN that can run on GPU would do that. but currently the run failes with the above errors.
I'm compiling libtesnorflowlite.so this way:

in tensorflow/lite/BUILD -> under deps I add a flag  "//tensorflow/lite/delegates/flex:delegate"
bazel build -c opt --local_ram_resources 2048 --local_cpu_resources 1 --jobs 1 --config=android_arm64 --config=monolithic tensorflow/lite:libtensorflowlite.so
for GPU: bazel build -c opt --local_ram_resources 2048 --local_cpu_resources 1 --jobs 1 --config=android_arm64 --config=monolithic //tensorflow/lite/delegates/gpu:libtensorflowlite_gpu_gl.so

in tensorflow/lite/BUILD -> under deps I add a flag "//tensorflow/lite/delegates/flex:delegate"

Does this remove the error "Make sure you apply/link the Flex delegate before inference."? Not sure if this matters, but I usually link the delegate to my client app (that is the BUILD rule of my binary that uses TFLite), rather than TFLite itself.
To debug further, can you check if the Flex error vanish and you can run the model successfully without the GPU? That would atleast confirm if the Flex part of this is running as intended, We can then debug the GPU part further.

I use this flag also with libtensorflowlite.so  and there it runs smoothly on CPU

I see. The GPU delegate .so BUILDs from tensorflow/lite/delegates/gpu/BUILD, so you will have  to add the Flex rule there :-). Also use the latest TF nightly for this, since we only recently added support for Flex w/ GPU

I compiled #3 with the flex rule and I get libtensorflowlite_gpu_gl.so of size 4GB (50MB without the flag).. I can't even test the solution since I don't have this amount of space free in my device.

to be on the same page here, I added the flex rule in tensorflow/lite/delegates/gpu/BUILD under libtensorflowlite_gpu_gl.so deps list.

You can choose only the relevant ops to be added to the binary, since the current solution you implemented adds all supported TF ops to the binary. See this. Adding @abattery who has more context on this.

Hi @shlomi-amitai
You can create your selective build-enabled flex build target in the bazel as the following snippet:
tlite_flex_cc_library(
  name = "my_flex_delegate",
  models = ["model.tflite"],
)

The above special build target will trim the unused TF operators when linking. You can replace the //tensorflow/lite/delegates/flex:delegate with the above my_flex_delegate.

Thanks for the support.
I added the above code to the BUILD file, replaced "//tensorflow/lite/delegates/flex:delegate" with  "my_flex_delegate" and copied my model.tflite to the BUILD directory.
the build ended with a size of 1.12GB, which is better but yet very big.
I will try and change the original model (in pytorch) to somehow reduce operator types but my questions are as follows:

Did my actions followed your instructions?
Is there something more that can be done build wise to reduce the size of the SO?

Instead of adding the flex delegate dependency to the build targets in the tensorflow/lite/BUILD file, could you follow the document to generate the tensorflow-lite-select-tf-ops.aar based on your model?

Thanks.
I have tried this with nightly version of tensorflow and now getting this error during compilation:
ERROR: /tensorflow_src/WORKSPACE:53:1: //external:android/sdk depends on @androidsdk//:sdk in repository @androidsdk which failed to fetch. no such package '@androidsdk//': Bazel does not recognize Android build tools version debian: Invalid revision: debian
I will try to debug it.

"Selective Build for C API and iOS version is not supported currently."
is this still valid?
I'm working with the C API.

@thaink could you answer the question at this thread?

"Selective Build for C API and iOS version is not supported currently."
is this still valid?
I'm working with the C API.

The selective build for C and iOS is not yet released.
For the build error when building with docker, What OS version are you using? did you enter "y" when the android license showed up?


store graph ports and start/end node information in graph

The BaseGraph.flattenGraph static method now returns the BaseGraph.getGraphPorts results so that the graph can store the information of graph input/output port names, as well as the start node ids and end node ids.
Those data can be access through the following variables:
class BaseGraph {
  ...
  // input port fields of the graph
  readonly graphInputs: Record<string, DataType | Readonly<DataType[]>>;

  // output port fields of the graph
  readonly graphOutputs: Record<string, DataType | Readonly<DataType[]>>;

  // a lookup table with the key of the input port name and the value
  // of the corresponding node id and actual input port name in the node
  readonly graphInputNameMap: Record<string, { nodeId: RecordId; name: string }>;

  // a lookup table with the key of the output port name and the value
  // of the corresponding node id and actual output port name in the node
  readonly graphOutputNameMap: Record<string, { nodeId: RecordId; name: string }>;
  ...
}

just to confirm that "graphInputs" are equivalent to "start nodes"?

just to confirm that "graphInputs" are equivalent to "start nodes"?


[Authentication] Add Authentication on the Backend

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Related issues

...

This is completed


Return object from transform, add map property

At @ecosia we're using this plugin for a project, and noticed that when we build with Vite and enable source maps, we get this error for every SVG import:
(unplugin-svg-vue-component plugin) Sourcemap is likely to be incorrect: a plugin (unplugin-svg-vue-component) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help

It looks like most similar rollup plugins return an empty source map (which makes sense because we're creating a new bit of code essentially from nothing, rather than transforming an existing piece of code).
I'm hoping returning an empty source map explicitly will suppress this warning.
EDIT: and thank you for making this plugin! It was the only one that fit our specific use case so it's a massive help 🙏

Thanks, and already posted

thank you @jaw52!


WIP: Change scan server ref UUID

After performing scale testing we found that scan servers encounter write contention if the scan server refs start with the file path.
Found that moving the UUID to the beginning of the reference removes the contention issue.
Creating this as a WIP since this needs additional tests and validation of the upgrade code to ensure that the entire sserv range is removed on upgrade.
I'm thinking about adding a issue ticket for a scan server "delete" admin command that would wipe the range.
That can be performed today with a deletemany -f shell command, but incurs risk of mistyping the range.

I originally pointed this change at 2.1. but I'm not sure how we want to treat this since going back to 2.1.2 vs 2.1.3 would cause the manager to die on a malformed scan server ref.
I'm open to suggestions on how to best proceed with this change.

oldRef
~sservfile:/data/workspace/accumulo/test/target/mini-tests/
newRef
~sserv01074c23-7c56-4cc0-8fc5-8b684c580e60

I'm open to suggestions on how to best proceed with this change.

We could attemot the following :

Create a new prefix for the new data format, maybe ~scanr
In 2.1.3 servers would start writing the new format under the new prefix
Push all of the logic for encoding/decoding to/from key/value into ScanServerRefTabletFile
Make ScanServerRefTabletFile internally track the prefix it was decoded from and it can use that to create mutations
When scanning to gather ScanServerRefTabletFile, scan both prefixes

Pushing all of the encode/decode into ScanServerRefTabletFile seens like a nice general improvement on its own because it would bring that logic all to a single place in the code.  Might look something like the following.  Then except for having to scan both prefixes, most of the code dealing w/ ScanServerRefTabletFile would hopefully be oblivious to how the data is represented.
public class ScanServerRefTabletFile extends TabletFile {

  private String prefix; // either old prefix of ~sserv or new one of ~scanr
  private Text uuid;
  private Text serverAddress;

  public ScanServerRefTabletFile(String file, String serverAddress, UUID serverLockUUID) {
    super(new Path(URI.create(file)));
    // for new data always use the new prefix
    prefix = "~scanr";
    uuid = new Text(serverLockUUID.toString());
    this.serverAddress  = new Text(serverAddress);
  }

  private boolean isOldPrefix(Key k){
    return k.getRow().toString().startsWith("~sserv");
  }

  private static String extractFile(Key k) {
    // TODO extract file from key depending on prefix
  }

  // create a scan server ref from a mutatiopn
  public ScanServerRefTabletFile(Key k, Value v) {
    super(new Path(URI.create(extractFile(k))));
    // TODO use prefix to determine how to extract uuid and serverAddress from key/value
  }

  public void put(Mutation m) {
    // TODO use prefix determine how to put uuid, server, and file into the mutation
  }

  public void putDelete(Mutation m) {
    // TODO use prefix determine how to put delete for uuid, server, and file into the mutation
  }
}

I'm open to suggestions on how to best proceed with this change.

We could attempt the following :

Create a new prefix for the new data format, maybe ~scanr
In 2.1.3 servers would start writing the new format under the new prefix
Push all of the logic for encoding/decoding to/from key/value into ScanServerRefTabletFile
Make ScanServerRefTabletFile internally track the prefix it was decoded from and it can use that to create mutations
When scanning to gather ScanServerRefTabletFile, scan both prefixes

Pushing all of the encode/decode into ScanServerRefTabletFile seens like a nice general improvement on its own because it would bring that logic all to a single place in the code. Might look something like the following. Then except for having to scan both prefixes, most of the code dealing w/ ScanServerRefTabletFile would hopefully be oblivious to how the data is represented.
public class ScanServerRefTabletFile extends TabletFile {

  private String prefix; // either old prefix of ~sserv or new one of ~scanr
  private Text uuid;
  private Text serverAddress;

  public ScanServerRefTabletFile(String file, String serverAddress, UUID serverLockUUID) {
    super(new Path(URI.create(file)));
    // for new data always use the new prefix
    prefix = "~scanr";
    uuid = new Text(serverLockUUID.toString());
    this.serverAddress  = new Text(serverAddress);
  }

  private boolean isOldPrefix(Key k){
    return k.getRow().toString().startsWith("~sserv");
  }

  private static String extractFile(Key k) {
    // TODO extract file from key depending on prefix
  }

  public ScanServerRefTabletFile(Key k, Value v) {
    super(new Path(URI.create(extractFile(k))));
    // TODO use prefix to determine how to extract uuid and serverAddress from key/value
  }

  public void put(Mutation m) {
    // TODO use prefix determine how to put uuid, server, and file into the mutation
  }

  public void putDelete(Mutation m) {
    // TODO use prefix determine how to put delete for uuid, server, and file into the mutation
  }
}

That makes a lot of sense and is much cleaner than dealing with the change in ample.
The existing code doesn't matter since the range is different and on the switch to 3.x we just remove the old range.

Implemented @keith-turner's suggestions in #4682.
Still need to figure out exactly what should be done in terms of the upgrade code.

I'm closing this draft as #4682 seems to be a better way forward.


As specified, type inference infers no constraint for Null <: Future

The local inference informal specification (https://github.com/dart-lang/sdk/pull/29371) says:

P is a subtype match for FutureOr<Q> with respect to L under constraints
C:

If P is a subtype match for Future<Q> with respect to L under
constraints C.
Or P is not a subtype match for Future<Q> with respect to L under
constraints C

And P is a subtype match for Q with respect to L under constraints
C

The analyzer behavior is slightly different in the case where P is a subtype match for both Future<Q> and Q.  (This happens, for instance, if P is Null).  In that case, if the attempt to match P against Future<Q> generates zero constraints, but the attempt to match P against Q generates constraints, then the constraints from matching P against Q are propagated.
This has a user visible effect in the analyzer.  Consider the code:
void test(Future<int> f) async {
  var t = f.then((int x) {});
  (await t).foo();
}

The analyzer attempts to infer the type argument for then by matching Null <: Future<T>.  This causes the type constraint Null <: T to be generated, therefore t has type Future<Null>, and (await t).foo() produces an error.  If I change the analyzer to follow the informal specification, it infers a type of Future<dynamic> for t, and no error is issued.  Issuing an error seems like a better behavior here.
(Note that the common front end's behavior is different still: it infers a type of dynamic for t, due to #33044.)
@leafpetersen @jmesserly what do you think?

I like this idea. Analyzer behavior seems useful here (catches the bug on the next line).


BNT-5: ICRC-7 NFT Implementation (Rust)

Overview
Status: Open
Project Type: Cooperative - Multiple workers can submit work, and the bounty is shared
Time Commitment: Weeks
Experience Level: Intermediate
Size: USD 7'000 in ICP (at time of distribution)
Description
As part of the ICRC process, we aim to provide production-level implementation code to speed up adoption. This bounty concerns the ICRC-7 NFT standard which is being finalized in the working group.
The applicant is expected to have understood the current draft of ICRC-7 as well as the intentions of the working group and the design trade-offs made, implement according to the specification, and report back to the working group on a bi-weekly basis about any findings during implementation and suggestions on how the standard could be improved.
Familiarity with the fungible token standards ICRC-1, ICRC-2, and ICRC-3 is a plus.
Use Cases
NFTs on the IC.
Acceptance Criteria

The implementation shall fully implement the ICRC-7 draft proposal.
The code shall be of production quality, have good documentation and reasonable test coverage.
The code shall be open sourced with an MIT license.
The code will be considered 80% complete when the above criteria are met, and 100% complete when it passes the security audit with all problems fixed (the applicant does not bear the cost of the security audit).

How to apply?
Include links to previous relevant work.
Include a brief overview of how you will complete the task.
Post your application text in this thread.
References
[1] ICRC-7 Github. https://github.com/dfinity/ICRC/tree/main/ICRCs/ICRC-7

is the working group planning on providing a motoko implementation? if not, could we create a bounty for this as well? currently > 90% of the NFT projects on the IC use motoko canisters

@letmejustputthishere The rationale was to start with one implementation to get some feedback from an implementation. But we could start off with a Motoko implementation as well.

I personally think a Motoko implementation would make more sense for the reasons stated in my previous comment

Assigned to @holykol

I'd be more than happy to contribute as well, on the RUST side. Who do I reach out to for this?

It looks like you're referencing a specific GitHub issue or discussion related to the dfinity/grant-rfps repository. Specifically, issue #29, which is labeled as "BNT-5: 1CRC-7 NFT Implementation."
Below I will provide an overview of what Dfinity, RFP, and CRC-7 NFT Implementation refer to, along with some guidance on how to get involved or contribute.
Overview
DFINITY
DFINITY is an organization behind the development of the Internet Computer, a decentralized computing platform. It aims to enable the creation of secure, scalable, and efficient decentralized applications (dApps).
RFP (Request For Proposals)
In the context of grant programs like those from DFINITY, an RFP is a formal document that invites developers and researchers to submit proposals to complete specific projects or research in exchange for funding.
CRC-7 NFT Implementation
The CRC-7 standard refers to a specification for Non-Fungible Tokens (NFTs) on the Internet Computer. NFTs are unique digital assets, and the 1CRC-7 standard is likely a protocol for creating and managing these assets within the DFINITY ecosystem.
GitHub Issue #29: BNT-5: 1CRC-7 NFT Implementation
Given that issue #29 is open, you might be looking for ways to contribute, understand the scope, or need some guidance on implementing the CRC-7 NFT standard.
Steps to Get Involved or Contribute

Read the Issue Description:
Go to the GitHub issue at issue #29 and read the description and any comments. This will provide you with the specifics of the RFP and what is being requested.

Understand the Requirements:
Thoroughly understand the requirements for the CRC-7 NFT implementation. Look for any linked specifications or documentation in the issue description.

Ask Questions:
If there are any ambiguities or you need further clarification, add a comment to the issue to ask questions. The maintainers or other contributors can provide guidance.

Research and Plan:

Technical Specifications: If not already provided, you may need to look for the spec for CRC-7 NFTs or similar standards.
Relevant Projects: Check out existing NFT implementations on the Internet Computer or other platforms to get a sense of best practices.

Implementation:
Start implementing the CRC-7 NFT standard according to your understanding and the requirements listed in the issue.

Environment Setup: Make sure to set up your development environment with the required tools and libraries.
Code: Develop the code to fulfill the RFP. This might involve smart contract development, user interface design, and integration with other parts of the Internet Computer.
Testing: Thoroughly test your implementation to ensure it meets the defined standard and works as expected.

Create a Pull Request:
Once you have completed the implementation, follow the repository's contribution guidelines to create a pull request. Make sure your PR includes:

A comprehensive description of the changes.
Any relevant documentation or links to external resources.
Test cases demonstrating the functionality.

Engage with Reviewers:
Actively engage with reviewers who will provide feedback on your implementation. Be prepared to make revisions based on their comments.

Example Resources

Dfinity Documentation: Check the DFINITY Developer Docs for guidance on developing on the Internet Computer.
GitHub Repository: Explore the DFINITY GitHub repositories for existing projects and standards.

By following these steps, you can effectively contribute to the BNT-5: 1CRC-7 NFT Implementation in the dfinity/grant-rfps repository. If you need specific help with the CRC-7 NFT standard or any other aspect, please provide more details!


Appender thread: Failed to log to appender: nil (passenger + rails_semantic_logger)

Appender thread: Failed to log to appender: nil -- Exception: NoMethodError: undefined method `log' for nil:NilClass
[167:SemanticLogger::AppenderThread] SemanticLogger -- Appender thread: Failed to flush appender: nil -- Exception: NoMethodError: undefined method `name' for nil:NilClass

When using Passenger, additional configuration is required: https://rocketjob.github.io/semantic_logger/forking.html

@reidmorrison I am using rails_semantic_logger, as I understand the gem take care of Passenger compatibility

If you were able to get Passenger working please post the details here so that anyone else using Passenger can get the fix.

@reidmorrison the only way to make it work is to have only one appender

Ah, ok. So it does work for the file appender.
Not all appenders implemented #reopen. You could try implementing #reopen for whatever other appender you are trying to use.

I am trying to use stdour appender, to run in docker

We have made changes to Rails Semantic Logger to better support the console logging option. Can you try the latest version.
Also turn off Rails Server console logging to avoid issues. For example with Puma you can use the --quiet option, not sure what the same option is under passenger. Then the logging can be properly controlled via the appender options in Rails Semantic Logger.

Hmm, what is the best solution for this issue? I use rails_semantic_logger gem and gelf gem for Graylog. But I also meet this issue. "Failed to log to appender: Exception: NoMethodError: undefined method `message' for nil:NilClass".


Join *_OPTS variables after *_OPTS_ARRAY variables

Ref: https://github.com/rbenv/ruby-build/pull/1368#issuecomment-824624767
This for instance allows RUBY_CONFIGURE_OPTS to override
what's set by the definition.
For instance enable_shared can be disabled with RUBY_CONFIGURE_OPTS='--disable-shared'
cc @eregon
NB: I tried to write a test for it, but I'm getting failures without much info to debug:
 ✗ ordering
   (from function `unstub' in file test/test_helper.bash, line 62,
    in test file test/build.bats, line 265)
     `unstub make' failed

Pointers on how best to do this are welcome.

I manually tested this with:
$ RUBY_CONFIGURE_OPTS=" --disable-shared " bin/ruby-build 3.0.0 /tmp/rubies/3.0.0
$ /tmp/rubies/3.0.0/bin/ruby -r rbconfig -e 'p RbConfig::CONFIG["ENABLE_SHARED"]'
"no"
$ /tmp/rubies/3.0.0/bin/ruby -r rbconfig -e 'p RbConfig::CONFIG["configure_args"]'
" '--prefix=/tmp/rubies/3.0.0' '--with-openssl-dir=/tmp/rubies/3.0.0/openssl' '--enable-shared' '--with-readline-dir=/usr/local/opt/readline' '--disable-shared' 'CC=clang' 'CFLAGS= -DHAVE_UNISTD_H ' 'LDFLAGS=-L/tmp/rubies/3.0.0/lib -L/usr/local/opt/openssl/lib' 'CPPFLAGS=-I/tmp/rubies/3.0.0/include -I/usr/local/opt/openssl/include'"

Is it the case that *_OPTS_ARRAY is only modified by package_option, and that's only called by some functions in ruby-build with values which are not controlled by the user (either hardcoded or from some system command), and is therefore never influenced by user-provided values?
As far as I could see, it seems the case, but I'm not super familiar with that logic.
If that holds then I guess it might be OK to change that order as in this PR. If not, it could cause some incompatibility.
Even if it holds, I guess it might cause some incompatibility as flags are passed in a different order, but OTOH it seems best that user-provided flags can override the defaults of ruby-build :+1:

... '--enable-shared' '--with-readline-dir=/usr/local/opt/readline' '--disable-shared' ...

That feels a bit suboptimal, maybe build_package_enable_shared could check if --disable-shared was passed and then not add --enable-shared at all?
It would look a bit cleaner and if anything ever uses something like RbConfig::CONFIG["configure_args"].include?("--enable-shared") (a bad idea, there is RbConfig::CONFIG["ENABLE_SHARED"] for that) it would not break (or if the configure script does some changes on seeing --enable-shared that it doesn't under with --disable-shared, etc).
Might be a bit magic, but I think it would be a good trade-off in this case.

is therefore never influenced by user-provided values?

As far as I can tell yes, but I might have missed something?

That feels a bit suboptimal, maybe build_package_enable_shared could check if --disable-shared was passed and then not add --enable-shared at all?

I thought about that, but I thought it would be cleaner to have a more general fix rather than to focus on --enable-shared specifically.
But I'm open to implement that alternative if you think it's better.

@hsbt @mislav It would be great if one of you can review too.
This looks fine to me, as it enables the user to override ruby-build defaults, which seems useful/expected in general (CLI arguments or in this case user-provided env vars typically override defaults in a script).
I think avoiding to add --enable-shared if --disable-shared is in RUBY_CONFIGURE_OPTS would be a bit cleaner for the result.
@casperisfine

I thought about that, but I thought it would be cleaner to have a more general fix rather than to focus on --enable-shared specifically.

I think both would be best, what you did here, and removing the extra --enable-shared (keeping the --disable-shared from RUBY_CONFIGURE_OPTS).

NB: I tried to write a test for it, but I'm getting failures without much info to debug:

Could you show the partial test you wrote/push it to a branch? It'd be nice to test this change to avoid regressions.

Of course:
Here's one of the version https://github.com/casperisfine/ruby-build/commit/2f5ae705b844d37c3f8f17a3c60be00c81c719e0
I know it can't work because --disable-shared was introduced much later than 2.0, but if I try to make a inline definition with say 2.5.x, it fail to download the archive...

I think avoiding to add --enable-shared if --disable-shared is in RUBY_CONFIGURE_OPTS would be a bit cleaner for the result.

I added a commit that does just that.

I think this changeset is risky, since it changes the order of build flags passed in. This might affect someone's builds in ways that we did not predict.
But now that it's released, let's wait to see whether we get any complaints!