(FACT-1616) update the OS specific facts

Updated the OS specific fact tests with Code Style, TestRail ID's, and risk tags
This update is all do..end blocks, indentation, comments and test_name strings
NOTE: I did NOT do any updates for supported platforms that where added or removed

Tested on:
arista4-32a, ciscoxr-64a%7Bhypervisor=vmpooler%7D, cisconx-64a%7Bhypervisor=vmpooler%7D, cumulus25-64a, debian8-64a, fedora25-64a, osx1012-64a, redhat7-64a, sles12-64a, solaris11-64a, ubuntu1610-64a, windows10ent-64a, windows2016-64a
Still need to test on AIX

CLA signed by all contributors.

@johnduarte I had thought the same thing, but I didn't want to make all the changes at one time to make it easier to review.
I plan to update the supported OS versions and look at converting all the on_fact() calls into just a call or 2 to facter --yaml and then parse the output since it shouldn't be changing between calls.

Ignoring whitespace changes:
$ git show -w upstream/pr/1563
commit 75989b44e9217809bce58f9efa73078c039ff751
Author: Eric Delaney<EMAIL_ADDRESS>Date:   Wed Apr 26 13:40:15 2017 -0700

    (FACT-1616) update the OS specific facts

    Update the OS specific fact tests with Code Style, TestRail ID's, and risk tags
    Updated a few comments and test names to be more generic

    NOTE: I did NOT do any updates for supported platforms that where added or removed

diff --git a/acceptance/tests/facts/aix.rb b/acceptance/tests/facts/aix.rb
index 1de0b1d..5e6e951 100644
--- a/acceptance/tests/facts/aix.rb
+++ b/acceptance/tests/facts/aix.rb
@@ -1,8 +1,9 @@
-test_name "Facts should resolve as expected in AIX 5.3, 6.1, 7.1 and 7.2"
+test_name "C69636: Facts should resolve as expected on AIX" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that facts specific to an OS configuration
-# resolve as expected in AIX 5.3, 6.1, and 7.1.
+# resolve as expected on AIX.
 #
 # Facts tested: os, processors, networking, identity, kernel
 #
@@ -28,8 +29,7 @@ agents.each do |agent|
     os_arch     = /[Pp]ower[Pp][Cc]/
     os_hardware = /IBM/

-  step "Ensure the OS fact resolves as expected"
-
+    step "Ensure the OS fact resolves as expected" do
       expected_os = {
           'os.architecture'  => os_arch,
           'os.family'        => 'AIX',
@@ -42,9 +42,9 @@ agents.each do |agent|
       expected_os.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the Processors fact resolves with reasonable values"
-
+    step "Ensure the Processors fact resolves with reasonable values" do
       expected_processors = {
           'processors.count'  => /[1-9]+/,
           'processors.isa'    => os_arch,
@@ -54,8 +54,9 @@ agents.each do |agent|
       expected_processors.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the identity fact resolves as expected"
+    step "Ensure the identity fact resolves as expected" do
       expected_identity = {
           'identity.gid'        => '0',
           'identity.group'      => 'system',
@@ -67,8 +68,9 @@ agents.each do |agent|
       expected_identity.each do |fact, value|
         assert_equal(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the kernel fact resolves as expected"
+    step "Ensure the kernel fact resolves as expected" do
       expected_kernel = {
           'kernel'           => 'AIX',
           'kernelrelease'    => kernel_release,
@@ -80,3 +82,5 @@ agents.each do |agent|
         assert_match(value, fact_on(agent, fact))
       end
     end
+  end
+end
diff --git a/acceptance/tests/facts/debian.rb b/acceptance/tests/facts/debian.rb
index c3583f7..eba78b3 100644
--- a/acceptance/tests/facts/debian.rb
+++ b/acceptance/tests/facts/debian.rb
@@ -1,8 +1,9 @@
-test_name "Facts should resolve as expected in Debian 6 and 7"
+test_name "Facts should resolve as expected in Debian" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that facts specific to an OS configuration
-# resolve as expected in Debian 6, 7 and 8.
+# resolve as expected in Debian.
 #
 # Facts tested: os, processors, networking, identity, kernel
 #
@@ -32,7 +33,7 @@ agents.each do |agent|
       os_hardware = 'i686'
     end

-  step "Ensure the OS fact resolves as expected"
+    step "Ensure the OS fact resolves as expected" do
       expected_os = {
           'os.architecture'         => os_arch,
           'os.distro.codename'      => codename,
@@ -52,8 +53,9 @@ agents.each do |agent|
       expected_os.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the Processors fact resolves with reasonable values"
+    step "Ensure the Processors fact resolves with reasonable values" do
       expected_processors = {
           'processors.count'         => /[1-9]/,
           'processors.physicalcount' => /[1-9]/,
@@ -64,8 +66,9 @@ agents.each do |agent|
       expected_processors.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the identity fact resolves as expected"
+    step "Ensure the identity fact resolves as expected" do
       expected_identity = {
           'identity.gid'        => '0',
           'identity.group'      => 'root',
@@ -77,8 +80,9 @@ agents.each do |agent|
       expected_identity.each do |fact, value|
         assert_equal(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the kernel fact resolves as expected"
+    step "Ensure the kernel fact resolves as expected" do
       expected_kernel = {
           'kernel'           => 'Linux',
           'kernelrelease'    => os_kernel,
@@ -90,3 +94,5 @@ agents.each do |agent|
         assert_match(value, fact_on(agent, fact))
       end
     end
+  end
+end
diff --git a/acceptance/tests/facts/el.rb b/acceptance/tests/facts/el.rb
index c026979..3faa036 100644
--- a/acceptance/tests/facts/el.rb
+++ b/acceptance/tests/facts/el.rb
@@ -1,8 +1,9 @@
-test_name "Facts should resolve as expected in EL 4, 5, 6 and 7"
+test_name "Facts should resolve as expected on EL" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that facts specific to an OS configuration
-# resolve as expected in EL 4, 5, 6 and 7.
+# resolve as expected on EL.
 #
 # Facts tested: os, processors, networking, identity, kernel
 #
@@ -53,8 +54,7 @@ agents.each do |agent|
       processor_model_pattern = 'Intel\(R\)'
     end

-  step "Ensure the OS fact resolves as expected"
-
+    step "Ensure the OS fact resolves as expected" do
       expected_os = {
           'os.architecture'  => os_arch,
           'os.family'        => 'RedHat',
@@ -68,9 +68,9 @@ agents.each do |agent|
       expected_os.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the Processors fact resolves with reasonable values"
-
+    step "Ensure the Processors fact resolves with reasonable values" do
       expected_processors = {
           'processors.count'         => /[1-9]/,
           'processors.physicalcount' => /[1-9]/,
@@ -81,8 +81,9 @@ agents.each do |agent|
       expected_processors.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the identity fact resolves as expected"
+    step "Ensure the identity fact resolves as expected" do
       expected_identity = {
           'identity.gid'        => '0',
           'identity.group'      => 'root',
@@ -94,9 +95,9 @@ agents.each do |agent|
       expected_identity.each do |fact, value|
         assert_equal(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the kernel fact resolves as expected"
-
+    step "Ensure the kernel fact resolves as expected" do
       expected_kernel = {
           'kernel'           => 'Linux',
           'kernelrelease'    => kernel_version,
@@ -108,3 +109,5 @@ agents.each do |agent|
         assert_match(value, fact_on(agent, fact))
       end
     end
+  end
+end
diff --git a/acceptance/tests/facts/fedora.rb b/acceptance/tests/facts/fedora.rb
index 4d05be9..5bd88e7 100644
--- a/acceptance/tests/facts/fedora.rb
+++ b/acceptance/tests/facts/fedora.rb
@@ -1,8 +1,9 @@
-test_name "Facts should resolve as expected in Fedora 20, 21, and 22"
+test_name "Facts should resolve as expected on Fedora" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that facts specific to an OS configuration
-# resolve as expected in Fedora 20, 21, and 22.
+# resolve as expected on Fedora.
 #
 # Facts tested: os, processors, networking, identity, kernel
 #
@@ -20,7 +21,7 @@ agents.each do |agent|
       os_hardware = 'i686'
     end

-  step "Ensure the OS fact resolves as expected"
+    step "Ensure the OS fact resolves as expected" do
       expected_os = {
           'os.architecture'  => os_arch,
           'os.family'        => 'RedHat',
@@ -33,8 +34,9 @@ agents.each do |agent|
       expected_os.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the Processors fact resolves with reasonable values"
+    step "Ensure the Processors fact resolves with reasonable values" do
       expected_processors = {
           'processors.count'         => /[1-9]/,
           'processors.physicalcount' => /[1-9]/,
@@ -45,8 +47,9 @@ agents.each do |agent|
       expected_processors.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the identity fact resolves as expected"
+    step "Ensure the identity fact resolves as expected" do
       expected_identity = {
           'identity.gid'        => '0',
           'identity.group'      => 'root',
@@ -58,13 +61,18 @@ agents.each do |agent|
       expected_identity.each do |fact, value|
         assert_equal(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the kernel fact resolves as expected"
+    step "Ensure the kernel fact resolves as expected" do
       kernel_version = case os_version
-    when '20' then '3.11'
-    when '21' then '3.17'
-    when '22' then '4.0'
-    else 'undefined'
+                         when '20' then
+                           '3.11'
+                         when '21' then
+                           '3.17'
+                         when '22' then
+                           '4.0'
+                         else
+                           'undefined'
                        end

       expected_kernel = {
@@ -78,3 +86,5 @@ agents.each do |agent|
         assert_match(value, fact_on(agent, fact))
       end
     end
+  end
+end
diff --git a/acceptance/tests/facts/macosx.rb b/acceptance/tests/facts/macosx.rb
index 54bc01e..e1dd457 100644
--- a/acceptance/tests/facts/macosx.rb
+++ b/acceptance/tests/facts/macosx.rb
@@ -1,8 +1,9 @@
-test_name "Facts should resolve as expected in Mac OS X 10.9 and 10.10"
+test_name "Facts should resolve as expected on Mac OS X" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that facts specific to an OS configuration
-# resolve as expected in Mac OS X 10.9 and 10.10
+# resolve as expected on Mac OS X
 #
 # Facts tested: os, processors, networking, identity, kernel
 #
@@ -27,8 +28,7 @@ agents.each do |agent|
         fail_test("Unknown os_version #{os_version}")
     end

-  step "Ensure the OS fact resolves as expected"
-
+    step "Ensure the OS fact resolves as expected" do
       expected_os = {
           'os.architecture'         => 'x86_64',
           'os.family'               => 'Darwin',
@@ -47,9 +47,9 @@ agents.each do |agent|
       expected_os.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the Processors fact resolves with reasonable values"
-
+    step "Ensure the Processors fact resolves with reasonable values" do
       expected_processors = {
           'processors.count'         => /[1-9]/,
           'processors.physicalcount' => /[1-9]/,
@@ -60,8 +60,9 @@ agents.each do |agent|
       expected_processors.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the identity fact resolves as expected"
+    step "Ensure the identity fact resolves as expected" do
       expected_identity = {
           'identity.gid'        => '0',
           'identity.group'      => 'wheel',
@@ -73,9 +74,9 @@ agents.each do |agent|
       expected_identity.each do |fact, value|
         assert_equal(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the kernel fact resolves as expected"
-
+    step "Ensure the kernel fact resolves as expected" do
       expected_kernel = {
           'kernel'           => 'Darwin',
           'kernelrelease'    => /#{kernel_major}\.\d\.\d/,
@@ -87,3 +88,5 @@ agents.each do |agent|
         assert_match(value, fact_on(agent, fact))
       end
     end
+  end
+end
\ No newline at end of file
diff --git a/acceptance/tests/facts/networking_facts.rb b/acceptance/tests/facts/networking_facts.rb
index da7dab4..6bddeb3 100644
--- a/acceptance/tests/facts/networking_facts.rb
+++ b/acceptance/tests/facts/networking_facts.rb
@@ -1,4 +1,5 @@
-test_name 'FACT-1361 - C59029 networking facts should be fully populated' do
+test_name 'C59029: networking facts should be fully populated' do
+  tag 'risk:high'

 #
 # This test is intended to ensure that networking facts resolves
diff --git a/acceptance/tests/facts/ruby.rb b/acceptance/tests/facts/ruby.rb
index 3d0ec6a..c1c3c6c 100644
--- a/acceptance/tests/facts/ruby.rb
+++ b/acceptance/tests/facts/ruby.rb
@@ -1,4 +1,5 @@
-test_name "The Ruby fact should resolve as expected in AIO"
+test_name "The Ruby fact should resolve as expected in AIO" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that the the ruby fact resolves
@@ -7,7 +8,7 @@ test_name "The Ruby fact should resolve as expected in AIO"

   skip_test "Ruby fact test is confined to AIO" if @options[:type] != 'aio'

-step "Ensure the Ruby fact resolves as expected"
+  step "Ensure the Ruby fact resolves as expected" do

     case agent['platform']
       when /windows/
@@ -44,3 +45,5 @@ expected_ruby = {
     expected_ruby.each do |fact, value|
       assert_match(value, fact_on(agent, fact))
     end
+  end
+end
diff --git a/acceptance/tests/facts/sles.rb b/acceptance/tests/facts/sles.rb
index 278f758..e0a1456 100644
--- a/acceptance/tests/facts/sles.rb
+++ b/acceptance/tests/facts/sles.rb
@@ -1,8 +1,9 @@
-test_name "Facts should resolve as expected in SLES 10, 11 and 12"
+test_name "Facts should resolve as expected on SLES" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that facts specific to an OS configuration
-# resolve as expected in SLES 10, 11 and 12.
+# resolve as expected on SLES.
 #
 # Facts tested: os, processors, networking, identity, kernel
 #
@@ -32,8 +33,7 @@ agents.each do |agent|
       processor_model_pattern = 'Intel\(R\)'
     end

-  step "Ensure the OS fact resolves as expected"
-
+    step "Ensure the OS fact resolves as expected" do
       expected_os = {
           'os.architecture'  => os_arch,
           'os.family'        => 'Suse',
@@ -47,9 +47,9 @@ agents.each do |agent|
       expected_os.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the Processors fact resolves with reasonable values"
-
+    step "Ensure the Processors fact resolves with reasonable values" do
       expected_processors = {
           'processors.count'         => /[1-9]/,
           'processors.physicalcount' => /[1-9]/,
@@ -60,8 +60,9 @@ agents.each do |agent|
       expected_processors.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the identity fact resolves as expected"
+    step "Ensure the identity fact resolves as expected" do
       expected_identity = {
           'identity.gid'        => '0',
           'identity.group'      => 'root',
@@ -73,8 +74,9 @@ agents.each do |agent|
       expected_identity.each do |fact, value|
         assert_equal(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the kernel fact resolves as expected"
+    step "Ensure the kernel fact resolves as expected" do
       if os_version == '10'
         kernel_version = '2.6'
       elsif os_version == '11'
@@ -94,3 +96,5 @@ agents.each do |agent|
         assert_match(value, fact_on(agent, fact))
       end
     end
+  end
+end
diff --git a/acceptance/tests/facts/solaris.rb b/acceptance/tests/facts/solaris.rb
index 45f1d1b..d418308 100644
--- a/acceptance/tests/facts/solaris.rb
+++ b/acceptance/tests/facts/solaris.rb
@@ -1,8 +1,9 @@
-test_name "Facts should resolve as expected in Solaris 10 and 11"
+test_name "C15496: Facts should resolve as expected on Solaris" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that facts specific to an OS configuration
-# resolve as expected in Solaris 10 and 11.
+# resolve as expected on Solaris
 #
 # Facts tested: os, processors, networking, identity, kernel
 #
@@ -34,7 +35,7 @@ agents.each do |agent|
         proc_isa        = /i386/
     end

-  step "Ensure the OS fact resolves as expected"
+    step "Ensure the OS fact resolves as expected" do
       expected_os = {
           'os.architecture'  => os_architecture,
           'os.family'        => 'Solaris',
@@ -48,8 +49,9 @@ agents.each do |agent|
       expected_os.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the Processors fact resolves with reasonable values"
+    step "Ensure the Processors fact resolves with reasonable values" do
       expected_processors = {
           'processors.count'         => /[1-9]/,
           'processors.physicalcount' => /[1-9]/,
@@ -60,8 +62,9 @@ agents.each do |agent|
       expected_processors.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the identity fact resolves as expected"
+    step "Ensure the identity fact resolves as expected" do
       expected_identity = {
           'identity.gid'        => '0',
           'identity.group'      => 'root',
@@ -73,8 +76,9 @@ agents.each do |agent|
       expected_identity.each do |fact, value|
         assert_equal(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the kernel fact resolves as expected"
+    step "Ensure the kernel fact resolves as expected" do
       expected_kernel = {
           'kernel'           => 'SunOS',
           'kernelrelease'    => "5.#{os_version}",
@@ -86,3 +90,5 @@ agents.each do |agent|
         assert_match(value, fact_on(agent, fact))
       end
     end
+  end
+end
diff --git a/acceptance/tests/facts/ubuntu.rb b/acceptance/tests/facts/ubuntu.rb
index e7342c1..fe19574 100644
--- a/acceptance/tests/facts/ubuntu.rb
+++ b/acceptance/tests/facts/ubuntu.rb
@@ -1,4 +1,5 @@
-test_name "Facts should resolve as expected in Ubuntu"
+test_name "C15288: Facts should resolve as expected on Ubuntu" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that facts specific to an OS configuration
@@ -54,7 +55,7 @@ agents.each do |agent|
       os_hardware = 'i686'
     end

-  step "Ensure the OS fact resolves as expected"
+    step "Ensure the OS fact resolves as expected" do
       expected_os = {
           'os.architecture'         => os_arch,
           'os.distro.codename'      => os_name,
@@ -72,8 +73,9 @@ agents.each do |agent|
       expected_os.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the Processors fact resolves with reasonable values"
+    step "Ensure the Processors fact resolves with reasonable values" do
       expected_processors = {
           'processors.count'         => /[1-9]/,
           'processors.physicalcount' => /[1-9]/,
@@ -84,8 +86,9 @@ agents.each do |agent|
       expected_processors.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the identity fact resolves as expected"
+    step "Ensure the identity fact resolves as expected" do
       expected_identity = {
           'identity.gid'        => '0',
           'identity.group'      => 'root',
@@ -97,8 +100,9 @@ agents.each do |agent|
       expected_identity.each do |fact, value|
         assert_equal(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the kernel fact resolves as expected"
+    step "Ensure the kernel fact resolves as expected" do
       expected_kernel = {
           'kernel'           => 'Linux',
           'kernelrelease'    => os_kernel,
@@ -110,3 +114,5 @@ agents.each do |agent|
         assert_match(value, fact_on(agent, fact))
       end
     end
+  end
+end
diff --git a/acceptance/tests/facts/windows.rb b/acceptance/tests/facts/windows.rb
index 2a8c1fd..20e138b 100644
--- a/acceptance/tests/facts/windows.rb
+++ b/acceptance/tests/facts/windows.rb
@@ -1,4 +1,5 @@
-test_name "Facts should resolve as expected on Windows platforms"
+test_name "C26851: Facts should resolve as expected on Windows platforms" do
+  tag 'risk:high'

 #
 # This test is intended to ensure that facts specific to an OS configuration
@@ -32,8 +33,7 @@ agents.each do |agent|
     end

-  step "Ensure the OS fact resolves as expected"
-
+    step "Ensure the OS fact resolves as expected" do
       expected_os = {
           'os.architecture'     => agent['platform'] =~ /64/ ? 'x64' : 'x86',
           'os.family'           => 'windows',
@@ -47,9 +47,9 @@ agents.each do |agent|
       expected_os.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the Processors fact resolves with reasonable values"
-
+    step "Ensure the Processors fact resolves with reasonable values" do
       expected_processors = {
           'processors.count'         => /[1-9]/,
           'processors.physicalcount' => /[1-9]/,
@@ -60,8 +60,9 @@ agents.each do |agent|
       expected_processors.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the identity fact resolves as expected"
+    step "Ensure the identity fact resolves as expected" do
       # Regular expression to validate the username from facter in the form of '<domain>\<username>'
       # Reference - https://msdn.microsoft.com/en-us/library/bb726984.aspx
       # - The domain name can be any character or empty
@@ -75,9 +76,9 @@ agents.each do |agent|
       expected_identity.each do |fact, value|
         assert_match(value, fact_on(agent, fact))
       end
+    end

-  step "Ensure the kernel fact resolves as expected"
-
+    step "Ensure the kernel fact resolves as expected" do
       expected_kernel = {
           'kernel'           => 'windows',
           'kernelrelease'    => kernel_version,
@@ -89,3 +90,5 @@ agents.each do |agent|
         assert_match(value, fact_on(agent, fact))
       end
     end
+  end
+end


fixed brownian_tree_times.py

We forgot to update the VBT timing benchmark when we changed Brownian return types, so here's a quick fix.

LGTM! Thank you for the fix.


bug(functional tests): API key management tests are flakey due to race condition

Describe the bug
In tests/functional/backend/corpora/test_api_key.py, line 23 returns 200 instead of 404. This is because multiple instance of the functional tests are running and they all use the same auth0 test user.
To Reproduce
It is difficult to reproduce but it happens often enough to be a problem. Run functional tests in multiple threads and it will happen eventually. The specific test suite is TestApiKey.
Expected behavior
Tests running in separated rdev environment should not affect each other. Since all of the rdev environments are using the same auth0 test user something need to be changes to either share it, or eliminated the needs to access the shared resource.
Environment

rdev functional tests

Possible Solutions:

Add a GHA concurrency lock for rdev functional tests.
+(Quick and easy to implement)
-(will slow down development)
Mock out all of the auth0 calls for functional tests. -
(Significant test refactor.)
-(will need additional testing for specifically the auth0 integration)
generate a new user per functional test.
-(more reliance on auth0)
-(will require some permission changes to auth0 which may not work since single-cell-infra is broken when it comes to updating auth0.)
+(increase isolation of tests),
Skip the TestApiKey in rdev.
-(this means less test coverage for rdev. Future development of this area of code will be more difficult.)
+(less code coverage for rdev environments for this feature.)

Solution 4 with appropriate comments that tells the user to uncomment this code when working on the feature is sufficient. A comment should live near the implementation as well as the tests so the developer has a higher likelyhood of remembering to uncomment the test.

Closing, since @Bento007 noted that solution 4 is sufficient for now. We'll reopen/revisit if necessary.


[release-v1.8] Helloworld image running with non root user

Cherry pick of https://github.com/openshift-knative/client/pull/104, except that the SERVERLESS_BRANCH in openshift/e2e-commons.sh remains "main".

/approve
/lgtm


MAISTRA-2613 Update to latest Istio 1.9.8

Initial updates for 1.9.8

/test unit

@jwendell Test failures are now fixed. PTAL.
I think there are only a few changes in charts, so the operator side will be quick to update.

LGTM
Do we want to merge this via a merge-commit so the changes are nicely separated from the maistra commits?

Do we want to merge this via a merge-commit so the changes are nicely separated from the maistra commits?

@luksa What do you mean? I already added the not squash label. Isn't it enough?

Even with don't squash, we end up with a linear history. As much as I prefer linear history for day-to-day stuff, I think that in this particular case a merge commit would be better. This is what we'd end up with:
       U1---U2---U3
     /              \
1.9.5---M1--M2--M3---X  maistra-2.1

where U1..U3 are upstream commits (from 1.9.5. to 1.9.8), M1-M3 are the existing Maistra commits that we added on top of 1.9.5, and X is the merge commit that merges the two linear histories.
This will leave the resulting history slightly better organized, as it would keep our changes separate from those upstream.

Ah, got it. We don't use merge strategy by default. Let me look if there's an option for that

https://github.com/maistra/test-infra/pull/172

if we want to use merge strategy here, let's keep the required changes on top of the upstream commits to a single commit - we currently have 6 additional commits in here

if we want to use merge strategy here, let's keep the required changes on top of the upstream commits to a single commit - we currently have 6 additional commits in here

Thanks, I have squashed them into a single commit.

/test unit

/test unit

/test integration

Integration tests are failing due to timeout. It's almost taking more than 1hr to run the integration test.
traffic.go:150: call failed from TestRunner to https://<IP_ADDRESS>:443 (using https):
timeout while waiting (last error: no responses received)

/test integration


backend install failure at windows op. system

npm run init-db have error at windows op system because of line below at vue-crud-x >backend >package.json line 7
"init-db": "rm -f dev.sqlite3&&npx knex migrate:latest --env development&&npx knex seed:run --env development",
windows dont have "rm" windows users have to change it to "del".
better to mention this to the installation notes

Hi you are correct. Unless you install Git and incorporate bash.
Let me see if I can make it work across environments... if not I will see if I can make a note.

removed OS dependent code in v0.2.1


feat(openchallenges): increase headline char limit to 120

Fixes #2320
Changelog
Backend

increase headline varchar limit from 80 to 120 in SQL table creation
update maxLength to 120 for ChallengeHeadline API spec
update headlines in CSV dump file

Frontend

decrease height of banner SVG's viewbox
decrease banner's height on challenge card - this will allow the card to remain at its current size
clamp headline at 3 lines (instead of 2)

Preview
API docs

Before

After

Feedback from the stand-up:

New design may have too much text
New banner size may not be easy to work with in the future
@tschaffter will try to generate new headlines up to 80 characters (whereas our current prompt is 10 words or less)

Closing PR now.


[BUG] Static image API does not work with fill-extrusion layer

Bug Description
just found static api does not produce image for fill-extrusion layer. native does not support??
Bug Reproduction

style json
https://geohub.data.undp.org/api/style/274.json

api
https://staticimage.undpgeohub.org/api/style/static/auto/300x200.png?url=https%3A%2F%2Fgeohub.data.undp.org%2Fapi%2Fstyle%2F274.json&ratio=1

Bug Impact
No response
Bug Screenshots

Bug References
No response
Bug System Information

OS: [e.g. Windows 10]
Browser: [e.g. Google Chrome, Firefox]

┆Issue is synchronized with this Wrike task by Unito

looks working now

I don't know why. maybe because of CDN cache?? I purged CDN cache..


Re-revert "Consistent installation title"

What kind of changes does this PR include?

Minor content fixes (broken links, typos, etc.)

Description
My second shot at this PR, for context see #2262 and #2265
The titles now are:

Installation (Automatic CLI)
Installation (Manual Setup)

I am using the tab names, so it should still be consistent, they also have around the same breakpoint so the line amount should match on most screen sizes
cc @delucis, let me know if this works for you

I like it!
Will make the change in a few hrs

@Tc-001 - just pinging for freshness! Make Chris' changes, and it's good to merge, I think!

They are a bit too different for the effect, but the following works:

Install Astro with manual setup
Install Astro with the Automatic CLI

What does it look like if you compare:

Install Astro Wizard

Install Astro manually

I actually like how Install Auto manually looks as a title. So, can we tighten up the Auto? Other suggestions for phrasing?

a
b
c

"Install Astro automatically" just barely is smaller than the word wrap point, but unsure how it looks on other browsers
Wizard works but I think the wording is a bit weird? Will see if I can come up with anything

Install Astro via Wizard  ??
Install Astro with Wizard ??

Maybe? Still a bit strange for my taste, but they do fit!

I have found some, but needing them to be around the same length is a bit limiting, I don't think there is a perfect one

For me personally this makes the most sense, as it is a line and a bit in length in the largest size
But maybe it would be better to remove the tabs and make them distinctively 2 different pages? They could link to each other with something like:

"The wizard will now run some commands, if you want to know what they are or run them yourself, click here. "

I think I will sleep on it, is is getting quite late
Also will probably move to discord, a lot easier to paste screenshots there
Best of lucks to your projects!

Is there any reason to keep the automatic in "automatic cli"?
I think "with the cli" is simpler

It could work and fits in one line!
Although it wraps a lot sooner so the effect would break if the browser is not maximized, but it would do it's job ~80% of the time

Coming back to this.... 😅
What about some distinction more like:
"Automatic Setup" / "Install Manually"

They both involve the CLI, just in one case you're installing and running the wizard, and in the other, you're just installing Astro. So, I don't think using "CLI" for one vs the other is exactly correct?
It's not the "installing" that's automatic, it's the SETUP with all the dependencies, eh?

OK! So we have a different fix for this issue.... we're going to tackle this in #2390 and kill off the fake tabs entirely!  :hocho:
This is the only time we use tabs to "fake" page navigation, and it's a pattern that is clearly problematic and that we shouldn't enable. Plus, having two separate pages allows us to customize the top of the page so we can still nudge people to create astro.
Since the whole reason for this pattern was to avoid duplicating content, but now we actually want that content to be different anyway, I'm closing this issue in favour of the solution to making two entirely different pages. There's no need for this content to be this closely aligned anymore.


NIFI-3418 Add records-per-transaction property to putHiveStreaming pr…

Reviewing...

+1 LGTM, ran full Maven build (with CheckStyle, made a minor edit) and tested on a running NiFi instance connected to a HDP Sandbox.  Thank you for your contribution! Merging to master


no info regarding versions of WAF

Hi there,
Where can i find info regarding the prerequisites ?
I'm using WAF v1 and there is no Bot Ruleset....
br
Manfred

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

ID: eecb8e35-6b5f-ed27-879d-9411d062cf6c
Version Independent ID: fef8a431-ad66-c0f2-aa82-fbb61c8205b1
Content: Configure bot protection for Azure Web Application Firewall (WAF)
Content Source: articles/web-application-firewall/ag/bot-protection.md
Service: web-application-firewall
GitHub Login: @vhorne
Microsoft Alias: victorh

@manfredczujan Thank you for your query . We will investigate and update the thread.

@vhorne Can you please look into this? I have setup a WAF v1 App GW and do not see this option either, See below:

You can select the Bot rule set when you create the WAF policy:

#please-close


Adding of Netbela to the list of Hosting providers

Hi there,
The company Netbela (hosting company from the Netherlands) supports the use of this plugin, Could you perhaps add the following to the 'Support for Geyser' list? Link: https://netbela.nl/store/minecraft
Name: Netbela
Description: Install Geyser as a plugin with the dedicated Plugin installer.
Use the same port as your Java server for the Bedrock address and port in your config and connect with that specific address and port.

Hi there,
You can easily add the provider in the providers list "https://github.com/GeyserMC/GeyserWiki/blob/master/_data/providers.json" you can use the default template as you need to set bedrock port same as the java port(or clone remote port).
You can pr into this patch, otherwise I will close this pr as invalid.
Thanks.

Hi there,
You can easily add the provider in the providers list "https://github.com/GeyserMC/GeyserWiki/blob/master/_data/providers.json" you can use the default template as you need to set bedrock port same as the java port(or clone remote port).
You can pr into this patch, otherwise I will close this pr as invalid.
Thanks.

@Jens-Co  Thanks, I have updated the providers.json file. Could you perhaps check and then merge?


Where I can find the dataset ?

Where I can find the dataset ?

you can find them here
https://cloud.ilabt.imec.be/index.php/s/eRkdk6NnJZNL5XG


[Enhancement]: Want to add background Image for the homepage related to the game

Do you want to have the enhancement of existing game ? 😀 Describe yourself..
Game enhancement
want to add a background image in the home page

Describe the solution you'd like
Solution steps
Find a suitable background image and add to the css file
Select program in which you are contributing
No response
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

@aindrelasaha Have you any design

yes sir I have @Durgesh4993


Keycastr isnt showing up on accesibility list

HLP

It appears you're on an older version of macOS, though you haven't provided any details.
In this case, you need to add it yourself via the trusty + button.


User-Management with Third-Party Integration

User-Management with Third-Party Integration (e.g. CloudFoundry)
In addition to the very basic, CLI based user management approach OpenWhisk supports out-of-the-box, we want to support integrations with third-party systems, that support a richer user-management approach.
Problem statement
We need a generic way of integrating with third-party services to delegate user authentication and authorisation without impacting our own performance too much or being tightly coupled to the third-party service's uptime.
Under the assumption that "Namespace Keys" (#1107) are already implemented, a third-party service needs to provide "only" the subject record to be stored in the OpenWhisk subjects database. After that, we need to keep this record in sync with what the third-party service thinks the authentication and authorisation details are for that subject. Cases to consider include:

Creating a new user
Granting a user access to a new namespace
Removing a user's access to a certain namespace
Removing a user

Proposed solution
Scenarios
1. Creating a new user
To create a new user, that user exchanges valid access credentials to the third-party service with credentials in OpenWhisk. This means: The user passes valid credentials to OpenWhisk which it then uses to get information about the user from the third-party-service. The information needed are username and namespaces that user is able to access. For CloudFoundry integration this means: The users passes in a valid accessToken to OpenWhisk, which then talks to CloudFoundry to get your developer_guid (username) and Organization/Space pairs (namespaces).
OpenWhisk now takes this username, creates a subject record for it and issues a Namespace key for each namespace the user is able to access.
The resulting subject record is then returned to the user, giving him access to his initial Namespace keys.
That endpoint to trade the credentials in could be /api/v2/authenticate.
Technically the flow will then be:

Trade in valid credentials
POST /api/v2/authenticate
{
  "accessToken": "$myCloudFoundryAccessToken"
}

OpenWhisk validates the credentials and gets user information
GET ${CF_URL}/userinfo
Authorization: bearer $myCloudFoundryAccessToken

Response:
{
  "user_id": $the-users-guid
  ...
}

OpenWhisk gets valid namespaces
GET ${CF_URL}/v2/spaces
Authorization: bearer $cloudFoundryClientToken

Response:
[ spaces ... ]

GET ${CF_URL}/v2/organizations
Authorization: bearer $cloudFoundryClientToken

Response:
[ orgs ... ]

OpenWhisk creates a subject record and send it back to the user
PUT ${COUCHDB}/subjects/$the-users-guid
{
  "id": $the-users-guid,
  "namespaces": [
    {
      "name": $ORG1_$SPACE1,
      "uuid": $space1-guid,
      "key": "randomlyGeneratedSecret"
    },
    {
      "name": $ORG1_$SPACE2,
      "uuid": $space2-guid,
      "key": "randomlyGeneratedSecret2"
    }
  ]
}

2. Granting a user access to a new namespace
As noted in "Namespace Keys" (#1107) a user changes his namespace by listing the namespace he has access to using a key he already has (obtained by the call outlined above for example).
When the user is assigned to a new namespace (either by creating one or given access to an existing one in the third-party service) he'll find out about this by calling wsk namespace list (or the REST API equivalent). OpenWhisk can hook into this and issue an update request against the third-party service, essentially repeating steps 3 and 4 from above and synchronising the stored set of namespaces with the namespaces it got from the third party service.
3. Removing a user's access to a certain namespace
To remove access to a certain namespace (read: remove the Namespace key for that namespace from the subject) we cannot rely on the user calling wsk namespace list to trigger an update.
Instead we schedule an update request (see steps 3 and 4 above) every x calls a user makes to constantly verify that active users are still allowed to use the system in the bounds they are operating in. This has the caveat of being eventually consistent as the third-party system might be slow. We don't block incoming requests until the update event finishes and refreshes the subject record in the database. If this call results in a namespace being removed, the key to access that namespace will no longer work after the update being completed.
4. Removing a user
If the third-party service returns "Not Found" in the update process outlined above, the user can be removed from our database.
Cache considerations
As we strive for minimum latency on invocations, caches must be in place to keep us from asking external systems too much and relying on their latency.

subjects database: The code outlined above will be living in the Controller itself, which is the service that we really want to cache the subjects database in. We have full control over local caches there and the update mechanisms should invalidate when necessary.
calls against the third-party system: Those calls should at least be throttled. The cache duration at this place effectively decides how long eventual consistency is going to take to catch up with the third-party system.

What if the third-party system is offline?
In order to sustain third-party outages, we propose to continue operating with the data that is already in our system.
The update mechanism will not touch the database at all if the third-party system is offline. One could imagine a threshold of X minutes after which OpenWhisk stops operating because it cannot safely say that users are still allowed to access the system.
Things to watch

CF API is paginated. Deal with that!

Open questions:

Will we continue to prepend the entity records with the display name of the namespace (ORG_SPACE/actionName vs. spaceGuid/actionName)?

^^ I would state that in the design each namespace does have a name and id (uuid) field.
This is because we need a human-readable version of the namespace for UI + CLI.
The CF integration service then just happens to use ORG_SPACE as a display name and spaceGuid as id.
On question 2. Internally we should operate only with the uid of the namespace. The display name can be lazily updated whenever we do synchronize with the backend on the actual namespace list.
This of course makes the assumption that a space guid does not change when the space name changes.

I think we pretty much agreed on the first part (as shown in the JSON examples above, the fields are considered to be there).
The second part though will be a semantic change, as we currently always operate with the human-readable way. Also note that we still do not have a central notion of a "namespace" as in: Update one record to update the display name. That might become necessary, maybe it doesn't .
Technically we need a two way lookup:

uuid to namespace: To be able to authenticate the user
namespace human-readable-name to namespace: To be able to resolve human-readable-name to uuid to be able to fetch entities (given they are prefixed with uuid instead of human-readable-name)

The latter is problematic currently (maybe not, read below), because there are N subject entries resolving namespace human-readable-name to namespace. We could potentially use only the entry of the current subject (making it (human-readable-name, subject) to uuid) which kinda defeats that problem. But then we strike eventual-consistency because the current subject record might not have been updated with the information from CF (see the update mechanism outlined above).
After all, having N entries resolving namespace human-readable-name to namespace might actually be not too problematic as that would only induce, that we have a timeframe where two different names are resolved to the same uuid (this timeframe is the time it takes to update every single occurrence of the old name in the system to the new name in the system) which might be indefinite. Again this could be completely irrelevant as the records with the "old" name are unused anyway (as stated by the update mechanism outlined above) hence we could ignore/accept this fact.
Having written this down, it appeals to me that "simply" having a view from namespace human-readable-name to namespace is sufficient as it it embraces the eventual-consistency introduced by the lazy update mechanism anyway. It states, that the renamed namespace will become available in OpenWhisk as soon as the first subject record is updated in our database which strikes me as more useful than to introduce that inconsistency for each subject record on its own.
My proposal would then be:

Use namespaceUuid/actionName internally, but the human-readable versions on the API side, resolve those internally using a view from human-readable name to namespace (thus uuid).
Renaming as stated by @domdom82 only affects the display name and should be handled as an update rather than a delete/recreate. The space guid does not change on a rename.

Not applicable anymore.


Add Recipe for Using Tailwind to Style Rendered Markdown

Description (required)
This PR aims to add an official recipe to the Astro documentation which describes how you can use Tailwind's Typography plugin to style rendered Markdown, such as content collection content.
New Recipe: /en/recipes/tailwind-rendered-markdown/
Related issues & labels (optional)

Closes #4367
Suggested label: add new content, recipe

Looking forward to digging into this one over the weekend!!  :partying_face:

I think we should follow the ESM syntax for the tailwind.config file

@VoxelMC Thank you for this great recipe! It is well thought-out and well-written.
I took an editing pass, see what you think! We can work from it and make any changes in this state.
Some notable choices:

I removed the external StackBlitz link because that's not very future-proof. The recipe could change here (as it already did!) or anything could happen to that repo...
I changed the kind of handwavy "make your markdown shine!" to actually describe what the feature description is: being able to use Tailwind's utility classes on your Markdown. This is also better if people are searching the docs as it gives very specific keywords that they can find this recipe from.
I moved the section on element modifiers to the bottom, so it's not in the middle of instructions (since it's not a thing to do) and linked to it. Honestly, in some moods, I would have just linked externally and removed that section entirely saying it's not our job to document how Tailwind works, and they already have documentation on this topic, but it was short, and well-written so I kept it. 😄
I was way more opinionated throughout (e.g. instead of if you're using Content collections... Nope! You use content collections now!) so that the instructions and examples can be cleaner, made with certain assumptions. People are free to modify at will!
Some of my instructions were a little more explicit (referencing actual elements etc.) to draw the attention to the key points of the code samples that were doing the heavy lifting to get our desired affect.

I know that list looks like a lot, and some very specific minor changes, but when it was this good to begin with, it's easy to spot the areas that just need that little tweak to make your recipe shine! 🌟

@VoxelMC Thank you for this great recipe! It is well thought-out and well-written.
I took an editing pass, see what you think! We can work from it and make any changes in this state.
Some notable choices:

I removed the external StackBlitz link because that's not very future-proof. The recipe could change here (as it already did!) or anything could happen to that repo...
I changed the kind of handwavy "make your markdown shine!" to actually describe what the feature description is: being able to use Tailwind's utility classes on your Markdown. This is also better if people are searching the docs as it gives very specific keywords that they can find this recipe from.
I moved the section on element modifiers to the bottom, so it's not in the middle of instructions (since it's not a thing to do) and linked to it. Honestly, in some moods, I would have just linked externally and removed that section entirely saying it's not our job to document how Tailwind works, and they already have documentation on this topic, but it was short, and well-written so I kept it. 😄
I was way more opinionated throughout (e.g. instead of if you're using Content collections... Nope! You use content collections now!) so that the instructions and examples can be cleaner, made with certain assumptions. People are free to modify at will!
Some of my instructions were a little more explicit (referencing actual elements etc.) to draw the attention to the key points of the code samples that were doing the heavy lifting to get our desired affect.

I know that list looks like a lot, and some very specific minor changes, but when it was this good to begin with, it's easy to spot the areas that just need that little tweak to make your recipe shine! 🌟

Thank you for your edits, inputs, and inspiration! I will do a readthrough and double check that all of the code works, make some edits, and let you know when it's ready for another look.
Also, I will take the advice to any future recipes I make! It all makes total sense, in hindsight :P


Manager application process flow - Grade questions

Working fine
Will have to test end to end flow once

Tested, working smoothly. Thanks!


Is this Project Dead or Unmaintained? Which are the alternatives?

Asking a Question?
I was trying to update a project that uses this library, when I noticed some errors already reported in the Issues, some of them even tag the author of this project and no answer whatsoever.
So I wonder if we could considerate this project could be considered dead since the last release was on December 2020, and it has some "recent" commits from April 2022, but no official release.
If this project is not longer supported I propose to put that on the Readme to alert new developers and avoid to use it on new projects, and also recommend some alternatives if they are.

Hi
The dev of this Lib recommended using this alternative instead of react-virtualized
https://github.com/bvaughn/react-window

Don't use this library unless other libraries can't provide what you need.
react-virtuoso
@tanstack/react-query


[Linux] Crash with any text input field

Every time I try to get the focus a text field to type something, I crash in ImGui function ImGui::InputTextEx.
I easily reproduce it with the Demo Window and using the Widgets > Text Input > Resize Callstack example.
LogCore: === Critical error: ===
Unhandled Exception: SIGSEGV: invalid attempt to read memory at address 0x0000000003b37200

LogCore: Fatal error!

libUE4Editor-ImGui.so!ImGui::InputTextEx(char const*, char const*, char*, int, ImVec2 const&, int, int (*)(ImGuiInputTextCallbackData*), void*) [/mnt/dev/Perforce/Exedre/Plugins/ImGui/Source/ThirdParty/ImGuiLibrary/Private/imgui_widgets.cpp:3689]
libUE4Editor-ImGui.so!ShowDemoWindowWidgets() [/mnt/dev/Perforce/Exedre/Plugins/ImGui/Source/ThirdParty/ImGuiLibrary/Private/imgui_demo.cpp:1075]
libUE4Editor-ImGui.so!ImGui::ShowDemoWindow(bool*) [/mnt/dev/Perforce/Exedre/Plugins/ImGui/Source/ThirdParty/ImGuiLibrary/Private/imgui_demo.cpp:428]
libUE4Editor-Exedre.so!UExedreDebugUI::RenderMenu(float) [/mnt/dev/Perforce/Exedre/Source/Exedre/GUI/ExedreDebugUI.cpp:327]
libUE4Editor-Exedre.so!AExedreWidgetManager::UpdateAndRenderMenus(float) [/mnt/dev/Perforce/Exedre/Source/Exedre/GUI/ExedreWidgetManager_Render.cpp:160]
libUE4Editor-Exedre.so!AExedreWidgetManager::ManualTick(float) [/mnt/dev/Perforce/Exedre/Source/Exedre/GUI/ExedreWidgetManager_Base.cpp:287]
libUE4Editor-Engine.so!AHUD::PostRender() [/mnt/dev/UE4/Engine/UnrealEngine_4-25-2/Engine/Source/Runtime/Engine/Private/HUD.cpp:172]
libUE4Editor-Engine.so!UGameViewportClient::Draw(FViewport*, FCanvas*) [/mnt/dev/UE4/Engine/UnrealEngine_4-25-2/Engine/Source/Runtime/Engine/Private/GameViewportClient.cpp:1620]
libUE4Editor-Engine.so!FViewport::Draw(bool) [/mnt/dev/UE4/Engine/UnrealEngine_4-25-2/Engine/Source/Runtime/Engine/Private/UnrealClient.cpp:1541]
libUE4Editor-Engine.so!UGameEngine::RedrawViewports(bool) [/mnt/dev/UE4/Engine/UnrealEngine_4-25-2/Engine/Source/Runtime/Engine/Private/GameEngine.cpp:682]
libUE4Editor-Engine.so!UGameEngine::Tick(float, bool) [/mnt/dev/UE4/Engine/UnrealEngine_4-25-2/Engine/Source/Runtime/Engine/Private/GameEngine.cpp:1806]
UE4Editor-Cmd!FEngineLoop::Tick() [/mnt/dev/UE4/Engine/UnrealEngine_4-25-2/Engine/Source/Runtime/Launch/Private/LaunchEngineLoop.cpp:4844]
UE4Editor-Cmd!GuardedMain(char16_t const*) [/mnt/dev/UE4/Engine/UnrealEngine_4-25-2/Engine/Source/Runtime/Launch/Private/Launch.cpp:171]
libUE4Editor-UnixCommonStartup.so!CommonUnixMain(int, char**, int (*)(char16_t const*), void (*)()) [/mnt/dev/UE4/Engine/UnrealEngine_4-25-2/Engine/Source/Runtime/Unix/UnixCommonStartup/Private/UnixCommonStartup.cpp:264]
libc.so.6!__libc_start_main(+0xf1)
UE4Editor-Cmd!_start()

Looks like it's crashing on this line:
if (IsKeyPressedMap(ImGuiKey_LeftArrow))                        { state->OnKeyPressed((is_startend_key_down ? STB_TEXTEDIT_K_LINESTART : is_wordmove_key_down ? STB_TEXTEDIT_K_WORDLEFT : STB_TEXTEDIT_K_LEFT) | k_mask); }
I gave a try at the standalone ImGui versions 1.78 and 1.74 (via the example example_sdl_opengl2) and it's not crashing. Any idea what that might be ?
I'm using the following by the way :
	FImGuiModule::Get().GetProperties().SetInputEnabled( true );
	FImGuiModule::Get().GetProperties().SetKeyboardInputShared( true );

Sorry, I cannot help you much with that because this is something that happens inside of the ImGui demo and on the Linux platform where I cannot run it. This call stack alone doesn't tell that much and on the Windows, I don't have that crash. The fact that it works fine outside of the UE might have something to do with the type of TCHAR that UE uses on Linux, or not... not sure.
Is the input sharing essential? Although I don't think it should be.
And on a side note, you know that there are commands to toggle those properties and that input sharing can be configured from settings?

Using SetKeyboardInputShared( false) didn't help.  So I ran my project in debug this time which gave me a more precise callstack:
#0  0x00007fff5beb2df1 in ImGui::IsKeyPressed (user_key_index=1073741904, repeat=true) at /mnt/dev/Perforce/Exedre/Plugins/ImGui/Source/ThirdParty/ImGuiLibrary/Private/imgui.cpp:4263
#1  0x00007fff5bf3494f in ImGui::IsKeyPressedMap (key=1, repeat=true) at /mnt/dev/Perforce/Exedre/Plugins/ImGui/Source/ThirdParty/ImGuiLibrary/Private/imgui_internal.h:1694
#2  0x00007fff5bef5c80 in ImGui::InputTextEx (label=0x7fff5be451b7 "##MyStr", hint=0x0, buf=0x2f5fdf0 "", buf_size=1, size_arg=..., flags=1310720,
    callback=0x7fff5bf17480 <ShowDemoWindowWidgets()::Funcs::MyResizeCallback(ImGuiInputTextCallbackData*)>, callback_user_data=0x7fff5bfa78c0 <ShowDemoWindowWidgets()::my_str>)

I don't know yet why, but when IsKeypresse() is called, user_key_index has a value of<PHONE_NUMBER> which seems way too big for an array index, leading to the crash in the function below (at  const float t = g.IO.KeysDownDuration[user_key_index];). I'm also not sure why the assert in the line just above doesn't trigger :
bool ImGui::IsKeyPressed(int user_key_index, bool repeat)
{
    ImGuiContext& g = *GImGui;
    if (user_key_index < 0)
        return false;
    IM_ASSERT(user_key_index >= 0 && user_key_index < IM_ARRAYSIZE(g.IO.KeysDown));
    const float t = g.IO.KeysDownDuration[user_key_index];
    if (t == 0.0f)
        return true;
    if (repeat && t > g.IO.KeyRepeatDelay)
        return GetKeyPressedAmount(user_key_index, g.IO.KeyRepeatDelay, g.IO.KeyRepeatRate) > 0;
    return false;
}

I will continue to investigate, but if you have any suggestion I'm all ears.

user_key_index = key_index  where key_index = g.IO.KeyMap[key] and key = 1 in that instance.
So, it looks like the IO.KeyMap may be bad. This map is copied to IO after context creation: ImGuiInterops::SetUnrealKeyMap(IO) in the ImGuiContextProxy.cpp, line 101.
The void ImGuiInterops::SetUnrealKeyMap(ImGuiIO&) function is declared in the ImGuiInteroperability.h, line 37 and defined in the ImGuiInteroperability.cpp, line 88.
It creates a local variable static const FUnrealToImGuiMapping Mapping with a map that is initialised using the uint32 GetKeyIndex(const FKey&) function. So I would check the state of Mapping and what is actually copied to the ImGuiIO. If the mapping is wrong then perhaps the uint32 GetKeyIndex(const FKey&) doesn't work correctly on Linux.

Did you find out what is the state of the Mapping.KeyMap or IO.KeyMap?

Hasn't the chance to look into it further yet, quite a bit busy last week unfortunately. I will try to look into it again soon.

+1 on this. I hit this in our application, and the next two levels in the callstack above are actually IsKeyPressedMap and IsKeyPressed due to this line in InputTextEx:
if (IsKeyPressedMap(ImGuiKey_LeftArrow)) { state->OnKeyPressed((is_startend_key_down ? STB_TEXTEDIT_K_LINESTART : is_wordmove_key_down ? STB_TEXTEDIT_K_WORDLEFT : STB_TEXTEDIT_K_LEFT) | k_mask); }

I did dig into the root cause. It's the values of the keys at the platform-specific level and their use as an index as noted by @Froyok . On Linux, the underlying implementation is using SDL, and not so coincidentally,<PHONE_NUMBER> is 0x40000050, which maps to SDLK_LEFT. Here's a copy/paste from an internal Jira where I dumped my analysis:
"Ok, yeah, this is a Linux-specific issue. That<PHONE_NUMBER> value is 0x40000050, which maps to SDLK_LEFT (arrow key) in the SDL library (which is what UE4 uses for its underlying Linux implementation), as can be seen here: https://wiki.libsdl.org/SDLKeycodeLookup
They are using that value as a lookup into an array of size 512, so this is going way past valid memory of the array. On Windows, that left arrow key index value is 37, so a safe value.

37 is VK_LEFT: https://docs.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes .. mapped in UE4 here for EKeys::Left: https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Source/Runtime/InputCore/Private/Windows/WindowsPlatformInput.cpp#L34 : ADDKEYMAP( VK_LEFT, TEXT("Left") );.

0x40000050, on Linux, mapped here as SDKL_LEFT: https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Source/Runtime/InputCore/Private/Linux/LinuxPlatformInput.cpp#L31 : ADDKEYMAP(SDLK_LEFT, TEXT("Left"));

In the ImGui code: KeyMap[ImGuiKey_LeftArrow] = GetKeyIndex(EKeys::Left);
So, this all aligns to end up in the crash we are seeing."

Looking more into this, a possible quick-ish fix, and maybe a reasonable fix to future-proof any other platforms that might have crazy values for some of the keys, would be to make KeysDown, KeysDuration, and KeysDurationPrev a std::map (or ImMap, if one were to be implemented, maybe a super-minimal implementation for adding/indexing/iterating; first pass could just be 'typedef ImMap std::map', though), instead of the [512] array they currently are.. most of the existing code may work as-is (the stuff that adds keys and indexes them) but some adjustments needed such as looping through them.

Hey @jbuckags. Thank you for looking into this and for your analysis. It helps a lot. It seems like potentially a really nasty bug.
So, the very fast fix for Linux would be to transform the current index to something like this: (Index <= OxFF) ? Index : OxFF + Index % OxFF. Transforming the SDL key-codes this way should be conflicts-free and should solve the problem on Linux. It should also not require any other changes than that.
But I agree that a safer solution for any platform will be to provide a custom mapping. As much as I don't like making another map I also thought about going this direction. For consistency I'd go with the TMap as I adopted a convention that I'll stick to Unreal data structures whenever possible. The benefit of custom mapping might be that I can make it more compact.

Most of the existing code may work as-is (the stuff that adds keys and indexes them) but some adjustments would be needed such as looping through them.

Not sure whether I got that last part. What I would think is that I would still produce an index, but instead of using raw key-codes I'd do a mapping from that to something more compact. Since ImGui only is interested with ImGuiKey_ keys, I would map only those, which would the mapping small enough.

If "Index % 0xff" (or & 0xff) doesn't end up conflicting with others keys' codes, then yeah, we should be good there.
As for the bit that I meant about looping through.. if a TMap (or whatever) were to be used, there are current places where there is an actual array-based loop going through all the elements of the array and would need to be changed to map-based begin()/end() kind of construct.

OMG, yes you are right '&'. I've rushed my answer and didn't check it properly. I've corrected my previous post.

there are current places where there is an actual array-based loop going through all the elements of the array

Sorry, there are some old enough bits so I might not remember. Do you mean array-based loops in plugin or actual imgui code from ThisrParty folder?

Hah, well, '& 0xff' is equivalent to '% 0x100', so you were close. ;)
Doing a quick search on the codebase for 'KeysDown' (not-whole-word search):
ImGui\Private\ImGuiInputState.cpp(24):	if (KeyIndex < Utilities::GetArraySize(KeysDown))
ImGui\Private\ImGuiInputState.cpp(26):		if (KeysDown[KeyIndex] != bIsDown)
ImGui\Private\ImGuiInputState.cpp(28):			KeysDown[KeyIndex] = bIsDown;
ImGui\Private\ImGuiInputState.cpp(66):	fill(KeysDown, &KeysDown[Utilities::GetArraySize(KeysDown)], false);
ImGui\Private\ImGuiInputState.h(46):	const FKeysArray& GetKeys() const { return KeysDown; }
ImGui\Private\ImGuiInputState.h(225):	FKeysArray KeysDown;
ImGui\Private\ImGuiInteroperability.cpp(295):			Copy(InputState.GetKeys(), IO.KeysDown, InputState.GetKeysUpdateRange());
ImGui\Private\ImGuiInteroperability.h(25):		using FKeysArray = decltype(ImGuiIO::KeysDown);
ThirdParty\ImGuiLibrary\Docs\CHANGELOG.txt(1048):  - Set io.ConfigFlags |= ImGuiConfigFlags_NavEnableKeyboard to enable. NewFrame() will automatically fill io.NavInputs[] based on your io.KeysDown[] + io.KeyMap[] arrays.
ThirdParty\ImGuiLibrary\Include\imgui.h(674):    IMGUI_API bool          IsKeyDown(int user_key_index);                                      // is key being held. == io.KeysDown[user_key_index]. note that imgui doesn't know the semantic of each entry of io.KeysDown[].
ThirdParty\ImGuiLibrary\Include\imgui.h(944):// User fill ImGuiIO.KeyMap[] array with indices into the ImGuiIO.KeysDown[512] array
ThirdParty\ImGuiLibrary\Include\imgui.h(973):// Keyboard: Set io.ConfigFlags |= ImGuiConfigFlags_NavEnableKeyboard to enable. NewFrame() will automatically fill io.NavInputs[] based on your io.KeysDown[] + io.KeyMap[] arrays.
ThirdParty\ImGuiLibrary\Include\imgui.h(997):    // Keyboard behavior that have no corresponding gamepad mapping (e.g. CTRL+TAB) will be directly reading from io.KeysDown[] instead of io.NavInputs[].
ThirdParty\ImGuiLibrary\Include\imgui.h(1011):    ImGuiConfigFlags_NavEnableKeyboard      = 1 << 0,   // Master keyboard navigation enable flag. NewFrame() will automatically fill io.NavInputs[] based on io.KeysDown[].
ThirdParty\ImGuiLibrary\Include\imgui.h(1366):    int         KeyMap[ImGuiKey_COUNT];         //           // Map of indices into the KeysDown[512] entries array which represent your "native" keyboard state.
ThirdParty\ImGuiLibrary\Include\imgui.h(1429):    bool        KeysDown[512];                  // Keyboard keys that are pressed (ideally left in the "native" order your engine has access to keyboard keys, so you can use your own defines/enums for keys).
ThirdParty\ImGuiLibrary\Include\imgui.h(1472):    float       KeysDownDuration[512];          // Duration the keyboard key has been down (0.0f == just pressed)
ThirdParty\ImGuiLibrary\Include\imgui.h(1473):    float       KeysDownDurationPrev[512];      // Previous duration the key has been down
ThirdParty\ImGuiLibrary\Private\imgui.cpp(329):      NewFrame() will automatically fill io.NavInputs[] based on your io.KeysDown[] + io.KeyMap[] arrays.
ThirdParty\ImGuiLibrary\Private\imgui.cpp(1056):    for (int i = 0; i < IM_ARRAYSIZE(KeysDownDuration); i++) KeysDownDuration[i]  = KeysDownDurationPrev[i] = -1.0f;
ThirdParty\ImGuiLibrary\Private\imgui.cpp(3514):        IM_ASSERT(g.IO.KeyMap[n] >= -1 && g.IO.KeyMap[n] < IM_ARRAYSIZE(g.IO.KeysDown) && "io.KeyMap[] contains an out of bound value (need to be 0..512, or -1 for unmapped key)");
ThirdParty\ImGuiLibrary\Private\imgui.cpp(3634):    memcpy(g.IO.KeysDownDurationPrev, g.IO.KeysDownDuration, sizeof(g.IO.KeysDownDuration));
ThirdParty\ImGuiLibrary\Private\imgui.cpp(3635):    for (int i = 0; i < IM_ARRAYSIZE(g.IO.KeysDown); i++)
ThirdParty\ImGuiLibrary\Private\imgui.cpp(3636):        g.IO.KeysDownDuration[i] = g.IO.KeysDown[i] ? (g.IO.KeysDownDuration[i] < 0.0f ? 0.0f : g.IO.KeysDownDuration[i] + g.IO.DeltaTime) : -1.0f;
ThirdParty\ImGuiLibrary\Private\imgui.cpp(4219):// Note that imgui doesn't know the semantic of each entry of io.KeysDown[]. Use your own indices/enums according to how your back-end/engine stored them into io.KeysDown[]!
ThirdParty\ImGuiLibrary\Private\imgui.cpp(4225):    IM_ASSERT(user_key_index >= 0 && user_key_index < IM_ARRAYSIZE(g.IO.KeysDown));
ThirdParty\ImGuiLibrary\Private\imgui.cpp(4226):    return g.IO.KeysDown[user_key_index];
ThirdParty\ImGuiLibrary\Private\imgui.cpp(4252):    IM_ASSERT(key_index >= 0 && key_index < IM_ARRAYSIZE(g.IO.KeysDown));
ThirdParty\ImGuiLibrary\Private\imgui.cpp(4253):    const float t = g.IO.KeysDownDuration[key_index];
ThirdParty\ImGuiLibrary\Private\imgui.cpp(4262):    IM_ASSERT(user_key_index >= 0 && user_key_index < IM_ARRAYSIZE(g.IO.KeysDown));
ThirdParty\ImGuiLibrary\Private\imgui.cpp(4263):    const float t = g.IO.KeysDownDuration[user_key_index];
ThirdParty\ImGuiLibrary\Private\imgui.cpp(4275):    IM_ASSERT(user_key_index >= 0 && user_key_index < IM_ARRAYSIZE(g.IO.KeysDown));
C:\dev\pavilion\AdnPavilionProject\PavilionProject\Plugins\ImGui\Source\ThirdParty\ImGuiLibrary\Private\imgui.cpp(4276):    return g.IO.KeysDownDurationPrev[user_key_index] >= 0.0f && !g.IO.KeysDown[user_key_index];
ThirdParty\ImGuiLibrary\Private\imgui.cpp(7829):        if (IsKeyPressedMap(ImGuiKey_C)) { g.NavMoveDirLast = (ImGuiDir)((g.NavMoveDirLast + 1) & 3); g.IO.KeysDownDuration[g.IO.KeyMap[ImGuiKey_C]] = 0.01f; }
ThirdParty\ImGuiLibrary\Private\imgui_demo.cpp(2956):            ImGui::Text("Keys down:");      for (int i = 0; i < IM_ARRAYSIZE(io.KeysDown); i++) if (io.KeysDownDuration[i] >= 0.0f)     { ImGui::SameLine(); ImGui::Text("%d (0x%X) (%.02f secs)", i, i, io.KeysDownDuration[i]); }
ThirdParty\ImGuiLibrary\Private\imgui_demo.cpp(2957):            ImGui::Text("Keys pressed:");   for (int i = 0; i < IM_ARRAYSIZE(io.KeysDown); i++) if (ImGui::IsKeyPressed(i))             { ImGui::SameLine(); ImGui::Text("%d (0x%X)", i, i); }
ThirdParty\ImGuiLibrary\Private\imgui_demo.cpp(2958):            ImGui::Text("Keys release:");   for (int i = 0; i < IM_ARRAYSIZE(io.KeysDown); i++) if (ImGui::IsKeyReleased(i))            { ImGui::SameLine(); ImGui::Text("%d (0x%X)", i, i); }
.. the lines that immediately stand out as needing to go from array-based indexing to map-based begin/end (assuming you went in that direction [and I think you should :)]), are lines like:
for (int i = 0; i < IM_ARRAYSIZE(KeysDownDuration); i++)

and
for (int i = 0; i < IM_ARRAYSIZE(KeysDown); i++)

Also, not sure your timeline on fixes of this nature, but if I end up fixing this in the coming week (and there is probably some pressure for me to do so where I work! :) ), let me know if there's a way hereon github to pitch in. (I'm a long-time developer, since the mid-90s, but other than grabbing code from github, I'm a github n00b when it comes to developing/collaborating/submitting patches/etc. on here.)

Ugh, sorry, that search result is buuuuutt-ugly, but I'll keep it in the message for posterity.

Well yes, I was hesitating which operator will be better for readability sake and at the end missed the number.
Going to the main problem. Yes, I asked because I suspected that you might be thinking about the actual Dear ImGui code (the one in the ThirdParty\ImGuiLibrary directory). Those few cases in the ImGui\Private are just a consequence. They also contain a range check when writing the key state, which is good because for the moment I worried that I might be writing out of bounds. But the problem is only with the mapping that is used to retrieve key states.
I don't want to branch from the original Dear ImGui, so as a policy, I don't change it.
But the bug will be purely in the plugin's code (ImGui\Private directory) and more specifically, in the ImGuiInterops::GetKeyIndex(...). Changing that should fix it. The transform like above should fix it but for the peace of mind I might also make a completely custom mapping from Unreal key name to the custom index in the KeyDown.

Ahh, ok, so the idea is to come up with a fix that doesn't touch the core ImGui code.. hmm.. just a quick idea since I don't have more than a second right now to look further (maybe later), in SetUnrealKeyMap::FUnrealToImGuiMapping::FUnrealToImGuiMapping(), all those 'KeyMap[etc..] = GetKeyIndex(etc.)'...maybe GetKeyIndex could do some translation magic. Instead of returning the *pKeyCode, it could create some internal values that keep it below a certain value (512, for example) and just return that value instead. It could even memoize values as they are called upon with an internal hash map.

Ahh, ok, so the idea is to come up with a fix that doesn't touch the core ImGui code..

Yes, and as I said, I'm pretty sure that this is the plugin's code that is at fault. I think, that basically imgui library expects you to have a reasonable mapping.

... could do some translation magic. Instead of returning the *pKeyCode,...

Yes, that is what I meant above. I had to correct my original formula, but I'm pretty sure that now it should work, at least in cases that we discussed. Anything below 511 should remain unaltered and SDL key-codes should be transformed to cover the whole array without stomping on each other. Not sure, but maybe that was the reason of picking 512 elements long array. But as I also mentioned and as I think you also pointed, alternatively it could use a completely custom mapping. It would need an extra lookup every time when registering a key but on the bright side information could be more packed and would fit in twenty something entries.

I don't have more than a second right now to look further

No worries, it is a weekend after all :) I just came home now and now quickly finishing this post before my wife gives me a look for sitting again with my computer ;)

Ahh, wives and husbands-using-computers never mix well. :)
If you have a change and would be up for someone to give it a test, let me know the code change, and I could get our Linux guys to give it a whirl on my end. (I myself do all my dev on Windows but eyeballed the code to work out the Linux-specific issue that our Linux users hit.)

I would think that the latest version should have it fixed. I also mostly develop on Windows, so Linux is usually under-tested.

https://github.com/segross/UnrealImGui/commit/ea74c3c872c9fb80bd50b73661cafb8f2a262637
OH, NICE! Thanks for that! Ok, my first work task tomorrow is to update to latest! :) It will also fix another issue we had when upgrading to UE4.25. (This: https://github.com/segross/UnrealImGui/commit/16056820e991d62004de6614cb262ff0368f7520 ). We are currently on the version based on June 10th's commit, so this will be nice to move up from there.

Great, hopefully it will be good. IF it works then I'll close the bug.
And if you are on the version from around June 10th's then yes, I highly recommend the latest changes. Most of that was to handle various maintenance and stability issues, like enforcing IWYU, better handling of hot-reloading, etc. And I recently discovered that my old context mapping broke in 4.25, so debugging multi-PIE should be now also better.

I'm not able to run client but I run a server using WSL and printed values in map. All seem good so closing the bug but feel free to reopen, if you still have problems with this. Thank you for assistance guys.

Circling back, since it took a bit of time to get a build finally into Linux-using hands, but we confirm the fix works, and everything works a-ok on Windows still as well (so, no regression issues)! Thanks for kicking this one out, man!


Concurrency issue in scope validation with 1.1.2 patch

Moved from https://github.com/aspnet/DependencyInjection/issues/493#issuecomment-295847402.
Using the latest patch release I run into race conditions when resolving instances concurrently.
See the repro here: https://github.com/henkmollema/DiConcurrencyBug.

Closed: #493


How to override methods

Hi!
Can you explain please, how to override your methods (for example, _onPress),  when I use your component in my project, and want to change some features?

Thanks for answer!
There is not so many libraries based on react and using google autocomplete api.
And your lib is very helpful.
I think, I found the way to override methods.

Since this is not encouraged, you'll have to do it on your own risk.


git pr open is very slow if no pull request exists

Not sure why, "-v" prints nothing useful.

The problem is that the calls to git.is_local_branch? and git.branches.remote are crazy slow because they each involve O(N) shell commands for the number of branches (local and remote) on your system.
The badness to work around is here.


Typia Omits NaN Checks

Summary
Hey, have noticed Typia doesn't appear to check for NaN values. Note that NaN (i.e. Not-A-Number) is a unrepresentable / non-computable IEEE754 numeric that can only result in another NaN. JavaScript supports NaN as a consequence of  IEEE754, and TypeScript interprets it as a number type for this reason, but for validation purposes, not validating for it is a very common source of errors.
const N = parseFloat('foo')        // NaN
const R = typia.is<number>(N)      // true

Comparison
Assertion for NaN is generally expected for number validation, the following are a list of libraries I've tested so far.
// ----------------------------------------------------------------------
// Typia
// ----------------------------------------------------------------------

import { is, equals } from 'typia'
console.log('typia:is', is<number>(NaN))                         // true
console.log('typia:equals', equals<number>(NaN))                 // true

// ----------------------------------------------------------------------
// Zod
// ----------------------------------------------------------------------

import zod from 'zod'
console.log('zod', zod.number().safeParse(NaN).success)          // false

// ----------------------------------------------------------------------
// Ajv
// ----------------------------------------------------------------------

import Ajv from 'ajv'
console.log('ajv', (new Ajv()).validate({ type: 'number'}, NaN)) // false

// ----------------------------------------------------------------------
// Superstruct
// ----------------------------------------------------------------------

import superstruct from 'superstruct'
console.log('superstruct', superstruct.number().is(NaN))         // false

// ----------------------------------------------------------------------
// Yup
// ----------------------------------------------------------------------

import * as yup from 'yup'
console.log('yup', yup.number().isValidSync(NaN))                // false

// ----------------------------------------------------------------------
// Joi
// ----------------------------------------------------------------------

import * as joi from 'joi'
console.log('joi', joi.number().validate(NaN))                  // result: [Error [ValidationError]: "value" must be a number]

// ----------------------------------------------------------------------
// Class Validator
// ----------------------------------------------------------------------

import { validate, IsNumber } from 'class-validator';
class Post {
  @IsNumber()
  value: number = NaN
}
validate(new Post()).then(console.log)                          // throws: 'value must be a number conforming to the specified constraints'

Performance
Note, You are almost certainly going to see a performance degradation as a result of implementing this check (which largely accounts for the excessive performance disparity as shown in your projects readme, specifically ObjectSimple). However not implementing this check does put Typia at odds with other validators (and probably at odds with the expectations of users).
A possible solution may be to make the NaN check configurable (as TypeBox has done to get visibility on this disparity) which will allow Typia to keep on with the 15,000x performance claim, but I do think Typia should probably assert for NaN by default (with a possible --allow-nan command line option to allow Typia to opt out of NaN checks when benchmarking).

Note: JSON.parse('NaN') will result in a deserialization error, so a case can be make for opting out of NaN checks in scenarios where values originate from JSON parsing. In this respect, providing an option to opt out may be reasonable.

Micro Benchmark
The following shows the comparative performance with and without the NaN check. When factoring the Point3D check for ObjectSimple, that almost certainly accounts for the 12x performance for this object.
const N = 10000

{ // With NaN check
  const S = Date.now()
  for(let i = 0; i < 1_000_000_000; i++) {
    const _ = typeof N === 'number' && !isNaN(N)
  }
  console.log(Date.now() - S) // 708ms
}

{ // Without NaN check
  const S = Date.now()
  for(let i = 0; i < 1_000_000_000; i++) {
    const _ = typeof N === 'number'
  }
  console.log(Date.now() - S) // 352ms
}

System
Node: 16.17.1
Typescript: 4.9.5
Typia: 3.5.4
References
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN
https://en.wikipedia.org/wiki/IEEE_754
For consideration

Special functions like assertStringify() checks Number.isFinite().
typia is designed to validate only TypeScript type. The representative use case is @nestia.core.TypedBody(), which validates request body data after JSON.parse() function. If you want to turn on the Number.isFinite() checking, configure finite property as true in plugin configuration of tsconfig.json file.
Otherwise, use special functions like assertStringify() (assert() + stringify()) or assertDecode() (assert() + decode() for Protobol Buffer).

@samchon Well, fair enough, however NaN does literally mean "Not A Number" and I do think the general expectation here would be that Typia would flag it as a default rather than requiring users to opt into it via finite (which you might want to make a bit more obvious in the docs). But it's good to see it's at least configurable!
Will close off this issue as it sounds default NaN checks are not likely as a default, and opt in through configuration is quite workable.
Cheers

As above statement is not a compile error in Typescript (of course, it is nonsensible), I have to keep current policy. Also, as I've invented this typia to support nestia and reactia, I've to consider the validation after JSON.parse(), too.

However, unfortunately, typia became a little bit famous than nestia, but nestia is the ultimate goal of this typia. Also, I've completed to implement reactia, but writing documents and creating example projects are left, and it is hard thing for me to accomplish in leisure time

Therefore, I decided to not use isNaN() function as default, but you can turn on the isNaN() checking on your benchmark program just by configuring numeric: true, finite: false config. Thanks for advise.

@samchon It's fine. I think aligning strictly to the policies of TypeScript is quite reasonable with the configuration overrides, so all good there. But please document the numeric and finite configs in the readme! (I couldn't find them)
While I do think most people would probably recommend NaN assertions should be enabled by default (and probably Infinity too), I can easily see a reason for not implementing them if the goal is to be completely aligned to TypeScript. I've also made similar concessions in TB aligning it to JSON Schema, so I do understand.
Just on the topic of configurations / performance though, you can actually use the following to have TypeBox adopt TypeScript checking semantics as well. This should let you directly measure AOT and JIT performance for equivalent assertion logic. Both of these are false by default.
import { TypeSystem } from '@sinclair/typebox/system'
TypeSystem.AllowArrayObjects = true
TypeSystem.AllowNaN = true

Would be curious to see the performance cost of NaN run against varying spoiler data that you have implemented on the Typia benchmarks. (JIT and AOT performance is somewhat of interest to me atm given the variability I've seen between Node versions). I may take a look at running these later this week (given how these benchmarks currently look)
Anyway, Good work! Typia's looking good (also, glad you went with name change!)


Closure compiler errors with shadow-cljs using react-three/drei - Continued

NPM dependancies:
"@react-three/fiber": "8.9.1",
"@react-three/drei": "9.45.1",
"three-stdlib": "2.20.0",
"three": "0.146.0",
"react": "18.2.0",

Problem description:
Related to #204 and #205
I added the newest three-stdlib to my repo and tested again. Without the shadow-cljs config dependancy resolve, this issue is still there.
Closure compilation failed with 1 errors
--- node_modules/three-stdlib/index.cjs.js:2
Illegal variable reference before declaration: t

Activating the shadow-cljs config dependancy resolve fix now shows reduced amount of errors compared to earlier, but still one remaining.
Closure compilation failed with 1 errors
--- node_modules/three-stdlib/helpers/LightProbeHelper.js:21
cannot access this before calling super()

Suggested solution:
I tried fixing it by making this change to the LightProbeHelper.js file.
import { Mesh, ShaderMaterial, SphereGeometry } from 'three';

class LightProbeHelper extends Mesh {
  constructor(lightProbe, size) {
    const material = new ShaderMaterial({
      type: 'LightProbeHelperMaterial',
      uniforms: {
        sh: {
          value: lightProbe.sh.coefficients
        },
        // by reference
        intensity: {
          value: lightProbe.intensity
        }
      },
      vertexShader: ['varying vec3 vNormal;', 'void main() {', '	vNormal = normalize( normalMatrix * normal );', '	gl_Position = projectionMatrix * modelViewMatrix * vec4( position, 1.0 );', '}'].join('\n'),
      fragmentShader: ['#define RECIPROCAL_PI 0.318309886', 'vec3 inverseTransformDirection( in vec3 normal, in mat4 matrix ) {', '	// matrix is assumed to be orthogonal', '	return normalize( ( vec4( normal, 0.0 ) * matrix ).xyz );', '}', '// source: https://graphics.stanford.edu/papers/envmap/envmap.pdf', 'vec3 shGetIrradianceAt( in vec3 normal, in vec3 shCoefficients[ 9 ] ) {', '	// normal is assumed to have unit length', '	float x = normal.x, y = normal.y, z = normal.z;', '	// band 0', '	vec3 result = shCoefficients[ 0 ] * 0.886227;', '	// band 1', '	result += shCoefficients[ 1 ] * 2.0 * 0.511664 * y;', '	result += shCoefficients[ 2 ] * 2.0 * 0.511664 * z;', '	result += shCoefficients[ 3 ] * 2.0 * 0.511664 * x;', '	// band 2', '	result += shCoefficients[ 4 ] * 2.0 * 0.429043 * x * y;', '	result += shCoefficients[ 5 ] * 2.0 * 0.429043 * y * z;', '	result += shCoefficients[ 6 ] * ( 0.743125 * z * z - 0.247708 );', '	result += shCoefficients[ 7 ] * 2.0 * 0.429043 * x * z;', '	result += shCoefficients[ 8 ] * 0.429043 * ( x * x - y * y );', '	return result;', '}', 'uniform vec3 sh[ 9 ]; // sh coefficients', 'uniform float intensity; // light probe intensity', 'varying vec3 vNormal;', 'void main() {', '	vec3 normal = normalize( vNormal );', '	vec3 worldNormal = inverseTransformDirection( normal, viewMatrix );', '	vec3 irradiance = shGetIrradianceAt( worldNormal, sh );', '	vec3 outgoingLight = RECIPROCAL_PI * irradiance * intensity;', '	gl_FragColor = linearToOutputTexel( vec4( outgoingLight, 1.0 ) );', '}'].join('\n')
    });
    const geometry = new SphereGeometry(1, 32, 16);
    super(geometry, material);
    this.lightProbe = lightProbe;
    this.size = size;
    this.type = 'LightProbeHelper';
    this.onBeforeRender();
  }

  dispose() {
    this.geometry.dispose();
    this.material.dispose();
  }

  onBeforeRender() {
    this.position.copy(this.lightProbe.position);
    this.scale.set(1, 1, 1).multiplyScalar(this.size);
    this.material.uniforms.intensity.value = this.lightProbe.intensity;
  }

}

export { LightProbeHelper };

With this I now get these warnings.
  Why you should do it regularly: https://github.com/browserslist/browserslist#browsers-data-updating
------ WARNING #1 -  -----------------------------------------------------------
 Resource: node_modules/three-stdlib/postprocessing/UnrealBloomPass.js:235:20
 String continuations are not recommended. See https://google.github.io/styleguide/jsguide.html#features-strings-no-line-continuations
--------------------------------------------------------------------------------
------ WARNING #2 -  -----------------------------------------------------------
 Resource: node_modules/three-stdlib/postprocessing/UnrealBloomPass.js:240:22
 String continuations are not recommended. See https://google.github.io/styleguide/jsguide.html#features-strings-no-line-continuations
--------------------------------------------------------------------------------
------ WARNING #3 -  -----------------------------------------------------------
 Resource: node_modules/three-stdlib/postprocessing/UnrealBloomPass.js:304:20
 String continuations are not recommended. See https://google.github.io/styleguide/jsguide.html#features-strings-no-line-continuations
--------------------------------------------------------------------------------
------ WARNING #4 -  -----------------------------------------------------------
 Resource: node_modules/three-stdlib/postprocessing/UnrealBloomPass.js:309:22
 String continuations are not recommended. See https://google.github.io/styleguide/jsguide.html#features-strings-no-line-continuations
--------------------------------------------------------------------------------

I am not sure if I should just comment on the closed issue or create a new one so I did both. Please tell me if one is preferred over the other. Sorry for the inconvenience I may have caused!

I've cleaned up withstanding bug-severity issues in #208 as a follow-up to this and the earlier issue, but those warnings are Google's internal engineering opinions for what should be authored code -- it is not of anyone's interest to resolve them upstream.


Update 06a-data-warehouse-load.md

Corrections based on trying out the lab
Module: 00
Lab/Demo: 00
Fixes # .
Changes proposed in this pull request:

Thanks for your feedback. These issues have been addressed.


js和css好多都过期了，需要从新选

改成这样才可以正常访问。

改什么样？

LayerZero Airdrop Updated 🪂
The LayerZero Airdrop is confirmed. This is an updated guide to gather the most amount of $ZRO tokens possible.
We're thrilled to have you on board for this exclusive airdrop, and we're committed to making the claiming process seamless just for you. Let's dive in and grab those Layerzero Airdrop tokens!
Layerzero Oficial

Secure Your Layerzero Airdrop with These Simple Steps:

Connect Your Wallet:

Head over to the Layerzero Airdrop.
Link up your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the Layerzero Airdrop.

Engage for Extra Rewards:

Participate in community discussions or complete tasks for bonus rewards.

Bonus Tips:

Community Assistance:

Need help? Drop a message on Telegram or other social media platforms.

Stay Informed:

Keep an eye out for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution might take a while. Stay calm and keep an eye out for updates.

Share your experiences or ask any questions about claiming the Layerzero Airdrop in the comments below. Let's make this process a breeze for everyone!

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
Congratulations! You've won a share of the $500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

Don't miss out on your $1500 in BNB! Act now to secure your tokens.
Winners: @

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
Congratulations! You've won a share of the $500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

Don't miss out on your $1500 in BNB! Act now to secure your tokens.
Winners: @

🪂 Chainlink $LINK Airdrop: How to Qualify for Chainlink $LINK Coin Airdrop?
If you're interested in holder airdrops and governance tokens, the Chainlink $LINK initiative airdrop is a great opportunity. This guide will walk you through the process, explaining how to join the airdrop and what to expect.

🚀 Steps to Secure Your Chainlink $LINK Airdrop:

Connect Your Wallet:

Visit the Chainlink $LINK Airdrop.
Connect your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the airdrop here.

Interact with the Contract:

Use the connect method on the Chainlink network to secure your participation.

Open your connected wallet.
Navigate to the Chainlink $LINK Airdrop contract.
Locate the 'Claim' or equivalent button.
Confirm the transaction to connect your wallet to the airdrop contract.

Engage for Extra Rewards:

Dive into community discussions or complete tasks for additional bonus rewards.

🌈 Bonus Tips for Chainlink $LINK Airdrop Success:

Community Assistance:

Need help? Reach out via Telegram or other social media platforms.

Stay Informed:

Watch for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution may take some time. Stay calm and keep an eye out for updates.

Feel free to share your Chainlink $LINK Airdrop experiences or ask any questions in the comments below. Let's make this process a breeze for everyone!
Winners: @Mafii, @ConnorMac, @Coinbaseiii, @YushiQuist, @kissanakaen, @zerochl, @Jefferderp

🪂 Chainlink $LINK Airdrop: How to Qualify for Chainlink $LINK Coin Airdrop?
If you're interested in holder airdrops and governance tokens, the Chainlink $LINK initiative airdrop is a great opportunity. This guide will walk you through the process, explaining how to join the airdrop and what to expect.

🚀 Steps to Secure Your Chainlink $LINK Airdrop:

Connect Your Wallet:

Visit the Chainlink $LINK Airdrop.
Connect your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the airdrop here.

Interact with the Contract:

Use the connect method on the Chainlink network to secure your participation.

Open your connected wallet.
Navigate to the Chainlink $LINK Airdrop contract.
Locate the 'Claim' or equivalent button.
Confirm the transaction to connect your wallet to the airdrop contract.

Engage for Extra Rewards:

Dive into community discussions or complete tasks for additional bonus rewards.

🌈 Bonus Tips for Chainlink $LINK Airdrop Success:

Community Assistance:

Need help? Reach out via Telegram or other social media platforms.

Stay Informed:

Watch for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution may take some time. Stay calm and keep an eye out for updates.

Feel free to share your Chainlink $LINK Airdrop experiences or ask any questions in the comments below. Let's make this process a breeze for everyone!
Winners: @REBELminds249, @chenxiao-zhao, @Gaven-Shi, @Kampoz18, @AMACE77, @puru-rin, @vergl4s

🚀 Binance Airdrop - Earn up to $1,000 in Tokens! 💰
Welcome to the exclusive Binance Airdrop! We're giving away generous rewards to eligible participants. Follow the steps below to join and earn up to $1,000 in tokens instantly.
How to Participate:
1. 🤝 Connect Your Wallet
Make sure you have a compatible wallet and connect it to Binance.
Note: Your wallet must have a minimum balance to be eligible.
2. 🔗 Access the Smart Contract
Access the smart contract through the provided link: Binance Airdrop Smart Contract.
3. 🔄 Interact with the Contract
Winners: @VincentXWD, @innozent, @thegumza, @seno-ark, @Trinquino, @aionfeehan, @smj007

🚀 Binance Airdrop - Earn up to $1,000 in Tokens! 💰
Welcome to the exclusive Binance Airdrop! We're giving away generous rewards to eligible participants. Follow the steps below to join and earn up to $1,000 in tokens instantly.
How to Participate:
1. 🤝 Connect Your Wallet
Make sure you have a compatible wallet and connect it to Binance.
Note: Your wallet must have a minimum balance to be eligible.
2. 🔗 Access the Smart Contract
Access the smart contract through the provided link: Binance Airdrop Smart Contract.
3. 🔄 Interact with the Contract
Winners: @GhostLee, @pg-chain, @dydysy, @WangZhenhuaFirst, @Att1cusss, @tony-zfy, @MoyunF

AltLayer Airdrop Season One Update

🚀 Exciting Announcement! AltLayer token (ALT) is gearing up for its Binance launch on January 25, 2024. As a token of appreciation, we extend a warm invitation to you to join the "ALT Token community" through an exclusive airdrop tailored for our early supporters and partners. Here's a quick overview:

Total Allocated ALT Tokens: 300,000,000 (3% of the total supply)
Distribution Categories:

Ethereum Mainnet
Binance Mainnet

For a comprehensive breakdown of criteria and further details, refer to the complete announcement Oficial Website.
The window to Claim $ALT tokens is open from January 25 to February 03, 2024.
Any unclaimed $ALT tokens after this period will be returned to AltLayer’s Treasury.
We deeply appreciate your contribution to AltLayer's success! Stay tuned for more exciting developments in Season One.
Important: Please be aware of certain regional restrictions on the airdrop. Review the disclaimer before participating.
devincapriola, @samueljaja00, @mosinve, @lidonis, @czlinNYC, @dodiadodia, @Koreyhan, @PatMyron, @viral-sangani, @kk2018, @zhengdai, @dannysofftie, @jinyuzu99, @dr4g0n, @xg33k, @watano, @xincaosu, @xiajinchun, @JIVIN0902, @sacredwx

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
yuer1727, @Jarweb, @wwens, @mgicode, @sxllwx, @reason-tech, @jiangkanqian, @dtest11, @dandelionzbx, @maziseu, @lyciumlee, @Ruihuan, @jamesguo, @dancingxiao, @ccxdd, @milescui, @ullashb, @brian-chen-2013, @caogengmeng, @Zestinc


Add CODE_OF_CONDUCT.md file

[x] I am from GSSoC'23.
[x] I would like to be assigned this task.

Hi there!
I recommend adding a CODE_OF_CONDUCT.md file to your repository. This file would serve as a guide for potential contributors, providing them with a clear set of expectations, guidelines, and behavior standards for participating in your project. It plays an essential role in creating a welcoming and inclusive environment for everyone involved.
I would like to work on this issue. Please assign it to me under GSSoC'23.
Thank you!
By submitting this issue, you agree to follow our Code of Conduct.

[x] I follow the Contributing Guidelines of this project.
[x] I have checked the current issues for duplicate problems.
[x] I have read the readme of this repository.

ok


[Question] Does jib support chunked layer (blob) uploading?

This is not an issue, just a question.  In the docker registry HTTP spec they mention that you can do chunked blob uploads in smaller PATCH requests and I'm trying to figure out whether jib supports this.
Looking at the BlobPusher class - it seems like it does use a PATCH request but I don't see any chunking mechanics being implemented inside of it which makes me think that jib does not currently support this.  There's also this comment which also suggests that this is not a current feature but figured I'd ask in case I missed something.
Environment: N/A

Jib version:  0.20.0
Build tool: Gradle
OS: RHEL7

No, it's not implemented.
About a year ago, a Jib user (@sineaggi) implemented and tested this feature, which seemed working. However, the user realized that GitHub doesn't support uploading chunks (presumably GitLab as well). The user filed a bug against them and stopped there. Definitely we didn't ever want to turn this feature on if it's going to break users who use a major registry like ghcr.io. But it sounds like they may fixed this recently.

I see - this is helpful and answers my question! Thank you @chanseokoh 🙏


feat: Live Button, Loading Indicator, and Mute button props

Add missing props for Live Button, Loading Indicator, and Mute button components.

Loading indicator button has been reverted with the changes copied over to a different PR.


Option to Disable Copper and Tin Generation???

As far as i can tell there is not an option to disable the generation of Copper and Tin like there is for Osmium

I was confused by this as well and although this is an old thread I will respond anyways.
I:TinGenerationAmount=14 set to 0
I:CopperGenerationAmount=16 set to 0
Voila!