minify failure with latest versions of uglify-js, uglify-es and terser

There's a common bug in the 3.x versions of the uglify-derived minifiers (uglify-js, uglify-es and terser) that prevents javascript bundlers from working with<EMAIL_ADDRESS>ERROR: Cannot read property '_walk' of null
https://github.com/terser-js/terser/issues/120#issuecomment-426418919
NOTE: There's nothing wrong with Tether's code! This is solely an uglify/terser problem.
You can see the bug if you apply this patch and run npm install && npm run check-dist:
--- a/package.json
+++ b/package.json
@@ -13,7 +13,8 @@
   "scripts": {
     "reinstall": "del node_modules && npm install",
     "watch": "gulp watch",
-    "build": "gulp build"
+    "build": "gulp build",
+    "check-dist": "gulp build && terser dist/js/tether.js -mc && echo SUCCESS"
   },
   "repository": {
     "type": "git",
@@ -35,6 +36,7 @@
     "gulp-rename": "^1.2.2",
     "gulp-sass": "^2.0.4",
     "gulp-uglify": "^1.4.3",
-    "gulp-wrap-umd": "^0.2.1"
+    "gulp-wrap-umd": "^0.2.1",
+    "terser": "^3.9.2"
   }
 }

Would you consider applying the following patch so that the uglify-derived minifiers can avoid this error? Hopefully this would be a temporary measure until these minifiers can be fixed.
--- a/src/js/tether.js
+++ b/src/js/tether.js
@@ -766,9 +766,4 @@ class TetherClass extends Evented {
       } else {
         let offsetParentIsBody = true;
-        function isFullscreenElement(e) {
-          let d = e.ownerDocument;
-          let fe = d.fullscreenElement || d.webkitFullscreenElement || d.mozFullScreenElement || d.msFullscreenElement;
-          return fe === e;
-        }
         let currentNode = this.element.parentNode;
         while (currentNode && currentNode.nodeType === 1 && currentNode.tagName !== 'BODY' && !isFullscreenElement(currentNode)) {
@@ -807,4 +802,10 @@ class TetherClass extends Evented {
       });
     }
+
+    function isFullscreenElement(e) {
+      let d = e.ownerDocument;
+      let fe = d.fullscreenElement || d.webkitFullscreenElement || d.mozFullScreenElement || d.msFullscreenElement;
+      return fe === e;
+    }
   }
 }

I think there is a simple workaround for this issue by simply moving out variable d one layer up. PR is here #292

Does uglify have an issue tracker with this for those of us who would like to follow it?  For now I'm having to force tether version 1.4.4 in my projects and would like to know when I can remove that restriction.

I think this is it:
https://github.com/mishoo/UglifyJS2/issues/3274

This bug was fixed in Terser.

Could you share which PR/version of terser that fixes it?

These two patches fixed it:
https://github.com/terser-js/terser/pull/152
https://github.com/terser-js/terser/pull/154
Everyone should be using<EMAIL_ADDRESS>or a later version.

Thanks!

This should now be fixed in<EMAIL_ADDRESS>


fix(appeal): skip creation on appeal duplication error for additional appeals

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 4 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.02%) to 38.78%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core/appeal/service.go
0
4
0.0%

Files with Coverage Reduction
New Missed Lines
%

core/appeal/service.go
1
57.65%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
2167

Relevant Lines:
5588

💛  - Coveralls


Paw 3.0.4

Editing an existing cask

[x] Commit message includes cask’s name (and new version, if applicable).
[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.

I put the version methods into the URL because it looks like they'll follow a pattern. Not obvious to me where they'd put the minor version component. Also, fixed an unnecessary quote reported by brew cask style --fix.

Thank you! 👍

According to the appcast, there is a specific position for the version.minor.
Some examples for version 2:

2003004001
2003003001
2003002001
2003001001


rancher2 + letsencrypt problems

Rancher versions:
2018.10.1    	v2.1.0
Docker version: (docker version,docker info preferred)
17.03
Operating system and kernel: (cat /etc/os-release, uname -r preferred)
rancheros 1.4.1
Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO)
aws
i am following along here https://rancher.com/docs/rancher/v2.x/en/installation/ha/helm-rancher/
but i can not get letsencrypt to work
when i do
kubectl -n cattle-system describe issuer
it shows
  Warning  ErrVerifyACMEAccount  4m    cert-manager  Failed to verify ACME account: Post https://acme-v02.api.letsencrypt.org/acme/acct/43751683: dial tcp: i/o timeout
  Warning  ErrInitIssuer         4m    cert-manager  Error initializing issuer: Post https://acme-v02.api.letsencrypt.org/acme/acct/43751683: dial tcp: i/o timeout

i followed the steps exactly and not sure what to do from here to fix it.

i tried to blow everything away and start from scratch and now i get
 kubectl -n cattle-system describe certificate
.......

  Conditions:
    Last Transition Time:  2018-10-12T21:32:07Z
    Message:               http-01 self check failed for domain "r2.example.com"
    Reason:                ValidateError
    Status:                False
    Type:                  Ready
Events:
  Type    Reason       Age   From          Message
  ----    ------       ----  ----          -------
  Normal  CreateOrder  14m   cert-manager  Created new ACME order, attempting validation...

and when i try and go to rancher in a browser i get
default backend - 404
so not sure how it would validate if that isnt working

i gave up trying and did external


Node crash with legacy MTi

When using a "legacy" MTi (MTi-28A53G35) the drivers crash as soon as it start, claiming the MTData message is too long.
Ros : Ros2 Humble
Os : Ubuntu 22.04.5
Steps to reproduce :

Have an old IMU, such as the MTi-28A53G35
Setup a ros2 workspace with the driver and source it.
launch the node with ros2 run xsens_driver mtnode.py

P.S. : a fix is on the way
driver_error_1.txt

Fixed (on my side at least) with #5 .


Issue-update workflow

Automated Review Comments
Issues in .github/workflows/main.yml:

(6, 'Line exceeds 80 characters')

I got it.


Instant checkout button is not visible in the cart sidebar

Current behavior

Instant checkout button is not visible in the cart sidebar, so I cannot use this option to place an order.

Expected behavior

There is a visible Instant checkout button in the cart sidebar, so I can place an order using this option.
Steps to reproduce the issue

Go to https://test.storefrontcloud.io/
Add any product to the cart
Open a cart sidebar clicking on the cart icon

Can you handle fixing this bug by yourself?

[ ] YES
[X] NO

Which Release Cycle state this refers to? Info for developer.
Pick one option.

[X] This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
[ ] This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
[ ] This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

Browser: Chrome 76
OS: ubuntu 18.04 LTS

Additional information

There is no difference if I'm logged in or not.

@GabiDivante are you sure? For me everything is ok (newest develop):

Please text me on slack, maybe I'm trying to reproduce it on the wrong way.

@andrzejewsky The problem exists only in the test environment https://test.storefrontcloud.io/ (in the latest develop is ok).
This shouldn't be due to the Magento configuration, because it is the same Magento test.

Seemingly the test.storefrontcloud.io has this module disabled; @patzick can you please confirm?

I'm closing the issue bc. the Instant Checkout works on develop for me too


Pull in the lastest rdf4j lib

Should address the following high-vulnerability SourceClear warning:

https://broadinstitute-dsp.sourceclear.io/teams/jppForw/issues/vulnerabilities/5391952/11157932

Coverage remained the same at 61.894% when pulling ae3facf4711e985f2164fb2fe5e048555d2740ea on gr-rdfxml into 837581c129f36464bb588a7b3ea091ec81385f65 on develop.


Link - active state doesn't work on sub-route

My mistake, I post this issue in the wrong repos and can't delete it 😅


[Access Request] report 99003802 "Copy Production Order Document"

Could you please change the Access of the following variables to protected, that we can access them from report extensions?
protected var
        ToProdOrder: Record "Production Order";
        StatusType: Enum "Production Order Status";
        DocNo: Code[20];
        IncludeHeader: Boolean;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Increase compiler warnings

We should strive to increase compiler warning options.
In #510, there were links to some useful external resources for warning flags (GCC):

References:
GCC: 3.8 Options to Request or Suppress Warnings
StackOverflow: How to turn on (literally) ALL of GCC's warnings?
Best GCC warning flags for compiling C++

Edit: Diagnostic flags in Clang

As noted in the links, you very likely do not want to enable all possible warning flags, as some may not make sense for modern code, and some may even be contradictory. Nevertheless, it's hard to know what warnings are available, or applicable to your code, without some way to turn them on. Conveniently Clang provides the -Weverything flag for such a purpose.
I experimented with Clang by enabling the -Weverything option, and then trying to disable warnings until the project was able to build again without warnings or errors. For each warning seen, I disabled it by adding the no- prefix to the flag name. The resulting command that got the project compiling cleanly again was:
make CXXFLAGS_EXTRA="-Weverything -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-documentation -Wno-documentation-unknown-command -Wno-weak-vtables -Wno-comma -Wno-sign-conversion -Wno-double-promotion -Wno-ctad-maybe-unsupported -Wno-cast-qual -Wno-old-style-cast -Wno-padded -Wno-missing-variable-declarations -Wno-float-equal -Wno-exit-time-destructors -Wno-inconsistent-missing-destructor-override -Wno-global-constructors -Wno-date-time -Wno-newline-eof -Wno-unreachable-code-break -Wno-shadow-field"

Edit: The reverse set of flags, to turn on all the warnings that produce errors, the command is:
make CXXFLAGS_EXTRA="-Wc++98-compat -Wc++98-compat-pedantic -Wdocumentation -Wdocumentation-unknown-command -Wweak-vtables -Wcomma -Wsign-conversion -Wdouble-promotion -Wctad-maybe-unsupported -Wcast-qual -Wold-style-cast -Wpadded -Wmissing-variable-declarations -Wfloat-equal -Wexit-time-destructors -Winconsistent-missing-destructor-override -Wglobal-constructors -Wdate-time -Wnewline-eof -Wunreachable-code-break -Wshadow-field"

Some of those are not of interest. In particular, we explicitly use C++17 features, and so we don't care about code that breaks compatibility with C++98. Other flags however do seem to suggest there are things we could improve upon. In particular, unknown commands in Doxygen comments, abuse of the comma operator, unexpected conversions, missing override declarations, no newlines at end of file, unreachable code, and old style casts.

The last link recommended the following flags.
New:
-Wredundant-decls
-Wmissing-declarations
-Wmissing-prototypes
-Wmissing-include-dirs
-Wswitch-enum
-Wswitch-default
-Winvalid-pch
-Wmissing-format-attribute
-Wformat=2

Redundant:
-Wformat-nonliteral  (included in `-Wformat=2`)

Existing:
-Werror
-Wextra
-Wall
-Wcast-align

There was also mention of -Weffc++ (based on the book Effective C++), though with the suggestion that it wasn't very good, and was pretty noisy. There was also mention of -Wodr (One Definition Rule), which was recommended.
Another flag I encountered while paying around was -Wunused-function.

Here's another good list of compiler warnings to enable (and some not) for The Big Three by Jason Turner.

Bit of an update.
The bulk of the recommended flags from the link in the first post were enabled by #539, with a few exceptions:

-Wformat=2 - conflicts with string_format, used by unit tests, and downstream OPHD
-Wformat-nonliteral  (included in -Wformat=2)`

Additionally, the following flags were partially enabled, with exceptions:

The following 3 enabled flags have exlusions:

-Wmissing-prototypes - Clang only (flag not supported by GCC)
-Wredundant-decls - Excluded for Mingw-w64, due to conflicts with builtins
-Wcast-function-type (enabled by -Wextra) - Excluded for GCC-8, due to warnings about casts used by Delegate code, which likely won't be fixed anytime soon.

The flag -Weffc++ was found to produce warnings with GCC. Some of them look like they should be fixed. Perhaps not all of them should be.

The following miscellaneous fix was made:

-Wsign-compare (included by -Wextra) (#530)  (Only warned by MacOS Clang)

For the Clang -Weverything section, the following warning flags now have fixes merged:

-Wshadow-field (#535)
-Wunreachable-code-break (#534)
-Wnewline-eof (#533)
-Wold-style-cast (#531)

Remaining flags that produce warnings are:
make CXXFLAGS_EXTRA="-Wc++98-compat -Wc++98-compat-pedantic -Wdocumentation -Wdocumentation-unknown-command -Wweak-vtables -Wcomma -Wsign-conversion -Wdouble-promotion -Wctad-maybe-unsupported -Wcast-qual -Wpadded -Wmissing-variable-declarations -Wfloat-equal -Wexit-time-destructors -Winconsistent-missing-destructor-override -Wglobal-constructors -Wdate-time"

From the GCC Warning Options page, the -Wall flag enables the following:
-Waddress
-Warray-bounds=1 (only with -O2)
-Wbool-compare
-Wbool-operation
-Wc++11-compat  -Wc++14-compat
-Wcatch-value (C++ and Objective-C++ only)
-Wchar-subscripts
-Wcomment
-Wduplicate-decl-specifier (C and Objective-C only)
-Wenum-compare (in C/ObjC; this is on by default in C++)
-Wenum-conversion in C/ObjC;
-Wformat
-Wint-in-bool-context
-Wimplicit (C and Objective-C only)
-Wimplicit-int (C and Objective-C only)
-Wimplicit-function-declaration (C and Objective-C only)
-Winit-self (only for C++)
-Wzero-length-bounds
-Wlogical-not-parentheses
-Wmain (only for C/ObjC and unless -ffreestanding)
-Wmaybe-uninitialized
-Wmemset-elt-size
-Wmemset-transposed-args
-Wmisleading-indentation (only for C/C++)
-Wmissing-attributes
-Wmissing-braces (only for C/ObjC)
-Wmultistatement-macros
-Wnarrowing (only for C++)
-Wnonnull
-Wnonnull-compare
-Wopenmp-simd
-Wparentheses
-Wpessimizing-move (only for C++)
-Wpointer-sign
-Wreorder
-Wrestrict
-Wreturn-type
-Wsequence-point
-Wsign-compare (only in C++)
-Wsizeof-pointer-div
-Wsizeof-pointer-memaccess
-Wstrict-aliasing
-Wstrict-overflow=1
-Wswitch
-Wtautological-compare
-Wtrigraphs
-Wuninitialized
-Wunknown-pragmas
-Wunused-function
-Wunused-label
-Wunused-value
-Wunused-variable
-Wvolatile-register-var

The -Wextra flag enables the following:
-Wclobbered
-Wcast-function-type
-Wdeprecated-copy (C++ only)
-Wempty-body
-Wignored-qualifiers
-Wimplicit-fallthrough=3
-Wmissing-field-initializers
-Wmissing-parameter-type (C only)
-Wold-style-declaration (C only)
-Woverride-init
-Wsign-compare (C only)
-Wstring-compare
-Wredundant-move (only for C++)
-Wtype-limits
-Wuninitialized
-Wshift-negative-value (in C++03 and in C99 and newer)
-Wunused-parameter (only with -Wunused or -Wall)
-Wunused-but-set-parameter (only with -Wunused or -Wall)

Note that -Wall implies -Wunused, which implies all the sub-flags for unused items.

Given that list, we may be specifying redundant warning flags, which are already enabled by another group flag.

Going through the list of possible additional warnings in this thread, the following additional flags appear to be potentially useful:
-Wshadow
-Wnon-virtual-dtor
-Wold-style-cast
-Wcast-align
-Woverloaded-virtual
-Wconversion
-Wsign-conversion
-Wduplicated-cond
-Wduplicated-branches
-Wlogical-op
-Wnull-dereference
-Wuseless-cast
-Wdouble-promotion
-Wformat=2
-Wlifetime
-Weffc++

The following are already included by -Wall:
-Wmisleading-indentation
-Wunused
-Wunused-function

Looking through remaining Clang warnings:
make CXXFLAGS_EXTRA="-Wc++98-compat -Wc++98-compat-pedantic -Wdocumentation -Wdocumentation-unknown-command -Wweak-vtables -Wcomma -Wsign-conversion -Wdouble-promotion -Wctad-maybe-unsupported -Wcast-qual -Wpadded -Wmissing-variable-declarations -Wfloat-equal -Wexit-time-destructors -Winconsistent-missing-destructor-override -Wglobal-constructors -Wdate-time"

Uninteresting:

-Wc++98-compat  (targeting C++17)
-Wc++98-compat-pedantic

Largely uninteresting:

-Wpadded  (Overall structure sizes are uninteresting. Padding for fields may be interesting)
-Wfloat-equal  (Compare against 0 not interesting, template object compare not interesting)

Mildly interesting:

-Wdate-time  (Can potentially tag builds with Git commit hashes or tags instead)
-Wexit-time-destructors  (Libraries should avoid declaring many globals)
-Wglobal-constructors  (Libraries should avoid declaring many globals)

Interesting:

-Wdocumentation  (Some documentation is inconsistent with declared parameters)
-Wdocumentation-unknown-command  (Unknown command \fixme)
-Wweak-vtables  (Move virtual function implementation from header to source file)
-Wcomma  (Comma operator abuse)
-Wsign-conversion  (Implicit signed/unsigned conversions)
-Wdouble-promotion  (Implicit conversions float to double)
-Wctad-maybe-unsupported  (Point and Rectangle have no deduction guides)
-Wcast-qual  (All warnings already fixed)
-Wmissing-variable-declarations  (Declare or wrap in unnamed namespace)
-Winconsistent-missing-destructor-override  (Use override keyword)

I went through the list of recommended GCC warning flags. I was able to add:
-Wshadow
-Wnon-virtual-dtor
-Wold-style-cast
-Wcast-align
-Woverloaded-virtual
-Wnull-dereference
-Wdouble-promotion

For the Clang flags, the following had all warnings fixed:
-Wdocumentation (Some documentation is inconsistent with declared parameters)
-Wdocumentation-unknown-command (Unknown command \fixme)
-Wcomma (Comma operator abuse)
-Wdouble-promotion (Implicit conversions float to double)
-Wcast-qual (All warnings already fixed)
-Winconsistent-missing-destructor-override (Use override keyword)

Some of the flags listed for Clang also worked with GCC:
-Wdouble-promotion (Implicit conversions float to double)
-Wcast-qual (All warnings already fixed)

Remaining GCC flags that have not been enabled:
-Wconversion
-Wsign-conversion
-Wduplicated-cond
-Wduplicated-branches
-Wlogical-op
-Wuseless-cast
-Wlifetime
-Wformat=2
-Weffc++

Remaining Clang flags that still produce warnings:
-Wweak-vtables (Move virtual function implementation from header to source file)
-Wsign-conversion (Implicit signed/unsigned conversions)
-Wctad-maybe-unsupported (Point and Rectangle have no deduction guides)
-Wmissing-variable-declarations (Declare or wrap in unnamed namespace)

I did a Clang build using -Weverything and then turned off warnings that were still generated. The following list of flags was used to get back to a clean compile:
make CXXFLAGS_WARN="-Weverything -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-padded -Wno-weak-vtables -Wno-date-time -Wno-global-constructors -Wno-exit-time-destructors -Wno-float-equal -Wno-implicit-int-float-conversion -Wno-sign-conversion -Wno-missing-variable-declarations -Wno-tautological-type-limit-compare"

Here's the inverted list that enables all flags that still generate warnings:
make CXXFLAGS_WARN="-Wc++98-compat -Wc++98-compat-pedantic -Wpadded -Wweak-vtables -Wdate-time -Wglobal-constructors -Wexit-time-destructors -Wfloat-equal -Wimplicit-int-float-conversion -Wsign-conversion -Wmissing-variable-declarations -Wtautological-type-limit-compare"

The first few flags are of little to no interest. Removing those, the remaining flags are:
make CXXFLAGS_WARN="-Wdate-time -Wglobal-constructors -Wexit-time-destructors -Wfloat-equal -Wimplicit-int-float-conversion -Wsign-conversion -Wmissing-variable-declarations -Wtautological-type-limit-compare"

Found this article that may be worth noting here:
https://devblogs.microsoft.com/cppblog/broken-warnings-theory/

Some official documentation on warning levels is here:
https://learn.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=msvc-170
We currently use warning level 4 (/W4). The documentation shows that /Wall is higher than /W4. The documentation also mentions /WX, which means to treat warnings as errors, which we do on CI builds. The /WX flag can be used by both the compiler and the linker to treat warnings as errors.
Individual warnings (with code nnnn) can be suppressed, treated as errors, or warned about only once:

/wdnnnn (suppressed)
/wennnn (treated as error)
/wonnnn (report only once)

Some more documentation:
https://learn.microsoft.com/en-us/cpp/build/reference/external-external-headers-diagnostics?view=msvc-170
Under the section on "Limitations":

Code analysis warnings are also unaffected, since they don't have warning levels.

This would seem to imply that CAExcludePath may still be needed even when using setting ExternalWarningLevel to TurnOffAllWarnings, since CAExcludePath is specifically about Code Analysis warnings, which don't have a warning level.
That is relevant to the recently merged PR #1119. Though in that case it was removed from the NAS2D project, where it didn't seem to be needed. Meanwhile the unit test project may need such an exclusion to enable Code Analysis.

It may also be helpful to check that we have Security Development Lifecycle (SDL) checks on:
https://learn.microsoft.com/en-us/cpp/build/reference/sdl-enable-additional-security-checks?view=msvc-170

I'll re-iterate that turning on /Wall in Visual Studio is not recommended as you get numerous warnings from the STL and Microsoft-provided code. They themselves strive for clean '/W4` code, that is, no warnings when compiling under Level 4 warnings. Warnings-as-errors enforces this as well.

Out of interest, I thought I'd give /Wall a try anyway. Here's a build log showing 601 warnings:
https://github.com/lairworks/nas2d-core/actions/runs/5103617248/jobs/9173981405
Most of them don't look particularly interesting. Some are pretty much just informational. So yeah, doesn't really look to be worth enabling.

Mind you, we have config that should exclude external headers from error reporting, so the STL and Microsoft provided code are not really a concern.

I was taking a look at -Wtautological-type-limit-compare, which is emitted by the Filesystem code:

NAS2D/Filesystem.cpp:320:16: error: result of comparison 'const uintmax_t' (aka 'const unsigned long') ><PHONE_NUMBER>3709551615 is always false [-Werror,-Wtautological-type-limit-compare]
                if (fileSize > std::numeric_limits<std::string::size_type>::max())
                    ~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Rather than use std::numeric_limits::max() on std::string::size_type, we could instead use std::string::max_size(). As of C++20, it is marked constexpr, so would be usable in an if constexpr context (such as the one enclosing the block above).
One caveat is CI builds were failing during an initial attempt, with the error stating the function call was not constexpr, despite the -std=c++20 flag being set. Perhaps the CI images were old and didn't have the necessary update for that particular part of the C++20 standard. Related, the Visual Studio Code syntax checker was underlining code that tried to use max_size() in a constexpr context, again with the same error about it not being constexpr. These errors would need to be resolved before we could use such a solution.
Another possible caveat is the -Wtautological-type-limit-compare warning can be emitted even from code within an if constexpr block that should be removed by the compiler, or so it seems. The rules for this are not clear. Some additional investigation may be required. Perhaps on a related note, static_assert(false) is ill formed even when inside an if constexpr (false) block.


Mention adding release notes in CONTRIBUTING.md file

Added content to the CONTRIBUTING.md file on including notes here for added
updates, features and fixes.

Thanks for the review @brianhhu. I will merge after green status checks.


Disable routing web-traffic as an option

Right now there is no way to disable routing web-traffic through OpenVPN. Many people/developers (IoT) are using OpenVPN as encrypted tunnel to some services but not the web. It will be nice to get this option :-)
Right now, the solution for that use case is:

add route-noexec to the client configuration file
disable push "dhcp-option DNS X.X.X.X" in the server configuration file

Ok, now I can't connect from server to client :
server@server:~$ ping <IP_ADDRESS>
    PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.

and it hangs out.
So, any idea how to disable routing web-traffic on the server side and see clients from server?

So, any idea how to disable routing web-traffic on the server side and see clients from server?

Go to the OpenVPN forums for technical support. This is an issue tracker for matters related to the script.
Simplifying things a little bit, you shouldn't use route-noexec for that, remove the push "redirect-gateway def1 bypass-dhcp" line from the server configuration instead.
But this will not make an ideal setup for your purposes, other things would need to be changed. A road-warrior install has very different requirements than an internal networking one, that's also why this script will not add support for what you want.

@Nyr why this has been closed?
I'm interested too in this "feature". Up to now I have to manually edit the server config to disable web-traffic routing, since I don't need it, almost nullifying the purpose of the script.

other things would need to be changed

What are those things? If you provide guidelines I can help in the editing of the script.

why this has been closed?

Technical support was requested and provided to the user and user was told to go through the proper channels to get further support if needed.
The message included also a feature request which is fine to place in the issue tracker, but as explained there are no plans for implementing that specific request.

closed PR

The PR was closed mostly because of its "works for me" nature. It was very incomplete and not production ready, additional to other reasons which are not very important given the first.

What are those [other] things [which would need to be changed]?

Incomplete list of what I can think of right now:

IP forwarding wouldn't be needed so that part needs to be removed, both for the installation and the removal procedures.
NAT doesn't need to be set up either.
iptables and firewalld rules would need to be adapted to the new situation (for example, explicitly allow intra-VPN traffic)
Other configuration options specific for that kind of setup need to be implemented (for example, client-to-client is likely desirable).

TL;DR is that I don't think this option will be implemented, at least not in the near future. If I consider that a suggested feature is worth including, I don't have a problem writing the code for it.

@Nyr ok, I kinda see your point. The PR is a fast yet not clean workaround, but I guess has been done due to your refusal to address this specific "configuration".
I think I will fork the project and have a look myself at it, taking into account the list you provided, because I really like this script but I also really don't need intra traffic for my purposes.

My refusal is because a kinda big part of the script needs to be reworked to properly satisfy the needs of a small part of the user base. I get your point and I get that some others are interested too, but I don't feel motivated enough to approach that at this time.
A fork of the script with a proper internal networking configuration and maybe even some specific options for that use case seems like a good idea to me, if someone wants to take the time to do it properly.
For those who don't want that effort, removing that single line can be a quick fix, but not something which I want to make an official "feature" ;)


Missing newer releases

Looks like this feedstock is missing newer releases. Placeholder until I can investigate why the bot isn't picking anything up.

Ahh, it was the patch that we had to inject the tests because they were missing from the SDist, I think. Probably confused the bot, since we no longer had a single source.

It's not perfect but the status page normally contains a hint at the error for why the bot fails, in this case the issue was the presence of git_url:
iminuit

The recipe did not change in the version migration, a URL did not hash, or there is jinja2 syntax the bot cannot handle!

Please check the URLs in your recipe with version '2.3.0' to make sure they exist!

We also found the following errors:

 - migrations do not work on `git_url`s


Check if cURL is installed

Updates:

Added: Auto-install cURL if it's not found; required by VSDBG installation validator
Update: LaunchBuilder now uses RemoteVsDbgFullPath (./path/to/vsdbg)
Update: Renamed RemoteVsDbgPath to RemoteVsDbgBasePath for clarity
Fixed: SshTool.TryInstallVsDbg pulls default path from Options page (previously hard-coded)

Breaking Change

Fixed: Options window's default VSDBG is now the base path and not the full executable's path. Before: ~/vsdbg/vsdbg. Now: ~/.vsdbg

References

Story #27

NOTE:

Since the default VSDBG setting has changed, we need a migration strategy
Considering removing the option to set the VsDbg path and align with the default used by Visual Studio (~/.vs-debugger/vs2022). This would take care of breaking changes.


🧹 [cleanup] - refactoring to reduce cyclomatic complexity in machine controller, add missing autogenerated changes

What type of PR is this?

/kind cleanup
What this PR does / why we need it:

Some cleanup to reduce cyclomatic complexity in the machine controller
Adds missing autogenerated changes from #163 (cc @cbzzz)

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer: Based on #172 which was just focused on some lint changes
TODOs:

[x] squashed commits
[ ] includes documentation
[ ] adds unit tests
[ ] adds or updates e2e tests

Created #175 to update GHA for diff checking (out of scope for this PR)


doc: default polling behavior

Description of the change:
Motivation for the change:
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /docs
[ ] Commit messages sensible and descriptive

/approve

merging manually as this is doc only


Different behavior in style insertion order between vue-cli2 and vue-cli3

Version
3.7.0
Environment info
Different behavior with same code
![avatar](https://hgkcdn.oss-cn-shanghai.aliyuncs.com/test/cli2bug.png)
![avatar](https://hgkcdn.oss-cn-shanghai.aliyuncs.com/test/cli3bug.png)

Steps to reproduce
vue create vue-project-v4
vue init vue-project-v3
// hello-world.vue
<template>

test-find cli@3

    <x-span></x-span>

</template>

// x-span.vue
<template>

hello world

</template>

What is expected?
both hello world has same color style
What is actually happening?
in v3.7.0 the hello world color is green
in v2.x the hello world color is blue

Look forward to your reply 3q

That's because the old behaviour was considered bad/a bug and changed in vue-loader 15.
the old webpack template uses vue-loader14.


convert ant to gradle #199

convert ant to gradle.

Hey @wangqiaoshi !
Can you resolve some of the conflicts

remove .gradle directory from your changes

@suvodeep-pyne ok ,i will do it.

remove .gradle directory
resolve the conflicts
add '.gradle' in .gitignore file

@suvodeep-pyne can you modify the check from ant to gradle

update .travis.yml


Add debounceTime parameter to onChangePlugin

Suggestion 🤓
Let's add a debounceTime parameter to OnChangePlugin so that nobody needs to implement it on their side?
Arguments in favour ➕

Lodash's debounce is already in dependencies
I assume it's rare occasion when people need to process every key stroke
I assume it's common to debounce onChange because it may lead to components been re-rendered and async requests been fired

Arguments against ➖

Anybody could implement it from scratch without much issues

Let me know if it makes sense and if it seems reasonable to add this 🙏

I very much appreciate the PR, but I think it's trivial for someone to add this on their own. I'm hesitant to expand our API surface at this point, on principle.


Plugin crashes when I try to use it

Traceback:
Exception occurred:
  File "/usr/local/lib/python3.4/dist-packages/sphinx_autodoc_annotation.py", line 65, in get_doc
    add_annotation_content(self.object, result[-1])
IndexError: list index out of range
The full traceback has been saved in /tmp/sphinx-err-c6hpws9t.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
make: *** [html] Error 1

Here is the contents of that log file:
# Sphinx version: 1.3.1
# Python version: 3.4.0 (CPython)
# Docutils version: 0.12 release
# Jinja2 version: 2.8
# Last messages:
#   Running Sphinx v1.3.1
#   loading pickled environment...
#   done
#   building [mo]: targets for 0 po files that are out of date
#   building [html]: targets for 0 source files that are out of date
#   updating environment:
#   [extensions changed] 4 added, 0 changed, 0 removed
#   reading sources... [ 25%] fireblog
# Loaded extensions:
#   alabaster (0.7.6) from /usr/local/lib/python3.4/dist-packages/alabaster/__init__.py
#   sphinx_autodoc_annotation (unknown version) from /usr/local/lib/python3.4/dist-packages/sphinx_autodoc_annotation.py
#   sphinx.ext.todo (1.3.1) from /usr/local/lib/python3.4/dist-packages/sphinx/ext/todo.py
#   sphinx.ext.coverage (1.3.1) from /usr/local/lib/python3.4/dist-packages/sphinx/ext/coverage.py
#   sphinx.ext.viewcode (1.3.1) from /usr/local/lib/python3.4/dist-packages/sphinx/ext/viewcode.py
#   sphinx.ext.autodoc (1.3.1) from /usr/local/lib/python3.4/dist-packages/sphinx/ext/autodoc.py
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/sphinx/cmdline.py", line 245, in main
    app.build(opts.force_all, filenames)
  File "/usr/local/lib/python3.4/dist-packages/sphinx/application.py", line 264, in build
    self.builder.build_update()
  File "/usr/local/lib/python3.4/dist-packages/sphinx/builders/__init__.py", line 245, in build_update
    'out of date' % len(to_build))
  File "/usr/local/lib/python3.4/dist-packages/sphinx/builders/__init__.py", line 259, in build
    self.doctreedir, self.app))
  File "/usr/local/lib/python3.4/dist-packages/sphinx/environment.py", line 618, in update
    self._read_serial(docnames, app)
  File "/usr/local/lib/python3.4/dist-packages/sphinx/environment.py", line 638, in _read_serial
    self.read_doc(docname, app)
  File "/usr/local/lib/python3.4/dist-packages/sphinx/environment.py", line 791, in read_doc
    pub.publish()
  File "/usr/local/lib/python3.4/dist-packages/docutils/core.py", line 217, in publish
    self.settings)
  File "/usr/local/lib/python3.4/dist-packages/sphinx/environment.py", line 126, in read
    self.parse()
  File "/usr/local/lib/python3.4/dist-packages/docutils/readers/__init__.py", line 78, in parse
    self.parser.parse(self.input, document)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/__init__.py", line 172, in parse
    self.statemachine.run(inputlines, document, inliner=self.inliner)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 170, in run
    input_source=document['source'])
  File "/usr/local/lib/python3.4/dist-packages/docutils/statemachine.py", line 239, in run
    context, state, transitions)
  File "/usr/local/lib/python3.4/dist-packages/docutils/statemachine.py", line 460, in check_line
    return method(match, context, next_state)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 2726, in underline
    self.section(title, source, style, lineno - 1, messages)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 327, in section
    self.new_subsection(title, lineno, messages)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 395, in new_subsection
    node=section_node, match_titles=True)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 282, in nested_parse
    node=node, match_titles=match_titles)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 195, in run
    results = StateMachineWS.run(self, input_lines, input_offset)
  File "/usr/local/lib/python3.4/dist-packages/docutils/statemachine.py", line 239, in run
    context, state, transitions)
  File "/usr/local/lib/python3.4/dist-packages/docutils/statemachine.py", line 460, in check_line
    return method(match, context, next_state)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 2726, in underline
    self.section(title, source, style, lineno - 1, messages)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 327, in section
    self.new_subsection(title, lineno, messages)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 395, in new_subsection
    node=section_node, match_titles=True)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 282, in nested_parse
    node=node, match_titles=match_titles)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 195, in run
    results = StateMachineWS.run(self, input_lines, input_offset)
  File "/usr/local/lib/python3.4/dist-packages/docutils/statemachine.py", line 239, in run
     context, state, transitions)
  File "/usr/local/lib/python3.4/dist-packages/docutils/statemachine.py", line 460, in check_line
    return method(match, context, next_state)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 2299, in explicit_markup
    nodelist, blank_finish = self.explicit_construct(match)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 2311, in explicit_construct
    return method(self, expmatch)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 2054, in directive
    directive_class, match, type_name, option_presets)
  File "/usr/local/lib/python3.4/dist-packages/docutils/parsers/rst/states.py", line 2103, in run_directive
    result = directive_instance.run()
  File "/usr/local/lib/python3.4/dist-packages/sphinx/ext/autodoc.py", line 1467, in run
    documenter.generate(more_content=self.content)
  File "/usr/local/lib/python3.4/dist-packages/sphinx/ext/autodoc.py", line 828, in generate
    self.document_members(all_members)
  File "/usr/local/lib/python3.4/dist-packages/sphinx/ext/autodoc.py", line 750, in document_members
    check_module=members_check_module and not isattr)
  File "/usr/local/lib/python3.4/dist-packages/sphinx/ext/autodoc.py", line 815, in generate
    sig = self.format_signature()
  File "/usr/local/lib/python3.4/dist-packages/sphinx/ext/autodoc.py", line 1008, in format_signature
    result = self._find_signature()
  File "/usr/local/lib/python3.4/dist-packages/sphinx/ext/autodoc.py", line 971, in _find_signature
    docstrings = self.get_doc(encoding)
  File "/usr/local/lib/python3.4/dist-packages/sphinx_autodoc_annotation.py", line 65, in get_doc
    add_annotation_content(self.object, result[-1])
IndexError: list index out of range

The code on this repository actually fixes that already - but there was no release after the fix.
https://github.com/nicolashainaux/sphinx-autodoc-annotation/commit/2210fd86f7b650c7cc5bb8cb0c273643a563360a

Then in that case, #5 should fix this, whenever @nicolashainaux sorts that out.

I just published the patched version on PyPI, so this should be solved now.


R: carry logger information in transformations/measurements

Could follow a similar spec as the opendp-logger.

Closed in #376


BTC are no longer displayed in the DeFi Wallet

Actual behavior: the wallet doesn't show the bitcoin and doesn't let me move it either
Expected behavior: the wallet should actually display the token since nothing has changed except for the update
How to reproduce it (as minimally and precisely as possible):

Send previous app version btc to the wallet (they will be displayed)
Update app version 2.8.4
snapshot download and sync
the BTC are no longer displayed

What are your environment parameters?

DeFiCh/app Version:2.8.4
Operating System (OS): OS Windows 10 - 10.0.19043
– RAM (GB):  16 GB
– CPU (Intel Core i5/i7/etc.): Intel(R)Core(TM) i7 - 8550U CPU @1.80GHz, 1992MHz, 4 Kern(e), 8 loigsche(r)Prozessor(en)
Current free storage capacity: 242 GB

Anything else we need to know? no

Hi @Braccus89 , regarding the issue BTC not in the wallet #1093, we can further discuss the issue there. We would like to keep same issues in one thread. Thank you.
Kindly refer to this comment and try this out: https://github.com/DeFiCh/app/issues/1093#issuecomment-992386228


Implementation of cat's Applicative for Endpoint

#548

Current coverage is 78.15%

Merging #551 into master will decrease coverage by -1.03% as of 2a12dd1

Powered by Codecov. Updated on successful CI builds.

Thanks @ImLiar! Just a couple of nits from me.

Just noticed this PR, and this looks great to me. I have two suggestions:
It'd be handy to have this be an Alternative instance instead of just Applicative. The identity would just return None, and | serves as the combineK.
This captures the nature of Endpoint more precisely, allows users to work with them generically as Alternative, and someday if Shapeless has a Cats dependency (or someone starts an integration project) I have plans for abstracting out the :+: here to use only Alternative + Adjoin.

Oh, that was only the first suggestion. I actually have two others:
It might be worth providing a pureEval implementation in case people want to inject a value into an Endpoint lazily. This would just map Future.value into the argument and wrap the result in the same way that pure currently does.
It also may make sense to provide an ApplicativeError instance as well, where the error would end up inside the Future. I haven't thought that through yet, though.

One other thing: as we add these instances it'd be great to check the laws as well—it makes sure the instances are valid, and in the case of things like composeK being defined in terms of |, provides some additional testing for existing methods. Here's what the law testing for com.twitter.util.Future in catbird looks like, for example.
I don't think that needs to happen in this PR, but we should keep it in mind (and possibly open an issue if this gets merged without it).

Also, I'd be happy to see this merged as it is without the Alternative or pureEval methods—they're easy enough to add separately. So :+1: from me as is, but if you want to include that extra stuff here I'd be glad to review.

@travisbrown
Nice to see you remarks. I was thinking about laws but decided to get some feedback first.

Done with Alternative implementation.

Looks great! Alternative fits so nice here!

:+1: to the Alternative and pureEval. This is super nitpicky, but in general I think it's best to group related implementations together in type class instances—e.g. here pure and pureEval would be next to each other, and empty and combineK. Just makes it easier to see what's implemented or derived at a glance.

About ApplicativeError
Are we ok to have following signature?
implicit def alternativeEndpoint[E <: Throwable]: Alternative[Endpoint] with ApplicativeError[Endpoint, E] = new Alternative[Endpoint] with ApplicativeError[Endpoint, E] { ... }

ApplicativeError extends Applicative instance and requires implementation of all those methods. Again

@ImLiar Right, I'd have one instance provide both Alternative and ApplicativeError, but I'd suggest just ApplicativeError[Endpoint, Throwable] and a val, not a generic def. The specific E <: Throwable will be forgotten once it goes in the future, anyway.
I think that should probably happen in a separate PR, though—I'm still not sure it even makes sense here.

Well, Sir, in that catse, I'm done here! :smile:
![Image]
(http://awesomegifs.com/wp-content/uploads/cat-gone.gif)

Can we also check Alternative laws here in this PR? It should be pretty straightforward given that Finch already has discipline dependency.

Yea, okay

Thanks @ImLiar! This looks good to me. @travisbrown any chance you can have a look before I merge that?

I'd be happy to see this merged for now, but we really ought to provide a more complete arbitrary instance for Endpoint and equality checking that tests more than one input. Maybe we could merge it and immediately open a new issue to track these additions?

Thanks! I'll merge this then and file a new ticket about the tests.

@vkostyukov I've started the work on the law-checking—should be just a few minutes.

Thanks a lot @travisbrown!
In the meantime, I'm experimenting with representing an Endpoint as
final class Endpoint[A](
  val run: Endpoint.State[A]
}

object Endpoint {
  type State[A] = StateT[Option, Input, Eval[Future[Output[A]]]]
}

I've almost got core compiled and it looks pretty clean so far. Really happy with the result.


running wdltool.jar

so now I'm learning about WDL using the Broad readthedocs. it's pretty clear for the most part.
this womtools.jar inputs tool looks cool, described in the "Generating the template JSON" section here, albeit using an older name for the tool.
Is that something you ever do?  Is it worth adding that to the course?  or maybe this is all WDL102 content rather than 101.
Took me a minute to figure out how I'd do it, so maybe that's worth including somewhere in the Hutch teaching materials
module load cromwell/84
java -jar $EBROOTCROMWELL/womtool.jar ....

I think that's a great thing to include in WDL 102 and actually I wonder if I could get it to run inside the shiny app itself?!?!


RFC: Dynamic stylesheet replacement

Rendered

I believe it can be simplified a little bit more. What if you do it as shown below. There could exist a prop in lightningElement that have references to style sheets. When changed, style sheets are recomputed and passed to template. This way we won't need to import template just to pass it along the resolved style sheets inside the render method. It is like a sintatic sugar.
 import dark from './dark.css';
 import light from './light.css';

 export default class extends LightningElement {
   @api darkMode = false;

    this.styleSheets = this.darkMode? dark : light;
 }
 ```

`this.styleSheets` can receive an object, array or function that returns either an object or array.

When working with objects style sheets are the object keys, and their values can be true or false. If true, the style sheet is applied. For example:

````js
this.styleSheets = {
   styleSheet1 : true
   styleSheet2 : false,
   ...
}

When working with an array,  all style sheets in a given array are applied:
this.styleSheets = [ styleSheet1, styleSheet2 ];

It could also accept functions
this.styleSheets = this.getStyleSheets(); // components function

Or
//inline function
this.styleSheets = () => {
   let computedStyleSheets;
   ...
   return computedStyleSheets;
}

Or
import { getStyleSheets } from 'c/utility';

//this function is used in so many other components that it was exported as a module, and then imported everywhere it is used
this.styleSheets = getStyleSheets();

@AllanOricil Thanks for the feedback! A few comments:
First off, there is an existing programmatic style injection RFC which is already being shipped in the latest open-source version of LWC. This defines a static stylesheets property. Unfortunately I think the presence of this feature means that having a new non-static stylesheets property (or anything similarly-named) would risk confusing developers.

In my opinion, dynamically choosing templates and style sheets are two separate problems/concerns. Maybe developers need to switch between style sheets but not templates.

This is a strong point. The reason I choice render was mostly to re-use the existing infrastructure for rendering multiple templates. But you're right that it's a bit odd to have to pass in a template if you only have one.
I think your "styleSheets hook" suggestion is a neat idea. Except I would maybe rename it:
 export default class extends LightningElement {
   @api darkMode = false;
   renderStyleSheets() {
      return this.darkMode? dark : light;
   }
 }

The main advantage I see here is that we don't need to have render return an object, and to explain what happens if the properties are missing.
Also, it's pretty clear that if you have an implicitly-associated HTML file (and no render), then that file will be rendered alongside the stylesheets. (That said, I could also make the template property optional in the current RFC, which would have the same effect.)
The main downside I see is that this introduces additional API surface and a new render* function for developers to learn. But maybe it's a better approach?

@nolanlawson

The main downside I see is that this introduces additional API surface and a new render* function for developers to learn. But maybe it's a better approach?

Today I changed my mind when I started to think what render means in other contexts, like rendering 2D|3D objects. When using libraries to create these objects, render means draw shapes/vertices, then apply colors, texture, materials, shaders to make them look good. The render method concern is a single one: do everything that is necessary to draw something in the screen. So, If we think that templates are shapes/vertices, and the rest are like styles and style sheets, then It makes sense to handle both in a single render method.
The main reason I thought about a second method was just because I wanted to avoid unnecessary imports. Then I started to think if there could exist another way to enable the render method handle both features at the same time, and independently of each other, and I found another solution:
What if the render method returns 3 possible object types < Render | Template | StyleSheet | StyleSheet [] > ?
The Render object takes care of use cases where both dynamic style sheets and templates are required. This approach would be compatible with the current API and avoid unnecessary imports.
dynamic templates only
 import template_1 from './template_1.html';
 import template_2 from './template_2.html';

 export default class extends LightningElement {

    render_template_1 = true;

    render(){
      return this.render_template_1 ? template_1 : template_2;
    }
 }

dynamic style sheets only
 import dark from './dark.css';
 import light from './light.css';

 export default class extends LightningElement {
   @api darkMode = false;

    render(){
      return this.darkMode? dark : light;
    }
 }

dynamic style sheets and template, single style sheet
 import template_1 from './template_1.html';
 import template_2 from './template_2.html';
 import dark from './dark.css';
 import light from './light.css';

 export default class extends LightningElement {

   render_template_1 = true;
   @api darkMode = false;

    render(){
      return {
         template: this.render_template_1 ? template_1 : template_2,
         styleSheet:  this.darkMode? dark : light
      }
    }
 }

dynamic style sheets with multiple style sheets
 import dark from './dark.css';
 import light from './light.css';
 import common from './common.css';

 export default class extends LightningElement {

   render_template_1 = true;

   @api darkMode = true;

    render(){
      return this.darMode ? [dark, common] : [light, common]
    }
 }

dynamic style sheets and template, with multiple style sheets
 import template_1 from './template_1.html';
 import template_2 from './template_2.html';
 import dark from './dark.css';
 import light from './light.css';
 import common from './common.css';

 export default class extends LightningElement {

   render_template_1 = true;

   @api darkMode = true;

    render(){
      return {
         template: this.render_template_1 ? template_1 : template_2,
         styleSheet[]:   this.darMode ? [dark, common] : [light, common]
      }
    }
 }

I think we can achieve a similar thing by allowing the render() function to return { stylesheets } (no template). In this case, the template would be implied.
You're right that we could also distinguish between stylesheets and templates being returned directly, but I wonder if the shorthand is worth it – I personally tend to prefer explicit compared to implicit. That said, it could always be added later in a backwards-compatible way.

I've modified the RFC to support returning { stylesheets } (no template),  or stylesheets directly as a shorthand. In this case, the template is just the implicitly-associated *.html file.

We have decided not to move forward with this RFC. Instead, we have documented several solutions to replace the current template.stylesheets = ... hacks.


[mac] remove dead code

The value of constant kMinBackoff is 1. So the value of constant kMinBackoffSum is always greater than 0. kMaxBackoffSum is unused.


Serilog logs aren't sent / written into Azure ApplicationInsights for .NET Core API and Worker Service

I have a C# ASP .NET Core Web API application and an Worker Service application, but the logs from API and from Worker Service doesn't arrive in Azure Application Insights, can see them only in Console and are written to files.
Both scenario tested:

API deployed in Azure AppService + Worker Service deployed as Windows service in Azure in an Windows Server Virtual Machine
API and Worker Service ran in debug mode from local machine in Visual Studio

Versions:

.NET 5.0
Microsoft.ApplicationInsights.AspNetCore 2.18.0 (installed for the API)
Microsoft.ApplicationInsights.WorkerService 2.18.0 (installed for the Worker Service)
Serilog 2.10.0
Serilog.Sinks.ApplicationInsights 3.1.0 (or 2.6.4)

Tried without success even downgrading Serilog.Sinks.ApplicationInsights to version 2.6.4 as suggested in this issue.
Have both API and Worker service configured the same way:
API - Program.cs
var options = CommandLineOptions.Configure(args);
await Host.CreateDefaultBuilder(args)
	.ConfigureAppConfiguration(AppConfigurationServices.Configure)
	.ConfigureLogging(LoggerServices.Configure)
	.ConfigureServices(HostServices.Configure)
	.UseSerilog()
	.RunHostAsync(options);

Serilog.Debugging.SelfLog.Enable(msg => Debug.WriteLine(msg));

Worker Service - Program.cs
await Host.CreateDefaultBuilder(args)
	  .ConfigureWebHostDefaults(webBuilder =>
	  {
		  webBuilder
			  .ConfigureAppConfiguration(AppConfigurationServices.Configure)
			  .ConfigureLogging(LoggingServices.Configure)
			  .UseStartup<Startup>();
	  })
	  .UseSerilog()
	  .Build()
	  .RunAsync();

Serilog.Debugging.SelfLog.Enable(msg => Debug.WriteLine(msg));

I'm already supplying the Azure App Insights InstrumentationKey in appSettings.json two locations:
...
"ApplicationInsights": {
    "InstrumentationKey": "xxx-xyz"
  },
...
"Serilog": {
    "Using": [
      "Serilog",
      "Serilog.Sinks.Console",
      "Serilog.Sinks.File",
      "Serilog.Sinks.ApplicationInsights"
    ],
    "MinimumLevel": {
      "Default": "Debug",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "WriteTo": [
      {
        "Name": "Console"
      },
      {
        "Name": "File",
        "Args": {
          "path": "Logs/Services-.log",
          "rollingInterval": "Day"
        }
      },
      {
        "Name": "ApplicationInsights",
        "Args": {
          "instrumentationKey": "xxx-xyz",
          "restrictedToMinimumLevel": "Information",
          "telemetryConverter": "Serilog.Sinks.ApplicationInsights.Sinks.ApplicationInsights.TelemetryConverters.TraceTelemetryConverter, Serilog.Sinks.ApplicationInsights"
        }
      }
    ],
    "Enrich": [ "FromLogContext" ]
  }
...

When specifying InstrumentationKey only in ApplicationInsights and not under Serilog writer as well, iKey wasn't present and i got:
Application Insights Telemetry (unconfigured) {"name":"AppTraces", "time": "123...", ....}
After specifying InstrumentationKey in both places (ApplicationInsights and under Serilog writer) you can see multiple records like bellow in the Debug Output window from Visual Studio.
Even enabling Serilog self diagnostic doesn't produce any different output than this one from Debug Output window:
Application Insights Telemetry: {"name":"AppRequests", "time": "123...", "iKey": "xxx-xyz", ....}
Application Insights Telemetry: {"name":"AppMetrics", "time": "123...", "iKey": "xxx-xyz", ....}
Application Insights Telemetry: {"name":"AppTraces", "time": "123...", "iKey": "xxx-xyz", ....}

I have this same issue with the Application Insights Sink not configuring properly using appsettings.json.
My variation is as follows:

no instrumentation key in the sink config (as per documentation suggestion)
updated versions

  <ItemGroup>
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.20.0" />
    <PackageReference Include="Serilog.AspNetCore" Version="5.0.0" />
    <PackageReference Include="Serilog.Sinks.ApplicationInsights" Version="3.1.0" />
  </ItemGroup>

Result:
Trace is sent to app insights for the debug session, but not to Azure.
Application Insights Telemetry (unconfigured):

I can confirm the same behavior with my ASP.Net 6 Web API.
When the InstrumentationKey is only present in the ApplicationInsights section in appsettings.json, the trace items are only visible inside Visual Studio while debugging.
After adding the InstrumentationKey to the Args of the ApplicationInsights Sink, they also show up in the Azure portal.

I can confirm the same behavior with my ASP.Net 6 Web API. When the InstrumentationKey is only present in the ApplicationInsights section in appsettings.json, the trace items are only visible inside Visual Studio while debugging. After adding the InstrumentationKey to the Args of the ApplicationInsights Sink, they also show up in the Azure portal.

How did you manage to send send logs to Insight?

How did you manage to send logs to Insight?

Add InstrumentationKey to the Args of the ApplicationInsights WriteTo-configuration section in appsettings.json, as described in the original issue.

This works for me (replace my-key with your Instrumentation Key)
appsettings.json
{
  "ApplicationInsights": {
    "InstrumentationKey": "my-key"
  },
  "Serilog": {
    "Using": [
      "Serilog.Sinks.ApplicationInsights"
    ],
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "WriteTo": [
      {
        "Name": "Async",
        "Args": {
          "configure": [
            {
              "Name": "Console"
            },
            {
              "Name": "File",
              "restrictedToMinimumLevel": "Information",
              "path": "logs/log.log",
              "rollingInterval": "Day",
              "rollOnFileSizeLimit": true
            }
          ]
        }
      },
      {
        "Name": "ApplicationInsights",
        "Args": {
          "InstrumentationKey": "my-key",
          "restrictedToMinimumLevel": "Information",
          "telemetryConverter": "Serilog.Sinks.ApplicationInsights.Sinks.ApplicationInsights.TelemetryConverters.TraceTelemetryConverter, Serilog.Sinks.ApplicationInsights"
        }
      }
    ],
    "Enrich": [ "FromLogContext" ]
  }
}

Program.cs
public static class Programm
{
        public static void Main(string[] args)
        {
            Log.Logger = new LoggerConfiguration()
                .Enrich.FromLogContext()
                .WriteTo.Console()
                .WriteTo.File("logs/log.log", rollingInterval: RollingInterval.Day, rollOnFileSizeLimit: true)
                .CreateBootstrapLogger();
            try
            {
                Log.Information("Starting up");
                CreateHostBuilder(args).Build().Run();
            }
            catch (Exception e)
            {
                Log.Fatal(e, "Application start-up failed");
            }
            finally
            {
                Log.CloseAndFlush();
            }
        }

        private static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .UseSerilog((context, services, configuration) =>
                    configuration
                        .ReadFrom.Configuration(context.Configuration)
                        .ReadFrom.Services(services)
                        .Enrich.FromLogContext())
                .ConfigureWebHostDefaults(webBuilder => webBuilder.UseStartup<Startup>());
}

In .Net Core WEB API 6.0, In order to get app insights logs when running locally,  Set "APPINSIGHTS_INSTRUMENTATIONKEY" environment variable in the launch settings.
"profiles": {
"ProfileName": {
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"APPINSIGHTS_INSTRUMENTATIONKEY": "your-instrumentation-key"
}
}

Does this mean it has to be setup under under both locations

{
"Name": "ApplicationInsights",
"Args": {
"instrumentationKey": "xxxxx",
"telemetryConverter": "Serilog.Sinks.ApplicationInsights.TelemetryConverters.TraceTelemetryConverter, Serilog.Sinks.ApplicationInsights"
}
}
and

"profiles": {
"ProfileName": {
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"APPINSIGHTS_INSTRUMENTATIONKEY": "your-instrumentation-key"
}
}

Does this mean it has to be setup under under both locations

{
"Name": "ApplicationInsights",
"Args": {
"instrumentationKey": "xxxxx",
"telemetryConverter": "Serilog.Sinks.ApplicationInsights.TelemetryConverters.TraceTelemetryConverter, Serilog.Sinks.ApplicationInsights"
}
}
and
"profiles": {
"ProfileName": {
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"APPINSIGHTS_INSTRUMENTATIONKEY": "your-instrumentation-key"
}
}

I think ONLY #2 is required (above)

I have found I do not need to set environment variable.
Within Serilog appsettings, specify the ConnectionString instead of the Instrumentationkey
  {
    "Name": "ApplicationInsights",
    "Args": {
      //"instrumentationKey": "",
      "ConnectionString": "{provide connection string",
      "telemetryConverter": "Serilog.Sinks.ApplicationInsights.TelemetryConverters.TraceTelemetryConverter, Serilog.Sinks.ApplicationInsights"
    }
  }


Typo "Azure database for PostgreSQL"→"Azure Database for PostgreSQL"

https://docs.microsoft.com/en-us/azure/postgresql/overview-postgres-choose-server-options
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/postgresql/overview-postgres-choose-server-options.md
#PingMSFTDocs

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


BzAPI server on which your software depends is going away

Hi,
This bug has been filed because a code search has revealed that code in this repository is using "BzAPI", the Bugzilla API proxy server at https://api-dev.bugzilla.mozilla.org/.
This service is due to be decommissioned. Fortunately, Bugzilla has a new native REST API which works somewhat similarly that you could use instead:
https://wiki.mozilla.org/Bugzilla:REST_API
Moving to that new API would require some porting work. If that seems like too much effort, fear not, because there is also a BzAPI compatibility layer built on top of the new API. Because it's compatible, using that should simply require a change of API endpoint.
Change:
https://api-dev.bugzilla.mozilla.org/latest/
(or https://api-dev.bugzilla.mozilla.org/1.3/)
to
https://bugzilla.mozilla.org/bzapi/
You should not expect the api-dev server to continue to work after Friday 14th November. So please test and migrate your production instance(s) over before then, either to the BzAPI compatibility endpoint or to the new native REST API.
Thanks for using BzAPI. It's been a great ride :-)
Gerv

@sylvestre Please let me know to which API I should change

@sylvestre  whether the API is mentioned here (https://wiki.mozilla.org/Bugzilla:REST_API) is okay?

https://wiki.mozilla.org/Bugzilla:REST_API documents the current REST API, and it is safe to use.


Fix compilation of contracts without actions

fixes #468
Change Description

API Changes

[ ] API Changes

Documentation Additions

[ ] Documentation Additions

Looking forward to this fix!

The problem is due to different with the file name and contract name.
Please update the contract name according to file name i.e if file name is "testcontract.cpp" The contract should be defined as:
class [[eosio::contract("testcontract")]] cafe : public eosio::contract {
}


convert repeat keys into lists when parsing headers

This PR aims to improve filing headers for duplicate keys.
Example:
<SEC-DOCUMENT>0001213900-24-076658.txt : 20240906
<SEC-HEADER>0001213900-24-076658.hdr.sgml : 20240906
<ACCEPTANCE-DATETIME>20240906194548
ACCESSION NUMBER:<PHONE_NUMBER>-24-076658
CONFORMED SUBMISSION TYPE:	SC 13G
PUBLIC DOCUMENT COUNT:		2
FILED AS OF DATE:		20240906
DATE AS OF CHANGE:		20240906
GROUP MEMBERS:		DANIEL B. ASHER
GROUP MEMBERS:		MITCHELL P. KOPIN       <-- Appears twice

Previously the following would be parsed;

This PR adds support for the following;

Accepting the fix for handling duplicate keys in headers


Implement MDServerRemote.FolderNeedsRekey

Looks like this needs to go in in order for https://github.com/keybase/client/pull/5521 to pass CircleCI

Sigh; it's failing here now. Perhaps I was suppose to add the record first, implement the method in kbfs repo, merge it here, then add the RPC in client ...

Please remember to assign it to me as well, otherwise I don't see it in the PRs list view.

Assigned; sorry for missing that in the first place!

@strib hmm so I'll revert the last commit in https://github.com/keybase/client/pull/5521 (i.e. add back the RPC), merge it, and merge this with updated vendor?

nvm just saw your comment there!


[WIP] Add validation rules

I'm not fully done testing that this works correctly.

Hello @marktopper!
This is a very interesting subject, since we can handle it in so different ways.
I was curious for your approach, I see you opted for the extra table, in fact we can gain a lot of features like user/author control, history, etc. But do we really need this?
I'd rater see the JSON approach, with the spatie/translatable. I have a working version of that, but need some time to create a fork. We can work on something together if you want.
Some screen shoots (you can also see the slugify in action):
BREAD

Menu

@akazorg, I think you commented on the wrong PR

Nope, it's the right one. Have to test out the rules work as expected :)


Update transferred_coins documentation

This issue showed the naming could be confusing, so I added a remark.
https://github.com/massalabs/massa-as-sdk/issues/318

@sydhds and @Ben-Rey, I don't seem to be authorized to merge PRs in this repo, If one of you are can you merge it please? ;)


parse_cookie returns empty list if any cookie value contains space character

According to rfc2109 space characters are not allowed in cookie value.
But if we try to parse cookie with some valid items (except one with space character) - empty list will be returned without any cookies at all:
1> yaws_api:parse_cookie("a=b; c=d e; f=g").
[]

For me this behaviours seems too restrictive. Access to some web-ite can fail if somebody installed bad cookie value (e.x. by mistake) and website checks for some session in cookie. This really happened for our website powered by ywas (and ywas_api).
For example, python Cookie module just omits error cookie content after space:
In [1]: import Cookie; Cookie.Cookie("a=b; c=d e; f=g")
Out[1]: <SmartCookie: a='b' c='d' f='g'>

I think python behavior (haven't checked other cookie parsing libs) is more expected by api user.

I'm looking into this issue, but I don't see how Python's Cookie module behavior is desirable, given that in your example cookie c is returned as if everything is OK yet it's given a completely incorrect value. IMO c should just be dropped.

The message is "not to loose all other valid cookies". It is just fine to do anything with invalid cookie because it violates rfc. We can treat it as "undefined behaviour" and do whatever we think is acceptable (ignore cookie value after space as python does, omit this cookie at all, do implicit quoting, etc...)

We also have PECL http v2 sending invalid cookies with extra space at the end:
"session=app@local-123; "

This causes latest yaws to completely ignore that cookie. Would be nice if it was a little more forgiving.

to be fair to PECL, it creates messed up cookie only when asking it to not encode cookies, and we need to do that to allow for the @ in the cookie value, maybe we are using yaws api wrong....

Hi @slobo,
You're right, the parser should be more permissive for this specific case (trailing spaces). I pushed a fix for that. Thanks!


Error when renaming a book

Describe the Bug
If I rename a book and click save, it says:

An Error Occurred
An unknown error occurred

When clicking "Return to Home", all made changes were saved properly. Just the redirect did not work.
Steps to Reproduce

Rename an existing book
Click Save

Expected Behaviour
Redirect with correct renamed book-name
Screenshots or Additional Context
No response
Browser Details
No response
Exact BookStack Version
BookStack v23.02.1
PHP Version
8.1.16
Hosting Environment
Standard apache2 vHost running on a wiki. subdomain. We are using Let's Encrypt for free SSL Encryption.
The apache config file has the following rules:
<Directory /var/www/wiki.domain.tld/public>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
        <IfModule mod_rewrite.c>
                <IfModule mod_negotiation.c>
                        Options -MultiViews -Indexes
                </IfModule>

                RewriteEngine On

                # Handle Authorization Header
                RewriteCond %{HTTP:Authorization} .
                RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

                # Redirect Trailing Slashes If Not A Folder...
                RewriteCond %{REQUEST_FILENAME} !-d
                RewriteCond %{REQUEST_URI} (.+)/$
                RewriteRule ^ %1 [L,R=301]

                # Handle Front Controller...
                RewriteCond %{REQUEST_FILENAME} !-d
                RewriteCond %{REQUEST_FILENAME} !-f
                RewriteRule ^ index.php [L]
        </IfModule>
</Directory>

Hi @david-prv,

Does this still occur if you update your instance to the latest release version of BookStack?
If so, please can you follow our debugging instructions to gain details for this particular error, then share those details.

An update to v23.05.2 fixed it. Damn, that should have been my first step. Thank you and sorry for the inconvenience.


contenttype modifier doesn't match Content-Type headers with parameters

The Content-Type header values can potentially contain parameters after a semicolon, in addition to the media type. Our $contenttype modifier implementation doesn't take that into account.
References:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type

In case anyone wants to work on this, I can walk you through a solution.

I think I can try

@Noahnut thanks for offering help, but it turns out $contenttype determines the type base on requests' Sec-Fetch-Dest header instead of response's Content-Type. The issue is incorrect.


missing logo

Describe the bug
The company logo is missing in the footer of the website, leaving an empty space where the logo should be.
To Reproduce
Steps to reproduce the behavior:
Go to the website's homepage.
Scroll down to the footer section.
Notice that the logo does not appear in the designated area.
Expected behavior
The company logo should be visible in the footer, properly aligned and displayed across all devices.
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@Rizwan102003

@SaurabhS55 and please add the relevant labels for gssoc

@pulkitpathak99

I have assigned this issue to you!! @Pragati1466

ok will solve by tommorow

If this issue is not solved till now, kindly assign it to me please as i saw the logo is still missing in learning and registration page.
@pulkitpathak99

@Pragati1466 @shivhere007 the logo is currently working

@Rizwan102003 but could you please refrence which issue solved it I took the issue first submitted the pr at time then why not accepted and at the time i submitted pr logo was still not there and even when the other person messaged and i submiteed pr befoe that thats violating rules pls see to it

I solved this issue 2 days ago and the other person message 16 hours ago that the issue is still not solved then why my pr is not accepted

@pulkitpathak99

@Pragati1466 We currently have 5 members assigning the issues and merging the pr's. It may be that an issue got created by 2 different contributors and got assigned to them by different mentors. Kindly provide us the issue numbers in question so that we can look into it and resolve the issue.

@Pragati1466 there are still a lot of improvements required on the website. You can work on other issues and raise a PR on it.


[deu] Split into Swiss German and Germany German. [nep] removes a duplicate from languages.json

[x] Updated Unreleased in CHANGELOG.md to reflect the changes in code or data.

ger is split into Swiss German and Germany German.
Nep duplicate is removed from languages.json

Hi Yeonju, this looks good to me.
Can you run the scrape for these languages in your branch to see how this affects the counts? I think you'd follow the instructions here:
https://github.com/kylebgorman/wikipron#repository
then you'd navigate to data/src and run ./scrape --restriction=ger && ./postprocess && ./generate_summary.

Ok! I will work on that :)
Yeonju
On Tue, Dec 15, 2020 at 3:23 PM Kyle Gorman<EMAIL_ADDRESS>wrote:

Hi Yeonju, this looks good to me.
Can you run the scrape for these languages in your branch to see how this
affects the counts? I think you'd follow the instructions here:
https://github.com/kylebgorman/wikipron#repository
then you'd navigate to data/src and run ./scrape --restriction=ger &&
./postprocess && ./generate_summary.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kylebgorman/wikipron/pull/286#issuecomment-745545106,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKKPU5EWFSJDFRXFC5IOII3SU7ATJANCNFSM4U45FI4A
.

Just in the interest of getting rid of old bugs, etc., I looked into this and it seems to now be out of date. We have support for gsw, and so there are there are only three words which would be affected by this,and two of them are MWEs. Closing for now.


Update CircleCI config template

Update to the current version based on ansible-prometheus.
Signed-off-by: SuperQ<EMAIL_ADDRESS>

CC @sdarwin


edgetext can not click

in version 9.5.3, the edgetext can not to click, only the path is clickable, not the rect

send your code please

I did some changes recently. What is not working for you @nfwyst ?

here is my use case:
<>
      <path
        id={id}
        style={{ ...style, borderRadius: '50%' }}
        className="react-flow__edge-path cursor-pointer"
        d={edgePath}
        markerEnd={markerEnd}
        onDragOver={onDragOver}
      />
      <EdgeText
        x={centerX}
        y={centerY}
        onDragOver={onDragOver}
        label={label}
        onClick={(e) => {
          e.stopPropagation();
          updateStore(null, () => ({
            asideDrawerType: 'components',
            currentConnection: {
              source,
              target,
              position: { x: centerX, y: centerY },
            },
          }));
        }}
        labelBgBorderRadius={14}
        width="28"
        height="28"
      />
    </>

Hey,
I can't reproduce this issue. The onClick handler works as expected. When you do e.stopPropagation() the edge is not getting selected. But that's why you added it, right?


jsone is not an application that needs starting

Not sure you should put jsone in the app.src file under applications.

Actually you need to for it to be picked up by the release generation tool (systool, reltool, relx...).
The applications field lists the dependencies whether they need starting or not.

Yeah that's one of the side effects of that field but you can't use it for libraries anyway. This is the documentation: http://erlang.org/doc/man/app.html
applications
All applications that must be started before this application is allowed to be started. systools uses this list to generate correct start scripts. Defaults to the empty list, but notice that all applications have dependencies to (at least) Kernel and STDLIB.

jsone is not an application that must be started and if you leave it there it's going to fail boot because it can't be started. And this is the result of launching it:
Erlang/OTP 19 [erts-8.3] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

Eshell V8.3  (abort with ^G)
1> application:start(raven).
{error,{not_started,jsone}}

You are supposed to use:
application:ensure_all_started/1


Cleanup

Removed CmdAsync

Took a quick look, seems fine.
@wz1000, merge it once the CI result is ok.

Thanks


ZeroTier DNS not working on Windows but working perfectly on Linux

So here is my setup
I have 2 machines: one is my personal Server running Debian 10 with nginx/php/mysql and samba, let's call it deb-srv, and the other is my Laptop, which is installed with Linux Mint 20.1 together with Windows 10 Home (dual systems, not on VM) and is under another physical sub network.
I have ZeroTier and zeronsd installed and configured on deb-srv using intra.mydomain.com, and all 3 systems joined in the same ZeroTier network (so there are 3 nodes under the network, but always up to 2 nodes are online), for which I have verified by connecting via ZeroTier Intranet IPs.
I CAN connect to deb-srv using intra.mydomain.com (ping, ssh, http/https, samba) from my Laptop when under Linux Mint, but if I reboot to Windows on the same laptop (still under the same physical network), I can only connect to deb-srv using the ZeroTier Intranet IP but not intra.mydomain.com.
I have confirmed on either GUI and command line (powershell) that allowDNS is TRUE for the Windows client, and I have tried to restart the whole Windows system and the windows ZeroTier-One client for several times, but still not working.
Also I tried to set manually again by zerotier-cli set network-id allowDNS=1, as well as un-check and re-check the allowDNS checkbox and restart the client - still no hope
I also tried under Administrator to ipconfig /flushdns as well as Clear-DnsClientCache and then reboot the system - still no hope...
I also tried to quit from the ZeroTier network from Windows and re-join, still nothing changed...
Under Windows on the Laptop:

ping intra.mydomain.com
Ping request could not find host intra.mydomain.com. Please check the name and try again.

ping 172.30..

Pinging 172.30.. with 32 bytes of data:
Reply from 172.30..: bytes=32 time=27ms TTL=64
Reply from 172.30..: bytes=32 time=27ms TTL=64

Hello. Is the Windows VM on a domain? Check here https://discuss.zerotier.com/t/new-dns-features-dont-appear-to-work/982/5

The Windows is on the same physical PC with my Linux (Dual Systems)

so both machines are named intra? and each has their own, independent identity?
that's basically a collision. we don't support that at the moment, largely for this reason.
If you want to clone the identity between the windows and linux pcs so they are -- in the eyes of zerotier -- the same machine, that would almost certainly work.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, August 4th, 2021 at 12:55 PM, wxrl @.***> wrote:

So here is my setup
I have 2 machines: one is my personal Server running Debian 10 with nginx/php/mysql and samba, let's call it deb-srv, and the other is my Laptop, which is installed with Linux Mint 20.1 together with Windows 10 Home (dual systems, not on VM) and is under another physical sub network.
I have ZeroTier and zeronsd installed and configured on deb-srv using intra.mydomain.com, and all 3 systems joined in the same ZeroTier network (so there are 3 nodes under the network, but always up to 2 nodes are online), for which I have verified by connecting via ZeroTier Intranet IPs.
I CAN connect to deb-srv using intra.mydomain.com (ping, ssh, http/https, samba) from my Laptop when under Linux Mint, but if I reboot to Windows on the same laptop (still under the same physical network), I can only connect to deb-srv using the ZeroTier Intranet IP but not intra.mydomain.com.
I have confirmed on either GUI and command line (powershell) that allowDNS is TRUE for the Windows client, and I have tried to restart the whole Windows system and the windows ZeroTier-One client for several times, but still not working.
Also I tried to set manually again by zerotier-cli set network-id allowDNS=1, as well as un-check and re-check the allowDNS checkbox and restart the client - still no hope
I also tried under Administrator to ipconfig /flushdns as well as Clear-DnsClientCache and then reboot the system - still no hope...
I also tried to quit from the ZeroTier network from Windows and re-join, still nothing changed...
Under Windows on the Laptop:

ping intra.mydomain.com
Ping request could not find host intra.mydomain.com. Please check the name and try again.

ping 172.30..

Pinging 172.30.. with 32 bytes of data:
Reply from 172.30..: bytes=32 time=27ms TTL=64
Reply from 172.30..: bytes=32 time=27ms TTL=64

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

No.  The intra is only the name for my Debian Server (which is another physical machine).
I mean I have client_linux and client_windows on another dual boot machine. And from client_linux on this machine, I can visit intra.mydomain.com (to my Debian Server) without problem, but if I reboot to client_windows on this same machine it doesn't recognize intra.mydomain.com (Although I can access the Debian Server via the zerotier virtual IP)

so both machines are named intra? and each has their own, independent identity? that's basically a collision. we don't support that at the moment, largely for this reason. If you want to clone the identity between the windows and linux pcs so they are -- in the eyes of zerotier -- the same machine, that would almost certainly work. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
…
On Wednesday, August 4th, 2021 at 12:55 PM, wxrl @.***> wrote: So here is my setup I have 2 machines: one is my personal Server running Debian 10 with nginx/php/mysql and samba, let's call it deb-srv, and the other is my Laptop, which is installed with Linux Mint 20.1 together with Windows 10 Home (dual systems, not on VM) and is under another physical sub network. I have ZeroTier and zeronsd installed and configured on deb-srv using intra.mydomain.com, and all 3 systems joined in the same ZeroTier network (so there are 3 nodes under the network, but always up to 2 nodes are online), for which I have verified by connecting via ZeroTier Intranet IPs. I CAN connect to deb-srv using intra.mydomain.com (ping, ssh, http/https, samba) from my Laptop when under Linux Mint, but if I reboot to Windows on the same laptop (still under the same physical network), I can only connect to deb-srv using the ZeroTier Intranet IP but not intra.mydomain.com. I have confirmed on either GUI and command line (powershell) that allowDNS is TRUE for the Windows client, and I have tried to restart the whole Windows system and the windows ZeroTier-One client for several times, but still not working. Also I tried to set manually again by zerotier-cli set network-id allowDNS=1, as well as un-check and re-check the allowDNS checkbox and restart the client - still no hope I also tried under Administrator to ipconfig /flushdns as well as Clear-DnsClientCache and then reboot the system - still no hope... I also tried to quit from the ZeroTier network from Windows and re-join, still nothing changed... Under Windows on the Laptop: > ping intra.mydomain.com > Ping request could not find host intra.mydomain.com. Please check the name and try again. > ping 172.30.. > Pinging 172.30.. with 32 bytes of data: > Reply from 172.30..: bytes=32 time=27ms TTL=64 > Reply from 172.30..: bytes=32 time=27ms TTL=64 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.


<PINRemoteImage/PINRemoteImageCaching.h> file not found

Installed with pod

but with manually installing, worked!

no one?

@CavalcanteLeo can you possibly give a bit more info?

Let me know if you have any more information to add, I'll re-open the issue.

Sure, I installed PINRemoteImage with cocoapods.
But the pod folder doesn't have all files that the project have.
Should have all those files: https://github.com/pinterest/PINRemoteImage/tree/master/Pod/Classes
instead, have only the print above

@CavalcanteLeo what version of cocoa pods (pod --version) do you have? Can you post your Podfile?

pod 'PINRemoteImage', '2.1.4'

also tried with 3 beta

i friend ( @leonardo-ferreira07 ) of mine had the same issue

cocoa pods version 1.0.1

@CavalcanteLeo I just created a new test project with Xcode and a podfile (I also tried 2.1.4) on cocoa pods 1.0.1:
target 'test-pinremoteimage' do
  pod 'PINRemoteImage', '3.0.0-beta.3'
end

Both compiled fine for me. Are you sure you have the .xcworkspace open and not the .xcproject?

hehe, of course, it's an old project, with a lot of pods, i just switched from SDWebImage to PINRemoteImage

@garrettmoon yeah, this compiled fine for us too. But, @CavalcanteLeo have a doubt if this class is used or not by the library, and in the main if this class is used to do a progressive loading.

I can't import the class PINRemoteImageCaching

Ohhh, I see, you're trying to import PINRemoteImageCaching.h but you're not able to because it's not exposed via cocoa pods, that's the issue?

Yep, i tried to reproduce this example:
https://github.com/pinterest/PINRemoteImage/blob/master/Example/PINRemoteImage/ProgressiveViewController.m

@CavalcanteLeo @leonardo-ferreira07
Ahh, ok, that file isn't in a release yet, it's only in master. Take a look at the Example in the actual repro that you're using:
https://github.com/pinterest/PINRemoteImage/blob/3.0.0-beta.3/Example/PINRemoteImage/ProgressiveViewController.m

damn, just got confused between the branches.. lol 😰  😰
Thank you @garrettmoon, and can't wait for the immutable data model open source

No worries :) (immutable data model is coming… higher priority things have been prevailing 😀)


Update vsc-dark-plus.js

Update theme to match the changes in my pull request:
Ref: https://github.com/PrismJS/prism-themes/pull/103

Hey @karlhorky, really appreciate this PR!
However, we autogenerate this theme file from the prism-themes package at build time (in order to provide the "light" build option), so we'll need to wait for a new release of prism-themes to drop in order to pick up your changes in RSH.
I've subscribed to your PR over there, and will keep an eye out for the next prism-theme release.

Ok, sounds good, it was merged! I guess will be released somewhat soon.
Thanks!


[SPARK-21837][SQL][TESTS] UserDefinedTypeSuite local UDFs not actually testing what it intends

What changes were proposed in this pull request?
Adjust Local UDTs test to assert about results, and fix index of vector column. See JIRA for details.
How was this patch tested?
Existing tests.

Test build #81130 has started for PR 19053 at commit f502f4f.

Test build #81130 has finished for PR 19053 at commit f502f4f.

This patch fails SparkR unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81130/
Test FAILed.

Merged build finished. Test FAILed.

Test build #3903 has started for PR 19053 at commit f502f4f.

UDF?

Oops, I meant UDT. Just referring to the tests name in the code.

LGTM except one comment.

Test build #3903 has finished for PR 19053 at commit f502f4f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #81137 has started for PR 19053 at commit a80c79a.

LGTM

Test build #81137 has finished for PR 19053 at commit a80c79a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81137/
Test PASSed.

Thanks! Merging to master.


Documentation update: generate_if cases

Dear SAP InfraBox community,
I looked thru the docs but couldn't find examples or guides on how to use the generate_if statements in order to control how/when a job gets generated. Is there a place where I can find these and I may have missed it? I was looking for it in order to determine how to setup jobs to run only on specific events like on merge to certain branch patterns. I did find some examples coming from other repositories, but I believe it'd be great to have it on the docs section of this project.
Let me know if I can be of any help and I'll submit a PR.
An example I found was:
"generate_if": [
    {   "after_release": true },
    {   "matches_pattern": [
            "*.go",
            "infrabox/go-mod/*"
        ]
    },
    {   "cronjobs": [ "daily*" ] }
]

but what are other key words and settings I can use this section?
Thanks!

The generate_if is a keyword in generator framework. It's not from infrabox.


Add e2e test of external function linking for ipu target

Add a test for calling external function from air.herd for the ipu xrt target.
issues / work in progress:

It seems to require -air-dma-to-channel -air-dependency, in that order, which is not the usual order.
The external function declaration gets duplicated during lowering, leading to error. Fixing this by hand gives PASS!

The external function declaration gets duplicated during lowering, leading to error. Fixing this by hand gives PASS!

Workaround by adding -symbol-dce

It seems to require -air-dma-to-channel -air-dependency, in that order, which is not the usual order.

@erwei-xilinx fyi, It doesn't seem to generate the shim allocation metadata correctly without this ordering or without the air-dependency. It also fails without a canonicalization between the dma-to-channel and air-dependency passes:
error: 'scf.parallel' op currently only supporting input scf::ParallelOp with no reductions

@erwei-xilinx fyi, It doesn't seem to generate the shim allocation metadata correctly without this ordering or without the air-dependency. It also fails without a canonicalization between the dma-to-channel and air-dependency passes:

Thanks for identifying the issues. Let me take a look.


How to customize WebauthnRegister (webauthn-register.ftl) using Keycloaktify?

I want to custom webauthn-register.ftl using React Keycloaktify, but in Keycloaktify does not yet provide a custom webauthn-register.ftl

Hello @muhammadaskar,
For pages that are not yet supported we provide two path:

Add support for the missing page in your project
Submitting a pull request to Keycloakify (It's quite straightforward and it would benefit the community)

It's explained here: https://docs.keycloakify.dev/limitations#some-pages-still-have-the-default-theme.-why
You can join us on discord if you need assistance: https://discord.gg/kYFZG7fQmn

Hello @garronej ,
Thanks for quick response. I will try


test: create test for tx_executor

This change is

Codecov Report
Attention: Patch coverage is 0% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 73.01%. Comparing base (6e817fe) to head (6898abf).
Report is 3 commits behind head on main.

Files
Patch %
Lines

crates/blockifier/src/blockifier/bouncer.rs
0.00%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1625      +/-   ##
==========================================
+ Coverage   70.16%   73.01%   +2.84%
==========================================
  Files          59       59
  Lines        8330     8331       +1
  Branches     8330     8331       +1
==========================================
+ Hits         5845     6083     +238
+ Misses       2012     1768     -244
- Partials      473      480       +7

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

crates/blockifier/src/blockifier/transaction_executor_test.rs line 46 at r3 (raw file):

}

fn l1_handler_for_test(

WDYT about moving it to crates/blockifier/src/transaction/transactions.rs or to add an impl block for L1HandlerTransaction with fn create_for_testing?
Code quote:
fn l1_handler_for_test(

crates/blockifier/src/blockifier/transaction_executor_test.rs line 84 at r3 (raw file):
Is it some kind of a convention? not sure I understand how it helps to read the test (:

crates/blockifier/src/blockifier/transaction_executor_test.rs line 87 at r3 (raw file):
Can you explain why you used ZERO above and you suggest to  consider ONE?
Code quote:
// TODO: consider TransactionVersion::ONE.

crates/blockifier/src/blockifier/transaction_executor_test.rs line 91 at r3 (raw file):
I'm not familiar with that, what does it do? and why it's an argument?
Code quote:
#[values(true)]

crates/blockifier/src/blockifier/transaction_executor_test.rs line 100 at r3 (raw file):
WDYT about something like that:
Suggestion:
    let mut tx_executor = TransactionExecutor::create_for_testing(...);

crates/blockifier/src/blockifier/transaction_executor_test.rs line 110 at r3 (raw file):
Possible to remove tx_type and version from the test args and to put tx: Transaction instead? So we can remove this match expression:

crates/blockifier/src/blockifier/transaction_executor_test.rs line 112 at r3 (raw file):
Don't we want to test it too?
Code quote:
_tx_execution_info

crates/blockifier/src/blockifier/bouncer.rs line 11 at r3 (raw file):

#[derive(Clone, Default)]
#[cfg_attr(test, derive(Eq, PartialEq, Debug))]

I'm not familiar with that, can you explain what the cfg_attr and the test do? and why the derives split between lines 10 and 11?
Code quote:
#[cfg_attr(test, derive(Eq, PartialEq, Debug))]

crates/blockifier/src/blockifier/bouncer.rs line 11 at r3 (raw file):
Previously, giladchase wrote…
That being said, i think Debug can easily be part of the regular derive, it's almost always Good to have.
Also partialEq and Eq are generally OK, is there a correctness issue in exposing them to users?

Since BouncerInfo holds usizes and a VmExecutionResources, which all have those derivations:
Suggestion:
#[derive(Clone, Debug, Default, Eq, PartialEq)]

crates/blockifier/src/blockifier/bouncer.rs line 11 at r3 (raw file):
Previously, barak-b-starkware wrote…
Since BouncerInfo holds usizes and a VmExecutionResources, which all have those derivations:

Thanks for the explanation (:

crates/blockifier/src/blockifier/bouncer.rs line 11 at r3 (raw file):
Previously, barak-b-starkware wrote…
Thanks for the explanation (:

Done.

crates/blockifier/src/blockifier/transaction_executor_test.rs line 75 at r8 (raw file):
Previously, Yoni-Starkware (Yoni) wrote…
Please refrain from hard-coding unstable numbers (gas_weight, n_steps, builtins)
state_diff_size,  message_segment_length,  n_events are okay.
You can use the execution_info (which is not tested here) to bound/calculate the unstable fields

Done.
The fields from BouncerInfo which are not checked here are: gas_weight and execution_resources.

crates/blockifier/src/blockifier/transaction_executor_test.rs line 75 at r8 (raw file):
Previously, ArniStarkware (Arnon Hod) wrote…
Done.
The fields from BouncerInfo which are not checked here are: gas_weight and execution_resources.

Do we want to add a todo?

crates/blockifier/src/blockifier/transaction_executor_test.rs line 75 at r8 (raw file):
Previously, Yoni-Starkware (Yoni) wrote…
Yes :)

Done.

crates/blockifier/src/blockifier/transaction_executor_test.rs line 67 at r11 (raw file):
Previously, Yoni-Starkware (Yoni) wrote…
@barak-b-starkware I don't want the test to fail upon every compiler/code/os change
We should test things like steps in a more robust way

for the record, @barak-b-starkware wanted to say this here:
Got it, I suggest extending this TODO so it will be more informative, something like "Test unstable number: gas_weight and.." or something