better file management and branding

when installing Helpy, there is no easy way to change favicon and profile images. or there is a way but I haven't found it.
also on heroku, there is no easy way to manage uploaded files. I think helpy needs S3 integration. The process of adding images in contents could be better too. as it is now, I can't add any images to Helpy

The favicon can be changed to whatever you want it to in /admin/settings under 'design'
Just ensure that the file you type in in the favicon field corresponds to a file in the APP_ROOT/assets/images

You can also use a remote hosted image by providing a full URL.  To enable images for your account you need to add an API key for Cloudinary.  They have a free tier that should suffice for smaller accounts.  I want do to some kind of S3 integration soon, it is definitely on the backlog.  You can see it here: https://trello.com/b/NuiWsdmK/helpy

Cool. S3 integration would be awesome.

@CGA1123 I know how to do it but UX wise, it's not so good. If you give user ability to upload the logo right in admin, that would make things simpler.


Loss of unsaved Untitled files from most recent update

VSCode Version: 1.32.0, 1.32.1
OS Version: macOS Mojave 10.14.3

Steps to Reproduce:

Open a new, unsaved ("Untitled-n.txt") tab, and type "test text" into it. Don't save.
In the taskbar click "Code" -> "Restart to Update"
No prompts about saving files, Code closes and reopens
The "Untitled-n.txt" tab is open, but the contents are empty

I just lost a lot of work by updating Code. I didn't think anything of it because in Sublime (which I recently switched from) I was in the habit of having some scratch buffers open, not saved to any particular file. If you update Sublime it will restore all open buffers, including unsaved and new ones, and the contents of them.
It seems Code mostly supports this workflow: I just tried it by quitting and restarting Code (as opposed to "Restart to Update") and it restored the buffers as expected. It seems to be related to the update specifically.

Yes, duplicate of https://github.com/Microsoft/vscode/issues/69972 . Sorry. Closing.


openamp sample integration/app

Example of using open-amp.
This example docs need some cleaning up, but this is based on #7415 and #7161

@dbkinder can you review this now from a doc perspective.

This is the first step towards a fuller solution for #3065.  We expect in the future to update the openamp implementation both for improved integration with Zephyr, as well as reduce code footprint from an improved openamp library.

Codecov Report

Merging #7416 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #7416      +/-   ##
==========================================
+ Coverage   55.31%   55.32%   +<.01%
==========================================
  Files         470      470
  Lines       51913    51913
  Branches     9923     9923
==========================================
+ Hits        28718    28719       +1
+ Misses      19270    19269       -1
  Partials     3925     3925

Impacted Files
Coverage Δ

lib/posix/pthread.c
69.84% <0%> (+0.5%)
:arrow_up:

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 ad6b890...5ab35bd. Read the comment docs.

Fixed the checkpatch error and all of the warnings except for:
-:405: WARNING:PREFER_KERNEL_TYPES: Prefer kernel type 'u32_t' over 'uint32_t'
#405: FILE: samples/subsys/ipc/openamp/platform/resource_table.h:16:
+	uint32_t ver;

-:406: WARNING:PREFER_KERNEL_TYPES: Prefer kernel type 'u32_t' over 'uint32_t'
#406: FILE: samples/subsys/ipc/openamp/platform/resource_table.h:17:
+	uint32_t num;

-:407: WARNING:PREFER_KERNEL_TYPES: Prefer kernel type 'u32_t' over 'uint32_t'
#407: FILE: samples/subsys/ipc/openamp/platform/resource_table.h:18:
+	uint32_t reserved[2];

-:408: WARNING:PREFER_KERNEL_TYPES: Prefer kernel type 'u32_t' over 'uint32_t'
#408: FILE: samples/subsys/ipc/openamp/platform/resource_table.h:19:
+	uint32_t offset[2];


[sival/edn] Add EDN tests to bazel testpoint rule

This commit just adds the existing EDN sival tests to the respective bazel rules in the chip_edn_testplan.

@johngt , @engdoreis , @moidx this PR adds the bazel rules for the EDN tests which have been written by Hakim quite some time ago. After merging this, I believe this should also be picked up by the automated tracking but it's probably worth to check this really happens.

Merging as this PR does not change RTL.


Various small tweaks and fixes

Currently leaving this WIP until I have a few of these.

@pascalw Let's merge this as other "small tweaks" are addressed in bigger PRs


HDFS-17300.  [SBN READ] Observer should throw ObserverRetryOnActiveException if stateid is always delayed with Active Namenode for a configured time

…ateid is always delayed with Active Namenode for a period of time

Description of PR
Now when Observer NN is used,  if the stateid is delayed , the rpcServer will be requeued into callqueue. If EditLogTailer is broken or something else wrong , the call will be requeued again and again.
So Observer should throw ObserverRetryOnActiveException if stateid is always delayed with Active Namenode for a configured time.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
7m 42s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
13m 30s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
19m 39s

trunk passed

+1 :green_heart:
compile
8m 17s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
7m 29s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
2m  2s

trunk passed

+1 :green_heart:
mvnsite
1m 42s

trunk passed

+1 :green_heart:
javadoc
1m 25s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 44s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m  6s

trunk passed

+1 :green_heart:
shadedclient
20m 45s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m  4s

the patch passed

+1 :green_heart:
compile
8m  0s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
8m  0s

the patch passed

+1 :green_heart:
compile
7m 29s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
7m 29s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
1m 57s
/results-checkstyle-root.txt
root: The patch generated 3 new + 267 unchanged - 0 fixed = 270 total (was 267)

+1 :green_heart:
mvnsite
1m 39s

the patch passed

+1 :green_heart:
javadoc
1m 16s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 42s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 18s

the patch passed

+1 :green_heart:
shadedclient
20m 36s

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

_ Other Tests _

+1 :green_heart:
unit
16m 21s

hadoop-common in the patch passed.

-1 :x:
unit
199m 50s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 42s

The patch does not generate ASF License warnings.

353m 14s

Reason
Tests

Failed junit tests
hadoop.hdfs.TestDecommissionWithStripedBackoffMonitor

hadoop.hdfs.server.datanode.TestDirectoryScanner

hadoop.hdfs.TestDFSStripedOutputStream

Subsystem
Report/Notes

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

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

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

uname
Linux 7a30dafd7c3b 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 982fa777f958e514a2e66faf915c53ec9ac86a12

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

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

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

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 20s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m  1s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
19m  9s

trunk passed

+1 :green_heart:
compile
8m 19s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
7m 32s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
2m  1s

trunk passed

+1 :green_heart:
mvnsite
1m 43s

trunk passed

+1 :green_heart:
javadoc
1m 21s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 45s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 11s

trunk passed

+1 :green_heart:
shadedclient
20m 52s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m  8s

the patch passed

+1 :green_heart:
compile
7m 58s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
7m 58s

the patch passed

+1 :green_heart:
compile
7m 25s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
7m 25s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
1m 54s
/results-checkstyle-root.txt
root: The patch generated 3 new + 267 unchanged - 0 fixed = 270 total (was 267)

+1 :green_heart:
mvnsite
1m 36s

the patch passed

+1 :green_heart:
javadoc
1m 20s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 41s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 28s

the patch passed

+1 :green_heart:
shadedclient
20m 54s

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

_ Other Tests _

+1 :green_heart:
unit
16m 17s

hadoop-common in the patch passed.

+1 :green_heart:
unit
190m 15s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 42s

The patch does not generate ASF License warnings.

336m 52s

Subsystem
Report/Notes

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

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

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

uname
Linux 1e406c3a3c9c 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 977035a5a140ace03c0ec32438ee49933ca95d09

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

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

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

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 20s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
13m 46s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
19m 39s

trunk passed

+1 :green_heart:
compile
8m  9s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
7m 35s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
2m  1s

trunk passed

+1 :green_heart:
mvnsite
1m 39s

trunk passed

+1 :green_heart:
javadoc
1m 20s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 41s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 13s

trunk passed

+1 :green_heart:
shadedclient
20m 45s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m  9s

the patch passed

+1 :green_heart:
compile
8m  0s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
8m  0s

the patch passed

+1 :green_heart:
compile
7m 37s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
7m 37s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
1m 54s
/results-checkstyle-root.txt
root: The patch generated 3 new + 304 unchanged - 0 fixed = 307 total (was 304)

+1 :green_heart:
mvnsite
1m 40s

the patch passed

+1 :green_heart:
javadoc
1m 23s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 43s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 23s

the patch passed

+1 :green_heart:
shadedclient
21m  0s

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

_ Other Tests _

+1 :green_heart:
unit
16m 22s

hadoop-common in the patch passed.

+1 :green_heart:
unit
190m 13s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 40s

The patch does not generate ASF License warnings.

337m  0s

Subsystem
Report/Notes

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

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

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

uname
Linux b2af95725e98 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 02d21e1316a674fa225cc8fd1a63ea2fba9f77aa

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

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

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

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

@simbadzina Do you have time to review this? Thanks

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 32s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 55s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
30m 57s

trunk passed

+1 :green_heart:
compile
16m 20s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
14m 45s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
4m 17s

trunk passed

+1 :green_heart:
mvnsite
3m  8s

trunk passed

+1 :green_heart:
javadoc
2m 26s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 46s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
3m 25s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-warnings.html
hadoop-hdfs-project/hadoop-hdfs in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
35m 11s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 31s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m  4s

the patch passed

+1 :green_heart:
compile
15m 39s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
15m 39s

the patch passed

+1 :green_heart:
compile
14m 43s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
14m 43s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
4m 19s
/results-checkstyle-root.txt
root: The patch generated 1 new + 304 unchanged - 0 fixed = 305 total (was 304)

+1 :green_heart:
mvnsite
3m 22s

the patch passed

+1 :green_heart:
javadoc
2m 22s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 39s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
6m 23s

the patch passed

+1 :green_heart:
shadedclient
35m 56s

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

_ Other Tests _

+1 :green_heart:
unit
19m 14s

hadoop-common in the patch passed.

+1 :green_heart:
unit
217m 35s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
1m  6s

The patch does not generate ASF License warnings.

458m 38s

Subsystem
Report/Notes

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

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

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

uname
Linux 370cbac834a0 5.15.0-86-generic #96-Ubuntu SMP Wed Sep 20 08:23:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 1a5600d2f736468b9a66e71eabf9abe969bad7d1

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

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

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

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 24s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 15s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
20m 20s

trunk passed

+1 :green_heart:
compile
9m 20s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
8m 36s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
2m 14s

trunk passed

+1 :green_heart:
mvnsite
1m 43s

trunk passed

+1 :green_heart:
javadoc
1m 18s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 31s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
1m 57s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-warnings.html
hadoop-hdfs-project/hadoop-hdfs in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
21m 31s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 22s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m  6s

the patch passed

+1 :green_heart:
compile
9m  3s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
9m  3s

the patch passed

+1 :green_heart:
compile
8m 17s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
8m 17s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
2m 10s
/results-checkstyle-root.txt
root: The patch generated 1 new + 304 unchanged - 0 fixed = 305 total (was 304)

+1 :green_heart:
mvnsite
1m 40s

the patch passed

+1 :green_heart:
javadoc
1m 11s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 36s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 27s

the patch passed

+1 :green_heart:
shadedclient
22m  4s

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

_ Other Tests _

-1 :x:
unit
16m 43s
/patch-unit-hadoop-common-project_hadoop-common.txt
hadoop-common in the patch passed.

-1 :x:
unit
207m 44s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 43s

The patch does not generate ASF License warnings.

361m 43s

Reason
Tests

Failed junit tests
hadoop.conf.TestCommonConfigurationFields

hadoop.hdfs.TestReadStripedFileWithDecoding

hadoop.hdfs.TestDecommissionWithStripedBackoffMonitor

hadoop.hdfs.TestDFSOutputStream

hadoop.hdfs.TestDFSStripedOutputStream

hadoop.hdfs.tools.TestDebugAdmin

hadoop.hdfs.TestReconstructStripedFileWithRandomECPolicy

hadoop.hdfs.TestReadStripedFileWithDNFailure

hadoop.hdfs.TestDFSStripedOutputStreamWithRandomECPolicy

Subsystem
Report/Notes

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

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

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

uname
Linux 79d228e29929 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / a2e4edfd92c992a32c93fe8990ba8051ecb02415

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

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

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

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 22s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 13s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
20m 13s

trunk passed

+1 :green_heart:
compile
9m 28s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
8m 32s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
2m 14s

trunk passed

+1 :green_heart:
mvnsite
1m 45s

trunk passed

+1 :green_heart:
javadoc
1m 17s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 35s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
1m 56s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-warnings.html
hadoop-hdfs-project/hadoop-hdfs in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
21m 49s

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

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 23s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 11s

the patch passed

+1 :green_heart:
compile
8m 54s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
8m 54s

the patch passed

+1 :green_heart:
compile
8m 29s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
javac
8m 29s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
2m 16s
/results-checkstyle-root.txt
root: The patch generated 1 new + 304 unchanged - 0 fixed = 305 total (was 304)

+1 :green_heart:
mvnsite
1m 33s

the patch passed

+1 :green_heart:
javadoc
1m 13s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 37s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 30s

the patch passed

+1 :green_heart:
shadedclient
22m 15s

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

_ Other Tests _

-1 :x:
unit
16m 31s
/patch-unit-hadoop-common-project_hadoop-common.txt
hadoop-common in the patch passed.

-1 :x:
unit
263m 37s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 42s

The patch does not generate ASF License warnings.

418m 19s

Reason
Tests

Failed junit tests
hadoop.conf.TestCommonConfigurationFields

hadoop.hdfs.TestFileChecksum

hadoop.hdfs.TestRenameWhileOpen

hadoop.hdfs.TestDecommissionWithStriped

hadoop.hdfs.TestDFSStripedInputStream

hadoop.hdfs.server.namenode.snapshot.TestRenameWithSnapshots

hadoop.hdfs.TestDFSFinalize

Subsystem
Report/Notes

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

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

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

uname
Linux 55b9b8aaaa69 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / a2e4edfd92c992a32c93fe8990ba8051ecb02415

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

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

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

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.


Deploy docs, improve CI workflow

Also removes redundant dev badge from README and pushes
doc previews for PRs.

Thanks @fredrikekre!


@reboot

Will Jobber or does jobber support the @reboot protocol like normal cron.
Or is there a way to get this same effect within jobber.
Thank you

Ok, I’ll look into this.

On Jan 28, 2019, at 9:45 PM, Andy<EMAIL_ADDRESS>wrote:
I'm also interested in this, it's a thing that many cron replacements miss :-(
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

+1

+1


Potentially unjustified unsafe

There are a couple of uses of unsafe in the code that I think are not strictly necessary. The prime example is this:
https://github.com/kbknapp/clap-rs/blob/6e948994a61e389c8f3b6726435d3d14bdd328bb/src/app/parser.rs#L1350-L1362
I understand that this instance of unsafe might have been introduced for performance reasons, however I don't think giving up safety is a clear win here. When printing help text for the user, I/O time probably dominates UTF-8 validation time, and help texts aren't enormously long either, usually (typically at most in the tens of kilobytes).
Similarly, in https://github.com/kbknapp/clap-rs/blob/6e948994a61e389c8f3b6726435d3d14bdd328bb/src/app/help.rs#L850-L855
it seems highly unlikely to me that a debug build would experience a bottleneck in the UTF-8 validation of this one method.

Agreed! I think those were either left over from old code, or under assumptions that only ascii code would be supported. Both of which seem wrong now.
The debug code one I actually want to look up git blame and see if that's something I did :stuck_out_tongue_winking_eye: as I normally don't care at all about debug performance. Even if I didn't write it, I still accepted it, so there's no escaping the blame :laughing:
I'd be good with a PR removing these uses if someone wants a quick PR!

Awesome, in this case I'll open a PR soon!

There are two more instances of unsafe I'd like to address separately, if possible. First one is:
https://github.com/kbknapp/clap-rs/blob/1ef6e62e1e05f3a1c5dee4d946eb85c9778e4065/src/macros.rs#L430-L442
If this is static for performance reasons, it could be realized using the dedicated lazy_static crate instead to avoid reinventing the wheel.
However, better yet, staticness could also be removed altogether, with the following additional advantages:

This gives more control to the user (if they wanted static, they could wrap it into a lazy_static, and if they preferred no unsafe, they could move it to a place in their code so that no static is necessary). This is in accordance with the common Rust design guideline that the consumer of an API should be able to decide how they want to use it, potentially based on context (for example, functions that need a value should generally take it by move, not by reference and then magically clone()ing inside).
The current implementation of the macro is such that when called multiple times, it will always return a result that respects the separator used in the first call. This might be counter-intuitive when it's called more than once with different separator arguments. I wouldn't necessarily call it a bug as long as it's documented, but it can be surprising.

The second one is:
https://github.com/kbknapp/clap-rs/blob/53f3b65d2469a00eefa3cbad5a2650d602dbbfc8/src/osstringext.rs#L26-L32
Wouldn't be it better to, instead of creating our own from_bytes method, use the already-existing one provided by OsStr itself, and use OsStrs instead of &OsStrs? There aren't many places this is being used (https://github.com/kbknapp/clap-rs/search?utf8=✓&q=from_bytes&type=), so it should also be a relatively painless change.

[crate authors]

I'm good trying this method if it can be implemented in a non-breaking manner. Even as unfortunate as it is, if we can't do this in a non-breaking way it'll have to wait.

[OsStrExt3]

This was written before the actual from_bytes was stablized. Now that we're well beyond the stable minus two releases from when from_bytes was stablized, I'm good with updating it so long as we ensure we bump the minor version of this lib and document that a newer version of Rust is required.

[crate authors]
"Non-breaking" meaning retaining the incorrect behavior with regards to the separator, or leaving it static? And if the former, wouldn't this classify as a bugfix rather than a breaking change? (AFAIK semver allows breaking changes without major version bump if they are actually bugfixes.)

[OsStrExt3]
Sure, will try to do that as well, then!

"Non-breaking" meaning retaining the incorrect behavior with regards to the separator, or leaving it static? And if the former, wouldn't this classify as a bugfix rather than a breaking change? (AFAIK semver allows breaking changes without major version bump if they are actually bugfixes.)

I mean non breaking, meaning change of user code with the exception of correcting a bugfix like you stated. Specifically, I'm talking about removing staticness altogether. For the bug about using crate_authors multiple times, it seems unlikely to me. I agree, its a bug per-se but only due to implementation or lack of being documented. I have yet to have anyone actually complain about this bug. The only thing I'm trying to avoid (not that you're advocating this, I'm just making my position clear 😄 ) is justifying a breaking change behind this one bug might be a stretch of allowable semver.
Thanks for tackling all this by the way!

Oooh, alright. Sure thing – of course I'm advocating for making this changes without user code having to change. My suggestion about "giving users the control over staticness" might have sounded contradictory to that, in fact.
And indeed there may be no non-breaking way to remove staticness since the macro yields a pointer. I'll see — but I'll try very hard to do it anyway.
And, as always — you are welcome! I'm happy to improve libraries that I love.

This has been resolved via https://github.com/kbknapp/clap-rs/pull/1058.


Fix 'String concat is not required here; use a single string instead' issue in web\app\themes\sasquatch\lib\assets.php

CodeFactor found an issue: String concat is not required here; use a single string instead
It's currently on:
web\app\themes\sasquatch\lib\assets.php:46

Fixed in 1.0.5


make travis retry and wait after success

retry up to 3 times
wait 5 seconds after success to make sure we can send info to travis-ci before VM shuts down

LGTM


The error was: "redirect_uri" mismatch when signing in as a customer to a newly created storefront

What is the location of your example repository?
https://github.com/rfried/redirect_uri-error
Which package or tool is having this issue?
Hydrogen
What version of that package or tool are you using?
2024.1.4
What version of Remix are you using?
2.8.0
Steps to Reproduce
Follow getting started guide: https://shopify.dev/docs/custom-storefronts/hydrogen/building/begin-development

in your shopify account, add the Hydrogen app
open command prompt
run "npm create @shopify/hydrogen@latest"
during creation name the project "redirect_uri-error" (for the sake of these reproducion instructions"
select "Typescript", "Tailwind", scaffold all standard routes, and allow it to create a hydrogen shortcut "h2"
run "cd redirect_uri-error"
run "h2 link", link to your account and create new Storefront. Name it whatever
run "h2 deploy". Now you have a boilerplate hydrogen storefront
In your shopify account, open the Hydrogen app and find the storefront you just created
Open the storefront URL
Click "Sign in"
See redirect_uri error.

Expected Behavior
I expected to see a sign in page and to be able to create/sign in as a customer
Actual Behavior
I got a redirect_uri error message and the only way to recover was to go back in the browser. There's no way to sign in as a customer on my custom hydrogen storefront
https://private-user-images.githubusercontent.com/1892407/316275996-9db13cf4-5d32-4094-bd53-9edf552c99ed.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTEzMjU5MDYsIm5iZiI6MTcxMTMyNTYwNiwicGF0aCI6Ii8xODkyNDA3LzMxNjI3NTk5Ni05ZGIxM2NmNC01ZDMyLTQwOTQtYmQ1My05ZWRmNTUyYzk5ZWQucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDMyNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDAzMjVUMDAxMzI2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZGIwYjQxODQyNzRjMTE3ZWMzMjQ5N2UyZjE4NjgwN2JlOGFiMmU5YjBmMzY5ODU5MDYxYjZhYmI0YjQ0M2Q1OCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.HaDxvPNQ9WYeopaO0WJsG89bVdmrVvPL5OwOgyf6M6o

As noted in the help discussion. It looks like even for a domain generated by shopify when creating a storefront the customer API must be set up. I wish that when hydrogen creates a public URL for a new storefront, that by default it would also set up that storefront's customer API to use that URL. All of the URLs in this screenshot I set up manually but it was a domain that shopify created for my store when it created the store. This is information that should have already been set up correctly for people using the hydrogen generator.

@rfried ah I understand. This is more of a feature request, and I agree, the oxygen preview deployment URLs should automatically support the Customer Account API redirects. We are tracking this internally, but have no timeline on when this might be available.

@blittle perhaps in the meantime the documentation can be updated?

Hi team! I have a report of a Plus merchant running into this exact issue on their Hydrogen storefront.
If you access the storefront here, then click Sign in, you will be able to replicate.
Screenshot:

An error occured
invalid_request
The error was: "redirect_uri" mismatch
Show request details
client_id=shp_dce6cf2d-d4dc-49f9-a1ce-d8e6497a7ffa
scope=openid email https://api.customers.com/auth/customer.graphql
response_type=code
redirect_uri=https://ar.waterdropfilter.com/account/authorize
state=1713412431297k14gvq68nxg
nonce=5f520f9420ed1d49cc04a4dff06ee5a4
code_challenge=52HnM1t3ax9aA4-XB6Hrl6eNH-XrbHpwfsmemSrnv-8
code_challenge_method=S256

Request ID: 47595cc6-ee86-44f9-8fec-d486d72652a2-1713412431

Splunk logs using index=catchall 47595cc6-ee86-44f9-8fec-d486d72652a2-1713412431
We see:
{:message=>"#<Rack::OAuth2::Server::Authorize::BadRequest: invalid_request :: \"redirect_uri\" mismatch>", :redirect=>false}
...
Completed 400 Bad Request in 29ms

Are you able to advise on a fix? From your discussion above, it sounds like there might be an issue with the merchant's use of the Customer Account API?
Internal
Ticket
@blittle @rfried

@FinnKinnear try reviewing this related discussion:
https://github.com/Shopify/hydrogen/discussions/1893#discussioncomment-9100724


Configuration for LIVE broadcasting

How to configure the player for online broadcasting (live broadcasting) so that the seekbar does not appear and there is an LIVE caption? Thanks!

Old issue but you can just do this with css

@daursdg - Can you please confirm if the issue resolved or does it still exist ?

@daursdg - Can you please confirm if the issue resolved or does it still exist ?

STOP
Sent from my iPhone

On Dec 24, 2021, at 5:48 AM, HariPriyaKuberSingh @.***> wrote:

@daursdg - Can you please confirm if the issue resolved or does it still exist ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.

Closing the ticket since there is no confirmation from the reporter


Menu Links Don't Work on Touchscreens

Issue Summary
Top level menu links don't work on touch screens.
When you press them, nothing happens.

Seem to work here on mobile + desktop mode in chrome.

Mobile is fine as it turns in to the mobile menu. I can only test on the iPad for touch, so can't comment on other touch devices!

I didn't think about tablets, just phone and desktops. Thanks for catching this


[ESLint] Turn on no-console for the codebase

Overview
Tidies up the codebase a bit.
Screenshots (if applicable)
N/A
Documentation

[ ] Updated Typescript types and/or component PropTypes
[ ] Added / modified component docs
[ ] Added / modified Storybook stories

@mshwery Would prefer to be intentional about console.log :)


Fix off-by one error in the LineIndex::offset calculation

Summary
This fixes an error where Emacs showed obscure syntax errors.
The reason for the obscure syntax errors was that Ruff incorrectly
applied the change updates from emacs because of an off-by-one error
in the UTF32 to UTF8 offset calculation. When you add a new type wrapper to make it clear that the offsets are one-based and you still get it wrong :shrug:
We didn't notice this error before because VS code always uses UTF 16 and
I think neovim uses UTF8. The same method is also used to detect the format range.
But it was never significant there because range formatting always extends the range to the enclosing statement.
Fixes https://github.com/emacs-lsp/lsp-mode/issues/4547
Fixes https://github.com/astral-sh/ruff-lsp/issues/495
and possibly https://github.com/astral-sh/ruff/issues/13392
Test Plan
Added tests. I used emacs with a debug build that contains the fix and I no longer
observed any stale/obscure syntax errors

Nice!


BUG: Profile setting

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?

Showing right prompt when there is no profile image to delete

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@PranotiPD already being done


Update system-utilities.mdx

fix missing brackets in code example
Summary
I was reading the docs and found a typo. It does not impact the source code.
Test plan
Not applicable.

Thanks!


thanks

hello , Do you have a semgrep-wrapper example that can run in windows system?
or is there a new semgrep-idea-plugin tool that don't need semgrep-wrapper？
thank you!

Hi @neil1811 I don't have an example of the windows system (I don't have a windows box to work on / test from). There's not another tool I'm aware of that doesn't need the wrapper. By design this uses the system intellij has for external tools. You could build a plugin that was native, but I don't think you can easily call external programs from it. You would have to package the binary to semgrep witht he plugin and do a lot of work to make it workable. I thought that wasn't the best design.


zf-panel animation variable no effect

I didn't recognise any effect when setting $panel-animation-speed in my settings.scss.
I searched where it's used in the generated css-file and couldn't find my value. Or any value related to the speed of the panel.
I checked _panel.scss and it looks like, that the variable for panel speed ($panel-animation-speed: 0.25s !default;) is not used at the moment.
Let me know if I missed something.

Ah, that's a legacy variable and shouldn't be in the codebase anymore. You can control the speed of animations with our built-in classes, or with your own CSS.
With our classes:

With your own code:

.panel-thing {
  transition-duration: 500ms;
}


Audio filters

Hello,
Is there any way to apply audio filters too. Something like -filter:a "highpass=f=200, lowpass=f=3000"
Thanks

https://xkcd.com/979

You can apply audio filters
currentaudiofile is a file object made with open()
outputfilename is a string thats a valid filepath like C:/testfile_processed.wav
input = ffmpeg.input(currentaudiofile.name)
input.audio.filter("lowpass",frequency="1500")
ffmpeg.output(input, outputfilename).run()


Auxilary packages

TODO

Closed in favor of https://github.com/Synthetixio/synthetix-v3/pull/1915


Hooks up Echo to make API calls

Our current betas don't update echo, which is a bit strange. This fixes that.

I broke this in #2802


35 | Search Insert Position | Java | Python

Title -  35.Search Insert Position
What will change -
Type of Issue -
Please add/delete options that are not relevant.

[x] Adding New Code
[] Improving Code
[] Improving Documentation
[] Bug Fix

Programming Language
Please add/delete options that are not relevant.

[x] Python
[] C++
[x] Java
[] SQL

Self Check

Ask for issue assignment and wait to get assigned to it before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Discord server ✉ - https://discord.gg/CXksGdn
Happy Coding,

Assign to me!

@Shrirang97 Just make an issue for 1 Language at a time. You can create a separate issue for another language.
Edit the Issue for now.

Ok.


💡 Created typescript definition file

Built off of the sample @vsviridov provided in issue #1. I cleaned that up and made it correct (to the best of my knowledge). Should provide adequate definition for those of us running svelte w/ typescript

Hi @Abourass - first of all, my apologies for the late reply, swarmed the last few days! Thanks so much for your contribution, much appreciated! I don't personally use typescript often and I'm not too familiar with best practices, so do bear with me. I've added some comments in the code and would love to hear your thoughts.

@zerodevx - I think I've resolved everything! Let me know if there's anything else

Thank for your contribution! 🎉


feat: allow customization of tvOS playback expierence

This PR would allow to customize the tvOS playback expierence as descripted here:
https://developer.apple.com/documentation/avkit/customizing_the_tvos_playback_experience#3820220
The custom title, subtitle and description are all optional and can specified in the source object.
These props are not handled on android side.
Additionally this PR allows to adapt the chapters interface for tvOS, according to the documentation:
https://developer.apple.com/documentation/avkit/presenting_navigation_markers#2948687
For providing custom chapters, a new prop chapters got introduced.
Provide an example of how to test the change
The changes can be tested in the tvOS example project, by running on an tvOS simulator.

@Duell10111  I forgot to publish my review :'(
I think this PR can be merged soon. please let me know

@freeboub Thanks for the review, I outsourced the functions to Util files to reduce the code in the RCTVideo class.
I left the externalMetadata feature available on iOS as this could maybe also be helpful on iOS devices.
So from my POV the PR can be merged. :)


Free floating library functions - SafeTransfer

When I import Solady libraries I should be able to specify the actual functions I want, like {safeTransferFrom} from {SafeTransferLib}, thoughts?

I prefer non-free-floating functions.


This is GameHack after all.

This is GameHack after all.
PUA stands for Potentially Unwanted Application.
—
Reply to this email directly, view it on GitHub
https://github.com/cleolibrary/CLEO5/issues/179#issuecomment-2295612868,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BKTZYW6OSHZXQVKWOZK6IF3ZSFTKJAVCNFSM6AAAAABMW7M4NSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJVGYYTEOBWHA
.
You are receiving this because you authored the thread.Message ID:
@.***>


Syntax highlighting does not work

Using latest released version at this time.
Here's what it looks like:

I don't really have much more I can say about this, except that it was working not too long ago :/

Don't worry, this is an issue caused by having the Babel ES6/ES7 extension installed at the same time. Closing.


Improvement

Try to fix problems I mentioned in #33 and #17

Coverage increased (+0.2%) to 95.062% when pulling ce6bc8cb01195a19f196723211b46687f1aa2c14 on SickSAMA:improvement into ab6c94ef6d81cf914cfa0ac764f737129f9029e0 on jasonslyvia:master.

Awesome! But it seems breaking some tests?

Firefox 31.0.0 (Linux 0.0.0) LazyLoad Basic setup should warn if custom placeholder has a largely varied `height` than `this.props.height` FAILED

I assume once the user provides placeholder, we don't care the height any more as it's never used.

Fair point, do you care removing related test?

Coverage increased (+0.2%) to 95.062% when pulling bc6c8e66b5e99250e305c64a30f7a15ee4835715 on SickSAMA:improvement into ab6c94ef6d81cf914cfa0ac764f737129f9029e0 on jasonslyvia:master.

Great, really appreciate your effort!

Cheers! 😆

Do you need an immediate release regarding this change?

Sure, thank you.

2.1.4 it is.


Minimal rust version specification

I am curious if we should enforce the minimal Rust version needed:
https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field ?
Right now, the minimal version is 1.80, is it fine?

I'm open to setting that. If we do set it, then we'll probably need to have a CI job that runs with the MSRV, otherwise we won't know when we need to bump it. Alternatively, we could just document that we only support the latest release of rust.

Good, I can work on this and ensure it via CI, good idea.


audio_output.instances not cleaned up properly

I stress tested an application Im making (for fun really) and it plays audio. Due to the high volume of play commands added I started to get log messages that I think originates from the CommandQueueFull error (perhaps kira printed it?).
I did a profiling and ran the stress test and basically even long after all audio stops playing this method:
https://github.com/NiklasEi/bevy_kira_audio/blob/a08ee2a4e3719cfbffbbca5f3feb61690e2233c6/src/audio_output.rs#L454
continues to take up in the profiling I did 34-35ms of frame-time (steadily growing from almost no time at start of app then really going haywire after a while). My guess is that the cleanup_stopped_instances don't detect them as faulty or even started but they still exist in the vector or something.

I might be running into a similar issue...
I see a number of these messages

Failed to set volume for instance: CommandQueueFull

and then a panic on

thread 'main' panicked at 'Failed to add sound to the AudioManager: CommandProducerError(CommandQueueFull)', bevy_kira_audio-ec9a44b32a5309c9/85658f1/src/audio_output.rs:75:14

It seems exactly like what's mentioned in #17 actually.. I might not be quite on latest on this project since its targeting bevy 0.6.1

You might be hit by stuff that has been "fixed" since then as you are using 0.6.1, I see a bit of refactoring in the CommandQueueFull places since 0.6.1 compat. Still seems to be some bad instances not being cleaned up still.

I will take a look at this again after #48
Thank you for pointing out the problem :slightly_smiling_face:

I stress-tested main by playing two sounds per frame on two channels.

The instances in the plugin's resource get cleaned up properly
I could run the app for ~10min before shutting it down
On one attempt I got an error from Kira saying that there was no more space for sound after a couple of minutes

Oh, I was probably adding 100's of sounds in one channel per frame. It must def be some instances here:
https://github.com/NiklasEi/bevy_kira_audio/blob/a08ee2a4e3719cfbffbbca5f3feb61690e2233c6/src/audio_output.rs#L459
(as that system took 34-35ms, I'd guess quite the few actually)
that wasn't properly cleaned up in: cleanup_stopped_instances
It might be that the list of instances that hasn't been stopped and possibly are in a bad state due to the massive amounts that were trying to be added, I've let the app run for quite the bit to see if that list was ever drained but it didnt seem so.
Q: did you do it after updating Kira now? If so I can see if I can get latest bevy_kira_audio if/when you release it and re-do my test :)

Actually, go to 1:50:ish in this video and you can see what I mean by adding a non-sane amount of audio https://www.youtube.com/watch?v=bTj6nkgYDl

The video does not seem to be available anymore, but I think I saw it on Discord (if I am thinking about the correct showcase).
I see that the 2 sounds per frame were way too little for a decent stress test. There is now a stress_test example on main. I can play around 75 (short) sounds per frame on my machine without getting any underrun or errors (it requires adjusting the audio backend settings though).
Running this example on version 0.9, I can reproduce the issue that instances don't get cleaned up properly. This works fine on main, so I would consider the issue closed with the next release.
Please correct me if I am wrong, but playing multiple instances of the same sound in the same frame is quite useless as it only increases the amplitude of the sound. In bevy_kira_audio 0.9 only one instance of the sound would actually play because Kira v5 had a cooldown on sounds by default. So effectively you were probably not playing so many sounds every frame in your game. As far as I can see, this cooldown option is gone in Kira v6. I would be interested to see the difference when you upgrade.

I can change bevy kira to point at master on github and re-test :) Lets hold thumbs that its fixed for next release.

"Please correct me if I am wrong, but playing multiple instances of the same sound in the same frame is quite useless as it only increases the amplitude of the sound. " Yes, but unless I add an reduce system that takes one frames request of  "play this audio please" and reduce a number of these requests to "play it once, but with volume * the requests" then thats how the nature of "thing x happens -> please play its corresponding audio" will be like out of the box :)

It should be resolved in the just-published version 0.10

Heya! Am about to upgrade, will try a stress-test later and report back if still wonky :) Closing this for now! Thanks for your work :)


Control-P in explorer split doesn't open file finder

Issue: Control+P in the explorer split doesn't open the quick open menu (rather, it moves back a line).
It's easy to repro by navigating to the explorer split (<C-w><C-h>), and then pressing Control-P.

On man, I've worked this out.  I looked again at my config.js which I'd copied from the docs  without really understanding what it did.  And it unbinds Ctrl-P.  I've commented that out, and it works again.  How embarrassing. ;-)

Not embarrassing at all. Glad you figured it out!

So, as far as I understand there is no issue to resolve - closing this issue.
If I'm wrong, please reopen.
Cheers :)

I'll re-open this since I am still having this issue.
The Command Palette opens fine, its just the quick open menu that doesn't work for me.
I've not got any unbinds in my config so I assume it is just a bug that we aren't passing over the <c-p> keybind when in the explorer or in the sidebar.

From a quick debugging, two things are  happening here:

The command quickOpen.show isn't in the commandDictionary when we press it in the explorer or side bar.
Instead, it then cycles through the other <c-p> bindings, before landing on menu.previous which does work.

I'm less sure why the commandDictionary doesn't contain this command though.

I'll close this out now, since its been fixed recently.


Add EuclideanNorm XLA kernel

Per discussion https://github.com/tensorflow/tensorflow/pull/41916#issuecomment-673641088. In order not to have additional works for common reduction ops, it calls another virtual function, which defaults to returning input directly when axis is empty. I have no better engineering way to approach this, so it's more than welcome to have some feedback. Thanks!
/cc @cheshire.

I see, since XlaReductionOp is a kernel it might be harder to wrap it. Could you just factor out all the helper methods you need and call them directly instead of using inheritance?

I see, since XlaReductionOp is a kernel it might be harder to wrap it. Could you just factor out all the helper methods you need and call them directly instead of using inheritance?

Will do :-) Thanks!

@WindQAQ Any update on this PR? Please. Thanks!

It has been 14 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

@WindQAQ Any update on this PR? Please. Thanks!

I'm going to go ahead and close this PR, because it seems to have stalled. If you're still interested in pursing this (and responding to my comments), please feel free to reopen!


[wip] Refactor Installer to new Manager interface and implementation

Description of change
This PR changes the Installer interface to rename to Manager and split out the ReconcileRelease functionality into new methods that can be called from the HelmOperatorReconciler (first commit), and it splits the helm.go file into 3 separate files more along the lines of the separation of concerns (second commit).
Motivation for change
The current Installer interface pushes too much logic into the ReconcileRelease function, which makes it difficult for the HelmOperatorReconciler to manage the various phases of the Helm release process and to provide detail in the custom resource status block (status updates coming in follow on PR).

@hasbro17 - There's a bunch of copy and paste here that moves logic into the HelmOperatorReconciler and cleans up the release package to separate things out, so its a pretty big changeset.
I'm not totally happy with the outcome and I'm thinking it might make sense to convert the Manager field to a ManagerFactory on the HelmOperatorReconciler and then use the factory to create a CR-specific Manager instance during every reconciliation. That way the CR doesn't have to be passed and parsed multiple times like it does with this PR as it is now.
Thoughts on the various approaches?


lwaftr does not generate icmpdest-unreachable for traffic non-matching binding-table

Dear all,
I am triggering a corner-case when testing the icmp-dest-unreach generation of lwaftr.
Depending on the traffic-pattern, the generation of icmp-dest-unreachable works or does not work.
Its a combination of

proto (udp/icmp)
if public IP is listed in the binding-table

issue
If the lwaftr receives an IPv4 icmp-echo-reply from internet, while the dest IPv4 is listed in the binding-table, but with no corresponding PSID, then the icmp-dest-unreachable will not be generated.
whats working
09:08:21.144270 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 42: <IP_ADDRESS>.53 > <IP_ADDRESS>.53: [|domain]
09:08:21.144317 02:cf:69:15:81:01 > 90:e2:ba:94:2a:bc, ethertype IPv4 (0x0800), length 88: <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 54

no-match-udp.pcap.gz
not-working
09:10:16.952484 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 242: <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 53, seq 0, length 208

no-match-icmp.pcap.gz
both IPv4 frames towards the lwaftr have same src/dst IP/MAC. The one which works is UDP-SPORT 53. The one which does to work is ICMP-ID 53.
the binding-table
Binding-table is important here, as the dst-ip must be listed in the binding-table, but must not have a matching PSID (in this case we start with PSID=1 while offending packets use PSID=0)
psid_map {
  <IP_ADDRESS> {psid_length=6, shift=10}
  <IP_ADDRESS> {psid_length=6, shift=10}
...
  { ipv4=<IP_ADDRESS>, psid=1, b4=2a02:587:f710::40, aftr=0 }
  { ipv4=<IP_ADDRESS>, psid=2, b4=2a02:587:f710::41, aftr=0 }
  { ipv4=<IP_ADDRESS>, psid=3, b4=2a02:587:f710::42, aftr=0 }

cg-binding_table.txt.s.gz
launching lwaftr
lab@ubuntu1:~/vmxlwaftr/tests/issue-no-seen-icmp-dst-unreach$ sudo usr/local/bin/snabb  lwaftr run --conf snabbvmx-lwaftr-xe1.conf --on-a-stick 0000:81:00.1

config-file
lab@ubuntu1:~/vmxlwaftr/tests/issue-no-seen-icmp-dst-unreach$ cat snabbvmx-lwaftr-xe1.conf
hairpinning = false,
binding_table = binding_table.txt.s,
aftr_ipv6_ip = 2001:db8::1,
aftr_ipv4_ip = <IP_ADDRESS>,
aftr_mac_inet_side = 02:cf:69:15:81:01,
inet_mac = 90:e2:ba:94:2a:bc,
aftr_mac_b4_side = 02:cf:69:15:81:01,
next_hop6_mac = 90:e2:ba:94:2a:bc,
ipv4_mtu = 9000,
ipv6_mtu = 9000,
vlan_tagging = false,
policy_icmpv4_incoming = allow,
policy_icmpv4_outgoing = allow,
policy_icmpv6_incoming = allow,
policy_icmpv6_outgoing = allow,
icmpv6_rate_limiter_n_packets = 300000,
icmpv6_rate_limiter_n_seconds = 4,

kindly have a look into this. Priority is low
thanks
christian

Thanks for the excellent report; we'll get on this.

Many thanks.
after further looking into it, it seemed I have to rephrase the above.
While I thought it is PSID-related, with todays testing of the same it just seemed to be proto-type related (ICMP or UDP). The influence of PSID it not seen in todays testing..
Please see below:
sendp(e_b/v4_from_internet/reply_match,iface='p4p1')
this is a valid packet matching the binding-table to verify proper operation and lwaftr properly performs encapsulation
04:00:02.428765 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 242: <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 1024, seq 0, length 208
04:00:02.430009 02:cf:69:15:81:01 > 90:e2:ba:94:2a:bc, ethertype IPv6 (0x86dd), length 282: 2a02:587:f700::100 > 2a02:587:f710::40: <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 1024, seq 0, length 208

sendp(e_b/v4_no_match/reply_match,iface='p4p1')
this is the one not working as expected. Packet does not match binding-table (192.168 is not listed in the binding-table) - as seen we miss the icmp-dest-unreachbale generated for this icmp-packet.
lab@ubuntu1:~/vmxlwaftr/tests/issue-no-seen-icmp-dst-unreach$ grep 192.168 binding_table.txt.s

04:10:47.892515 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 242: <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 1024, seq 0, length 208

sendp(e_b/v4_no_match/udp_match,iface='p4p1')
this works fine. same IP-addresses as the non-working case, but UDP instead of ICMP
04:10:47.904269 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 42: <IP_ADDRESS>.1024 > <IP_ADDRESS>.53: [|domain]
04:10:47.904344 02:cf:69:15:81:01 > 90:e2:ba:94:2a:bc, ethertype IPv4 (0x0800), length 88: <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 54

sendp(e_b/v4_from_internet/udp_no_match,iface='p4p1')
and thats the correction from the initial report. Packet is matching the public Ip in binding-table, but not matching PSID. in yesterdays testing there was no icmp-dest unreach generated, but today it is. Will need to look into it ...
lab@ubuntu1:~/vmxlwaftr/tests/issue-no-seen-icmp-dst-unreach$ grep <IP_ADDRESS> binding_table.txt.s
  <IP_ADDRESS> {psid_length=6, shift=10}
  { ipv4=<IP_ADDRESS>, psid=1, b4=2a02:587:f710::40, aftr=0 }
  { ipv4=<IP_ADDRESS>, psid=2, b4=2a02:587:f710::41, aftr=0 }

04:10:47.916268 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 42: <IP_ADDRESS>.53 > <IP_ADDRESS>.53: [|domain]
04:10:47.916330 02:cf:69:15:81:01 > 90:e2:ba:94:2a:bc, ethertype IPv4 (0x0800), length 88: <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 54

** scapy script **
lab@cgrafubuntu2:~/cg-ubuntu2/testing1.0$ cat test-icmp.py
#!/usr/bin/python

from scapy.all import *
size="a" * 200

e_r=Ether(src='90:e2:ba:94:2a:bc', dst='5c:45:27:15:a0:0d')
e_b=Ether(src='90:e2:ba:94:2a:bc', dst='02:cf:69:15:81:01')
v6=IPv6(src='2a02:587:f710::40',dst='2a02:587:f700::100')
v4_from_internet=IP(src='<IP_ADDRESS>',dst='<IP_ADDRESS>')
v4_to_internet=IP(dst='<IP_ADDRESS>',src='<IP_ADDRESS>')
v4_no_match=IP(dst='<IP_ADDRESS>',src='<IP_ADDRESS>')
request_match=ICMP(type=8, code=0, id=1024)/size
reply_match=ICMP(type=0, code=0, id=1024)/size
udp_match=UDP(sport=1024)
udp_no_match=UDP(sport=53)

for x in range(0,1):
        sendp(e_b/v4_from_internet/reply_match,iface='p4p1')
        #sendp(e_b/v6/v4_no_match/request_match,iface='p4p1')
        sendp(e_b/v4_no_match/reply_match,iface='p4p1')
        sendp(e_b/v4_no_match/udp_match,iface='p4p1')
        sendp(e_b/v4_from_internet/udp_no_match,iface='p4p1')

thanks
christian

Dear all,
a quick update on this - issue is still seen with latest snabb lwaftr:
lab@ubuntu1:~/latest-snabb-binary/snabb/src$ git log
commit e13962200c119c0665816672e541491701822bd9
Merge: 459b9a4 b84b46a
Author: Jessica Tallon<EMAIL_ADDRESS>Date:   Wed Nov 30 10:43:32 2016 +0100

    Merge pull request #605 from Igalia/get-state-docs

    Add better documentation for config get-state

used config and starting snabb lwaftr
^Clab@ubuntu1:~/latest-snabb-binary/snabb/src$ cat migrated.cfg
binding-table {
  br-address 2a02:587:f700::100;
  psid-map {
    addr <IP_ADDRESS>;
    psid-length 6;
    shift 10;
  }
  psid-map {
    addr <IP_ADDRESS>;
    end-addr <IP_ADDRESS>;
    psid-length 6;
    shift 10;
  }
  psid-map {
    addr <IP_ADDRESS>;
    end-addr <IP_ADDRESS>;
    psid-length 6;
    shift 10;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 1;
    b4-ipv6 2a02:587:f710::40;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 4;
    b4-ipv6 2a02:587:f710::43;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 7;
    b4-ipv6 2a02:587:f710::46;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 2;
    b4-ipv6 2a02:587:f710::41;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 8;
    b4-ipv6 2a02:587:f710::47;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 9;
    b4-ipv6 2a02:587:f710::48;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 3;
    b4-ipv6 2a02:587:f710::42;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 5;
    b4-ipv6 2a02:587:f710::44;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 6;
    b4-ipv6 2a02:587:f710::45;
  }
  softwire {
    ipv4 <IP_ADDRESS>;
    psid 10;
    b4-ipv6 2a02:587:f710::49;
  }
}
external-interface {
  error-rate-limiting {
    packets 600000;
  }
  ip <IP_ADDRESS>;
  mac 02:cf:69:15:81:01;
  mtu 9000;
  next-hop {
    mac 90:e2:ba:94:2a:bc;
  }
  reassembly {
    max-fragments-per-packet 40;
  }
}
internal-interface {
  error-rate-limiting {
    packets 300000;
    period 4;
  }
  ip 2001:db8::1;
  mac 02:cf:69:15:81:01;
  mtu 9000;
  next-hop {
    mac 90:e2:ba:94:2a:bc;
  }
  reassembly {
    max-fragments-per-packet 40;
  }
}

lab@ubuntu1:~/latest-snabb-binary/snabb/src$ sudo ./snabb  lwaftr run --conf migrated.cfg --on-a-stick 0000:81:00.1
Warning: No NUMA memory affinity.
Pass --cpu to bind to a CPU and its NUMA node.
migrated.cfg: loading source configuration from migrated.cfg
[mounting /var/run/snabb/hugetlbfs]

With that configuration I am sending 3 IPv4 packets into lwaftr:

First packet get translated properly and showing that lwaftr is functional
2nd and 3rd packet do not match binding-table (packets use PSID 0, while binding-table starts with PSID 1)
second packet is not matching the binding-table, but is UDP. Here an ICMP dest-runreach is generated
third (last) packet is not matching binding-table as well, but is proto ICMP. Here the icmp dest. unreachable should have been generated as well, but this is not happening. The issue is opened because of the 3rd packet the lwaftr is not generating an icmp dest unreachable

lab@cgrafubuntu2:~$ sudo tcpdump -n -i p4p1 -e ether host 90:e2:ba:94:2a:bc
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on p4p1, link-type EN10MB (Ethernet), capture size 262144 bytes
# first packet
13:42:03.872948 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 42: <IP_ADDRESS>.53 > <IP_ADDRESS>.1024: [|domain]
13:42:03.873385 02:cf:69:15:81:01 > 90:e2:ba:94:2a:bc, ethertype IPv6 (0x86dd), length 100: 2a02:587:f700::100 > 2a02:587:f710::40: <IP_ADDRESS>.53 > <IP_ADDRESS>.1024: [|domain]

#2nd packet
13:42:03.884901 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 42: <IP_ADDRESS>.53 > <IP_ADDRESS>.53: [|domain]
13:42:03.885421 02:cf:69:15:81:01 > 90:e2:ba:94:2a:bc, ethertype IPv4 (0x0800), length 88: <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 54

#3rd packet
13:42:03.897311 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 242: <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 53, seq 0, length 208

generate the packets via scapy  or use below provided pcap
lab@cgrafubuntu2:~/cg-ubuntu2/testing1.0$ cat test-icmp.py
#!/usr/bin/python

from scapy.all import *
size="a" * 200

e_r=Ether(src='90:e2:ba:94:2a:bc', dst='5c:45:27:15:a0:0d')
e_b=Ether(src='90:e2:ba:94:2a:bc', dst='02:cf:69:15:81:01')
v6=IPv6(src='2a02:587:f710::40',dst='2a02:587:f700::100')
v4_from_internet=IP(src='<IP_ADDRESS>',dst='<IP_ADDRESS>')
v4_to_internet=IP(dst='<IP_ADDRESS>',src='<IP_ADDRESS>')
v4_no_match=IP(dst='<IP_ADDRESS>',src='<IP_ADDRESS>')
request_match=ICMP(type=8, code=0, id=1024)/size
request_no_match=ICMP(type=8, code=0, id=53)/size
reply_match=ICMP(type=0, code=0, id=1024)/size
reply_no_match=ICMP(type=0, code=0, id=53)/size
udp_match4=UDP(dport=1024)
udp_match6=UDP(sport=1024)
udp_no_match=UDP(sport=53,dport=53)

response = raw_input("What traffic shall be generated [46]: ")

if response in [ '4',"" ]:
    for x in range(0,1):
        ## first packet, shows lwaftr proper function
        sendp(e_b/v4_from_internet/udp_match4,iface='p4p1')

        ## lwaftr creates valid icmpdest-unreachable
        ## second packet
        sendp(e_b/v4_from_internet/udp_no_match,iface='p4p1')

        ## valid frame, gets proper translated
        # sendp(e_b/v4_from_internet/reply_match,iface='p4p1')

        ## 3rd packet. not matching binding-table, but proto icmp
        ## doesn ot match binding-table, icmpdest-unreachbale not generated
        sendp(e_b/v4_from_internet/reply_no_match,iface='p4p1')

        #sendp(e_b/v4_no_match/reply_match,iface='p4p1')
        # sendp(e_b/v4_no_match/udp_match4,iface='p4p1')

if response in [ '6',"" ]:
    for x in range(0,1):
        sendp(e_b/v6/v4_to_internet/udp_match6,iface='p4p1')
        sendp(e_b/v6/v4_to_internet/udp_no_match,iface='p4p1')
        sendp(e_b/v6/v4_to_internet/request_match,iface='p4p1')
        sendp(e_b/v6/v4_to_internet/request_no_match,iface='p4p1')
        sendp(e_b/v6/v4_no_match/request_match,iface='p4p1')

input-pcap
lab@cgrafubuntu2:~$ sudo tcpdump -n -i p4p1 -e ether host 90:e2:ba:94:2a:bc
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on p4p1, link-type EN10MB (Ethernet), capture size 262144 bytes
13:47:26.032405 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 42: <IP_ADDRESS>.53 > <IP_ADDRESS>.1024: [|domain]
13:47:26.044349 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 42: <IP_ADDRESS>.53 > <IP_ADDRESS>.53: [|domain]
13:47:26.056593 90:e2:ba:94:2a:bc > 02:cf:69:15:81:01, ethertype IPv4 (0x0800), length 242: <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 53, seq 0, length 208

input.pcap.gz
thanks
christian

Hi @chrgraf
Sorry for the delay looking into this bug, and thanks again for the great report.
As you suggested it seems there's a missing ICMP error message for the third packet, as it doesn't match the binding table. I dove into the source code to check what's happening. In the code that manages incoming ICMP packets:
   if get_ipv4_proto(get_ethernet_payload(pkt)) == proto_icmp then
      -- RFC 7596 section 8.1 requires us to silently drop incoming
      -- ICMPv4 messages that don't match the binding table.
      counter.add(lwstate.counters["drop-in-by-rfc7596-icmpv4-bytes"], pkt.length)
      counter.add(lwstate.counters["drop-in-by-rfc7596-icmpv4-packets"])
      return drop_ipv4(lwstate, pkt, pkt_src_link)
   end

This snippet of code is the one that discards non-matching ICMP packets. Then I read more in detail section 8.1 of RFC 7596. This is the relevant paragraph:
2.  If the ICMP Type field is set to 0 or 8 (echo reply or request),
       then the lwAFTR MUST take the value of the ICMP Identifier field
       as the source port and use this value to look up the binding
       table for an encapsulation destination.  If a match is found, the
       lwAFTR forwards the ICMP packet to the IPv6 address stored in the
       entry; otherwise, it MUST discard the packet.

So to silently drop a non-matching ICMP packet is the expected behaviour according to the RFC. I understand this was confusion and seemed like a bug. I thought it was a bug too.
Now that the issue is clarified, I think we the issues can be closed. Agree?

Dear Diego,
This is a perfect match. Please have the issue closed and please excuse for reporting this wrongly.
Thanks
Christian

Christian Graf
Senior Consulting Engineer
Telephone +49 5651/336174
Mobile +49 175/2929 167
<EMAIL_ADDRESS>www.juniper.net
Juniper Networks GmbH
Sitz der Gesellschaft / Registered office: Oskar-Schlemmer-Str. 15, 80807 München
Registergericht / Commercial registry: München, HRB 205571
Geschäftsführer / Directors: Johannes Albers, Stephen Byrne, Terrance Floyd Spidell

This email contains material that is confidential. The content of this email is for the sole use of the intended recipient(s).
Any review or distribution by persons other than the intended recipient(s) without the express permission of Juniper Networks is strictly prohibited.
If you are not the intended recipient, please contact the sender and delete/destroy all copies of this email and any related attachments.
Juniper does not guarantee the accuracy or completeness of third party materials or information

From: Diego Pino <notifications<EMAIL_ADDRESS>Reply-To: Igalia/snabb <reply<EMAIL_ADDRESS>Date: Freitag, 2. Dezember 2016 14:23
To: Igalia/snabb <snabb<EMAIL_ADDRESS>Cc: Christian Graf <cgraf<EMAIL_ADDRESS>Mention <mention<EMAIL_ADDRESS>Subject: Re: [Igalia/snabb] lwaftr does not generate icmpdest-unreachable for traffic non-matching binding-table (#533)
Hi @chrgrafhttps://github.com/chrgraf
Sorry for the delay looking into this bug, and thanks again for the great report.
As you suggested it seems there's a missing ICMP error message for the third packet, as it doesn't match the binding table. I dove into the source code to check what's happening. In the code that manages incoming ICMP packets:
if get_ipv4_proto(get_ethernet_payload(pkt)) == proto_icmp then
-- RFC 7596 section 8.1 requires us to silently drop incoming
-- ICMPv4 messages that don't match the binding table.
counter.add(lwstate.counters["drop-in-by-rfc7596-icmpv4-bytes"], pkt.length)
counter.add(lwstate.counters["drop-in-by-rfc7596-icmpv4-packets"])
return drop_ipv4(lwstate, pkt, pkt_src_link)
end
This snippet of code is the one that discards non-matching ICMP packets. Then I read more in detail section 8.1 of RFC 7596. This is the relevant paragraph:

If the ICMP Type field is set to 0 or 8 (echo reply or request),
then the lwAFTR MUST take the value of the ICMP Identifier field
as the source port and use this value to look up the binding
table for an encapsulation destination.  If a match is found, the
lwAFTR forwards the ICMP packet to the IPv6 address stored in the
entry; otherwise, it MUST discard the packet.

So to silently drop a non-matching ICMP packet is the expected behaviour according to the RFC. I understand this was confusion and seemed like a bug. I thought it was a bug too.
Now that the issue is clarified, I think we the issues can be closed. Agree?

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Igalia/snabb/issues/533#issuecomment-264452854, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AU_G6k5WnBWGrFvA_BPZ8BtCXSuCuBgFks5rEBvbgaJpZM4KnV7G.


[ERROR] Build failed using vcpkg+cmake for arm-uwp platform

Host Environment

OS: windows10 desktop
Compiler: arm-uwp

To Reproduce
Steps to reproduce the behavior:
./vcpkg install --recurse abseil:arm-uwp
Failure logs

item
message

file
absl/time/internal/cctz/src/zone_info_source.cc

error
fatal error C1189: #error:  Unsupported MSVC platform

#if defined(_M_IX86)
#elif defined(_M_IA_64) || defined(_M_AMD64) || defined(_M_ARM64)
#else
#error Unsupported MSVC platform
#endif  // _M_<PLATFORM>

No code here to capture _M_ARM
Additional context
I had try to modify with a patch to capture _M_ARM which just to confirm that it can be compiled through.  I am not sure if this condition is handled correctly.
Hope that our group could give a good solution to solve this error.
Thank you!
From 5968dc74a7b3c326387db1d985e0f5eb0c3d273f Mon Sep 17 00:00:00 2001
Subject: [PATCH 12/12] ARM-UWP
Url: https://github.com/suhao/pkg/commit/c1cd17dd2b9982e9686b73236e8b587f7239808f
---
 absl/time/internal/cctz/src/zone_info_source.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/absl/time/internal/cctz/src/zone_info_source.cc b/absl/time/internal/cctz/src/zone_info_source.cc
index 98ea161..a155fe8 100644
--- a/absl/time/internal/cctz/src/zone_info_source.cc
+++ b/absl/time/internal/cctz/src/zone_info_source.cc
@@ -83,7 +83,7 @@ ZoneInfoSourceFactory default_factory = DefaultFactory;
     "@@U?$default_delete@VZoneInfoSource@cctz@time_internal@" ABSL_INTERNAL_MANGLED_NS                                   \
     "@@@std@@@std@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@2@@Z@" ABSL_INTERNAL_MANGLED_BACKREFERENCE \
     "@@ZA")
-#elif defined(_M_IA_64) || defined(_M_AMD64) || defined(_M_ARM64)
+#elif defined(_M_IA_64) || defined(_M_AMD64) || defined(_M_ARM64) || defined(_M_ARM)
 #pragma comment(                                                                                \
     linker,                                                                                \
     "/alternatename:?zone_info_source_factory@cctz_extension@time_internal@" ABSL_INTERNAL_MANGLED_NS                     \
--
2.26.0.windows.1

link: https://github.com/microsoft/vcpkg/issues/11372

This is fixed.


instance_profiling: fix detail page crash

Reason: row may be undefined

I don't know why it works :)

Let me check the document deeper, actually, we don't add the getKey prop in other tables.

According to the source code: https://github.com/microsoft/fluentui/pull/1347/files/c1fc1449ae064802e967b36022349179dbabb8b2#diff-92617c3c9fecec754c52f44e7204cec2R321 , if we don't supply the getKey prop, it will use index as the row key, but it is still weird if the row is undefined, the getKey shouldn't be called.
So getKey should be necessary when the rows need to sort, I will add it for StatementsTable and SlowQueryTable later.

Maybe the core problem is why row can be undefined?

Maybe the core problem is why row can be undefined?

Oh! good hint! I think it must the ShimmeredDetailsList create those empty rows, and it proved!
https://github.com/microsoft/fluentui/blob/master/packages/office-ui-fabric-react/src/components/DetailsList/ShimmeredDetailsList.base.tsx#L24
export class ShimmeredDetailsListBase extends React.Component<IShimmeredDetailsListProps, {}> {
  private _shimmerItems: null[];
  private _classNames: IProcessedStyleSet<IShimmeredDetailsListStyles>;

  constructor(props: IShimmeredDetailsListProps) {
    super(props);

    this._shimmerItems = props.shimmerLines ? new Array(props.shimmerLines) : new Array(SHIMMER_INITIAL_ITEMS);
  }

This line code doesn't judge the item whether null (they ever did, but don't know why it is removed in the master branch):
https://github.com/microsoft/fluentui/blob/master/packages/office-ui-fabric-react/src/components/List/List.tsx#L549
let itemKey = this.props.getKey ? this.props.getKey(item, index) : item && (item as any).key;

I guess the workaround is to use row => row?.xxx.

Considering current situation, I have some ideas about improving the table, as well as resolving some <Skeleton> related display problems. I will open a PR for this :)


[WFCORE-6421] Wait until the server is fully started before starting …

…with the tests
Jira issue: https://issues.redhat.com/browse/WFCORE-6421

Thanks @yersan


[Enhance]: Allignment correction in main entry page ,

Description
The allignment of the "learn about us section" is basically wrong or not good looking ,
make it more attractive by incresing the size of the image present in left and create Box like model which , enhance User-Interface.
Screenshots

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I'm a GSSoC'24-Extd contributor
[X] I'm a Hacktoberfest'24 contributor
[X] I am willing to work on this issue (optional)

Hey @Jashwanth-rit, actually, this is what we want. This is not a bug; it is intended to be exactly like this. Please raise another issue, which I'm happy to assign to you. However, make sure that the issue you raise is valid and genuinely needs to be addressed on our website; otherwise, invalid issues will be closed. Thank you!

checkout Issueno: #755 can I work on that , I am new to open source contribution.


Remake pagination component

Redesigned the pagination component to display it in a simpler way and with the option for the user to navigate to:

Next page
Previous page
First page
Last page

Covering changes in component display behavior depending on which page the user is on, for example, close to the first or last page and when on the first or last page.
Screens:

As it is a completely new component, I ended up recreating the tests on it and checking yet another new scenario, that of displaying the number of the last page.
@rosa ready for review ;)


[cli] add cli-radio build

Background:
In an early stage of developing a new product, developers may want to verify
the Thread related hardware functionality, for example, send, receive, etc.
However if the product uses the posix <-> RCP mode, it's hard to verify it
before the posix daemon can run on the host. cli-ftd and cli-mtd could be an
alternative. However, if the product uses the posix <-> RCP mode, the space of
the 802.15.4 radio chip will be very small. For example, nRF52811 doesn't have
enough space to flash cli-ftd or cli-mtd firmware. So this PR creates a new
firmware ot-cli-radio which has very limited functionality for verifying the
hardware.
Basically, the ot-cli-radio consists of openthread-radio and
libopenthread-cli-radio.a. It supports very few cli commands. The most
important command is diag. Currently, there are: diag, help, reset,
version.
Currently, the diag commands have different implementation on RCP:

For commands like diag start, the process function (Diags::ProcessStart)
is first called on host. Then host sends an SPI frame to the RCP and
Diags::ProcessStart (different implementation) is called again on RCP.
For commands like diag send, Diags::ProcessSend is first called on host.
Then host sends an SPI frame to the RCP, directly calling send API. And there
is no Diags::ProcessSend implemented on RCP.

Let's call the implementation of Diags::Process* currently on host as native
diag commands. When we run ot-cli-radio, we should use the native diag
commands because it won't interact with a posix daemon and it processes the
diag commands through the whole process. So this PR adds a new option
OPENTHREAD_CONFIG_DIAG_NATIVE_CMDS_ON_RCP to control whether to use the
native diag implementation on RCP. When we use a normal RCP, the option should
be disabled. While when use ot-cli-radio, the option should be enabled.

@abtink Thanks!
I added a build check for cli-radio.

@jwhui
I've updated the implementation. I added a new lib openthread-radio-alone which is slightly different from openthread-radio. I think we can add more features to openthread-radio-alone for building a firmware to debug the hardware. Thoughts?

I've updated the implementation. I added a new lib openthread-radio-alone which is slightly different from openthread-radio. I think we can add more features to openthread-radio-alone for building a firmware to debug the hardware. Thoughts?

@Irving-cl , can we think of a better name than openthread-radio-alone? I don't think openthread-radio-alone provides much insight into how it differs from openthread-radio. How about something like openthread-radio-cli?

I've updated the implementation. I added a new lib openthread-radio-alone which is slightly different from openthread-radio. I think we can add more features to openthread-radio-alone for building a firmware to debug the hardware. Thoughts?

@Irving-cl , can we think of a better name than openthread-radio-alone? I don't think openthread-radio-alone provides much insight into how it differs from openthread-radio. How about something like openthread-radio-cli?

@jwhui
SGTM. I'll update it.

SGTM. I'll update it.

@Irving-cl , thanks. Looking at this again, is OPENTHREAD_RADIO_CLI a struct superset of OPENTHREAD_RADIO? In other words, are there situations where code is included with OPENTHREAD_RADIO_CLI but not OPENTHREAD_RADIO? I'm wondering if we can reduce the number of OPENTHREAD_RADIO || OPENTHREAD_RADIO_CLI occurrences.

@Irving-cl , thanks. Looking at this again, is OPENTHREAD_RADIO_CLI a struct superset of OPENTHREAD_RADIO? In other words, are there situations where code is included with OPENTHREAD_RADIO_CLI but not OPENTHREAD_RADIO? I'm wondering if we can reduce the number of OPENTHREAD_RADIO || OPENTHREAD_RADIO_CLI occurrences.

@jwhui OPENTHREAD_RADIO_CLI is almost a superset of OPENTHREAD_RADIO. However, OPENTHREAD_RADIO and OPENTHREAD_RADIO_CLI are different in some functions:

In factory_diags.cpp, they have different implementations of factory diag functions
In radio_callbacks.cpp, they have different implementation of HandleDiagsReceiveDone and HandleDiagsTransmitDone.

Do you mean we still use OPENTHREAD_RADIO for the common cases and add another macro for the cases where they are different?

Do you mean we still use OPENTHREAD_RADIO for the common cases and add another macro for the cases where they are different?

@Irving-cl , yes, exactly. What do you think?

@Irving-cl , yes, exactly. What do you think?

Make sense to me. I will update it.

@jwhui
I've updated it. Now I made OPENTHREAD_RADIO_CLI as a sub option when using OPENTHREAD_RADIO. OPENTHREAD_RADIO_CLI will only have effect when OPENTHREAD_RADIO is enabled.


corrected api endpoint

Have corrected work-item API endpoints

Can one of the admins verify this patch?

[test]


feat: [TextIntroduction] Support ReactNode content in the description

Close #338
On SBL we have some descriptions that include lists (Errors page: download and upload links).  I'm seeing console errors about nesting uls within paragraphs.
This PR basically renders description within a <p> tag if it's a string, otherwise renders it unchanged allowing us to pass more customized content.

@shindigira Fixed.


Custom text for icon

This was closed previously (without explanation) But it would be great to have custom values for image text

I don't think I've ever closed this feature request but this is actually a thing I'm planning to add in the future.

Would there be a way to hotlink the image? (clicking the image brings you to a link)

Unfortunately not. Discord doesn't support links/Markdown etc. in your status.

Unfortunate, I might make a feature request

This has been implemented in v1.5.0.


Notes on Cache and Performance

So, we're building the new WebUI and we want it to be amazingly good and blazing fast. Some of the last changes introduced, such as the #702 and #718 in the future, can slow down the pages a bit (at least on my computer on Chrome).
Why? #702 because it is always fetching the locations for our peers. I have 800+ in this moment so as soon as I open the WebUI what happens? It starts fetching all of them, even when we're not on the peers page, with a maximum of 10 concurrently. During that time, opening the File Browser to add files or even just navigate can be a pain. After having the info about all peers, it gets normal.
On #718 the same thing would happen.
I've got two different suggestions that could be applied to solve this issues.
1 Caching
Why not cache the peer location's information for x days and then update it? Why not cache a file's health for y hours before updating it again? Those are not really node-dependent informations so it wouldn't matter much. It wouldn't harm anyone, and we'd have a more fluid WebUI. We could also provide some option to clean the cache or tell the user that there is a cache that can be cleaned through the browser.
Uh, and we could also cache information on Explore panel. After all, a hash is linked to a content. But I'm not sure if IPFS doesn't do this already internally when we fetch stuff from the DAG api. I still don't know how it will work for other IPLD things (like Git and Ethereum). Correct me if I'm wrong.
Cool links:

https://reduxbundler.com/api/included-bundles.html#createcachebundlecachingfunction
https://github.com/HenrikJoreteg/money-clip

2 Web Workers
We could perform secondary data fetching in Web Workers to make the interface more responsive while we're fetching peers, peer informations and other background tasks that aren't crucially needed.
Some background fetchings we could make:

Peers
Peer Locations
Files find provs

Some things done in the main process:

Files stuff
Config stuff
Everything else absolutely needed for a specific page.

So, this is it. I'd personally like to take a shot at the caching stuff if you think it's a great idea. /cc @ipfs-shipyard/gui

I'm very much in favour of this. It's on the roadmap, we just wanted to hit the problems first before adding caching... having IPFS running on the same machine we the webui should make lots of look ups so fast that we don't need caching... but the api for peers is so low-level that we end up having to do a lot of work at the app layer. The longer term fix that @alanshaw is thinking about is to propose a new peers api that does the work of tracking peers bandwidth over time and bandwidth usage by root CID.
But I totally agree with you @hacdias we want webui to be awesome today, and I'm super happy that you've dug into the the redux-bundler docs and recommendations for this!
I'd pause on web-workers while we get the caching story figured out. I think part of that will be replacing the redux-bundler asyncResourceBundle with our own fork that takes into account that the IPFS api is often running on the same machine... an ipfsResouceBundle perhaps that know about content Ids and peer ids, and automatically caches things forever where they are content addressed.

Thanks @olizilla! 😄 Did you have the opportunity to check #731? Although I now had an idea: cache on MFS instead of the browser. What do you think? 😄I'd like to work on that. Not that automatic as you are saying but something in the lines of what I've done on #731 but with MFS instead.

@olizilla yes #732 😄

Uh, and taking into account what @lidel said about a remote node I think I can answer myself about this:

Although I now had an idea: cache on MFS instead of the browser. What do you think? 😄I'd like to work on that.

It would just be the same problem if the node was far away or the connection was slow. The best bet is browser cache. Right? @olizilla ping me when you see #732. I'd like to merge it and implement it on #718 too!

@alanshaw that would also be a good idea (I think). It could be a storage-only node. Do you think it would be a good idea?

Due to all of the background tasks WebUI is doing, reactX functions are not being called as frequently as they should or at least they're taking more time to be called due to blocking.
Changing reactFilesFetch to have those two console.logs:
bundle.reactFilesFetch = createSelector(
  'selectFilesIsLoading',
  'selectFilesShouldUpdate',
  'selectIpfsReady',
  'selectRouteInfo',
  'selectFiles',
  (isLoading, shouldUpdate, ipfsReady, {url, params}, files) => {
    if (!isLoading && ipfsReady && url.startsWith('/files')) {
      console.log('1')
      if (shouldUpdate || !files || files.path !== decodeURIComponent(params.path)) {
        console.log('2')
        return { actionCreator: 'doFetchFiles' }
      }
    }
  }
)

Provides this effect: https://youtu.be/1RQdA9YMBM8 . I had to wait about 5 seconds to call the function which is visibly slow. And this wasn't the slowest thing I've seen here. I'll probably try changing the FilesPage in order to call directly doFilesFetch instead of having this react function.

We went with caching. There is more to do, but this issue has done it's job.


Parallel tests + new resource manager

Type of change

Enhancement / new feature

Description

Parallel tests
better resource manager which removes only resources for test/testclass identifier

TODO:

Add orchestration to do not remove default infra if some other parallel tests using it
Change displayName to class+displayName

Checklist

[ ] Update/write design documentation in ./documentation/design
[ ] Write tests and make sure they pass
[ ] Update documentation
[ ] Check RBAC rights for Kubernetes / OpenShift roles
[ ] Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
[ ] Reference relevant issue(s) and close them after merging
[ ] Update CHANGELOG.md

@lulf I can investigate that in another PR, I for now I this this approach is the best, in next PRs I would like to fix orchestration to do not delete default infra is some other test using it, also I want to enable parallel classes and storing test logs into files.

@lulf yup I closed that

@kornys Why did the test run take longer than normal? :)

@lulf I dont know :( maybe env?

I think maybe the reason is that it would make most impact on tests that use separate infra, rather than tests using the same infra, because the time to configure address + endpoint should be in the order of seconds once infra is running.

Or maybe thing is synchronized and will be serialize that way :)


Handle request and response in one class

Only one filter is used for client / server-side. This approach is used by the most of our bindings and make tracee easier to use.

LGTM


docs: fix some component names

Purpose
Some component names are not being correctly inferred by Storybook tools.
It is unclear why, as it was working in previous versions.
Approach
Hard-code problematic components' names in Storybook only.
Ideally we can simply remove this after tools work once again.
Testing
Check code snippet for all components (e.g. Spinner, Radio, Checkbox) before and after change
Risks
Temporary code tends to live longer than intended

that would increase bundle size, and not provide much value
I can see it being important for React browser extensions, which probably rely on those, but I haven't tested yet whether or not they present the same issue as Storybook
it's very likely that was the cause, although it's weird it still works for some components but not others

I'll merge as is for a fix to our docs and we can change it later if necessary