Cannot continue update after build failure?

Describe the bug
After a build failure, .\vcpkg uprade does not work, I suppose.
Environment

OS: Windows
Compiler: Visual Studio 2017

Expected behavior
The second time .\vcpkg upgrade --no-dry-run should restart downloading and updating.
Additional context
The console session:
C:\work\Projects\vcpkg>.\vcpkg upgrade --no-dry-run
The following packages will be rebuilt:
  * abseil[core]:x86-windows -> 2020-09-23#3
  * boost[core]:x86-windows -> 1.75.0
  * boost-asio[core]:x86-windows -> 1.75.0#1
  * boost-beast[core]:x86-windows -> 1.75.0
  * boost-context[core]:x86-windows -> 1.75.0#2
  * boost-coroutine[core]:x86-windows -> 1.75.0
  * boost-coroutine2[core]:x86-windows -> 1.75.0
  * boost-fiber[core]:x86-windows -> 1.75.0
  * boost-log[core]:x86-windows -> 1.75.0
  * boost-parameter-python[core]:x86-windows -> 1.75.0
  * boost-process[core]:x86-windows -> 1.75.0
  * boost-python[core]:x86-windows -> 1.75.0#1
  * grpc[core]:x86-windows -> 1.33.1#2
  * openssl[core]:x86-windows -> 1.1.1j
  * python3[core]:x86-windows -> 3.9.2
  * sqlite3[core]:x86-windows -> 3.35.0
Additional packages (*) will be modified to complete this operation.
Starting package 1/32: grpc:x86-windows
Removing package grpc:x86-windows...
Removing package grpc:x86-windows... done
Elapsed time for package grpc:x86-windows: 719.6 ms
Starting package 2/32: abseil:x86-windows
Removing package abseil:x86-windows...
Removing package abseil:x86-windows... done
Elapsed time for package abseil:x86-windows: 759.7 ms
Starting package 3/32: boost:x86-windows
Removing package boost:x86-windows...
Removing package boost:x86-windows... done
Elapsed time for package boost:x86-windows: 8.586 ms
Starting package 4/32: boost-beast:x86-windows
Removing package boost-beast:x86-windows...
Removing package boost-beast:x86-windows... done
Elapsed time for package boost-beast:x86-windows: 268.5 ms
Starting package 5/32: boost-log:x86-windows
Removing package boost-log:x86-windows...
Removing package boost-log:x86-windows... done
Elapsed time for package boost-log:x86-windows: 307.5 ms
Starting package 6/32: boost-process:x86-windows
Removing package boost-process:x86-windows...
Removing package boost-process:x86-windows... done
Elapsed time for package boost-process:x86-windows: 137.1 ms
Starting package 7/32: boost-asio:x86-windows
Removing package boost-asio:x86-windows...
Removing package boost-asio:x86-windows... done
Elapsed time for package boost-asio:x86-windows: 591.5 ms
Starting package 8/32: boost-coroutine2:x86-windows
Removing package boost-coroutine2:x86-windows...
Removing package boost-coroutine2:x86-windows... done
Elapsed time for package boost-coroutine2:x86-windows: 46.74 ms
Starting package 9/32: boost-coroutine:x86-windows
Removing package boost-coroutine:x86-windows...
Removing package boost-coroutine:x86-windows... done
Elapsed time for package boost-coroutine:x86-windows: 71.51 ms
Starting package 10/32: boost-fiber:x86-windows
Removing package boost-fiber:x86-windows...
Removing package boost-fiber:x86-windows... done
Elapsed time for package boost-fiber:x86-windows: 92.42 ms
Starting package 11/32: boost-context:x86-windows
Removing package boost-context:x86-windows...
Removing package boost-context:x86-windows... done
Elapsed time for package boost-context:x86-windows: 56.06 ms
Starting package 12/32: boost-parameter-python:x86-windows
Removing package boost-parameter-python:x86-windows...
Removing package boost-parameter-python:x86-windows... done
Elapsed time for package boost-parameter-python:x86-windows: 22.44 ms
Starting package 13/32: boost-python:x86-windows
Removing package boost-python:x86-windows...
Removing package boost-python:x86-windows... done
Elapsed time for package boost-python:x86-windows: 240.3 ms
Starting package 14/32: python3:x86-windows
Removing package python3:x86-windows...
Removing package python3:x86-windows... done
Elapsed time for package python3:x86-windows: 4.152 s
Starting package 15/32: openssl:x86-windows
Removing package openssl:x86-windows...
Removing package openssl:x86-windows... done
Elapsed time for package openssl:x86-windows: 326.1 ms
Starting package 16/32: sqlite3:x86-windows
Removing package sqlite3:x86-windows...
Removing package sqlite3:x86-windows... done
Elapsed time for package sqlite3:x86-windows: 30.71 ms
Detecting compiler hash for triplet x86-windows...

-- Downloading https://github.com/abseil/abseil-cpp/archive/6f9d96a1f41439ac172ee2ef7ccd8edf0e5d068c.tar.gz -> abseil-abseil-cpp-6f9d96a1f41439ac172ee2ef7ccd8edf0e5d068c.tar.gz...
-- Extracting source C:/work/Projects/vcpkg/downloads/abseil-abseil-cpp-6f9d96a1f41439ac172ee2ef7ccd8edf0e5d068c.tar.gz
-- Applying patch fix-cxx-standard.patch
-- Applying patch fix-msvc-flags.patch
-- Using source at C:/work/Projects/vcpkg/buildtrees/abseil/src/df0e5d068c-e45371f367.clean
CMake Deprecation Warning at scripts/cmake/vcpkg_check_features.cmake:182 (message):
  calling `vcpkg_check_features` without the `FEATURES` keyword has been
  deprecated.

      Please add the `FEATURES` keyword to the call.
Call Stack (most recent call first):
  ports/abseil/portfile.cmake:22 (vcpkg_check_features)
  scripts/ports.cmake:142 (include)

-- Configuring x86-windows-dbg
-- Configuring x86-windows-rel
-- Building x86-windows-dbg
-- Building x86-windows-rel
-- Installing: C:/work/Projects/vcpkg/packages/abseil_x86-windows/share/abseil/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\myname\AppData\Local\vcpkg\archives\27\27849fc685c48a4501b02093132ba8c3fab4a95c.zip
Building package abseil[core]:x86-windows... done
Installing package abseil[core]:x86-windows...
Installing package abseil[core]:x86-windows... done
Elapsed time for package abseil:x86-windows: 1.563 min
Starting package 18/32: boost-context:x86-windows
Building package boost-context[core]:x86-windows...
-- Using cached C:/work/Projects/vcpkg/downloads/boostorg-context-boost-1.75.0.tar.gz
-- Extracting source C:/work/Projects/vcpkg/downloads/boostorg-context-boost-1.75.0.tar.gz
-- Applying patch fix_exports_for_32bit_GNU_asm_for_windows.patch
-- Using source at C:/work/Projects/vcpkg/buildtrees/boost-context/src/ost-1.75.0-f345d4f780.clean
-- Including C:/work/Projects/vcpkg/buildtrees/boost-context/vcpkg-b2-options.cmake
-- Building x86-windows-rel
-- Building x86-windows-rel done
-- Building x86-windows-dbg
-- Building x86-windows-dbg done
-- Packaging x86-windows-rel
-- Packaging x86-windows-rel done
-- Packaging x86-windows-dbg
-- Packaging x86-windows-dbg done
-- Installing: C:/work/Projects/vcpkg/packages/boost-context_x86-windows/share/boost-context/usage
-- Packaging headers
-- Packaging headers done
-- Using cached C:/work/Projects/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Up-to-date: C:/work/Projects/vcpkg/packages/boost-context_x86-windows/share/boost-context/usage
-- Installing: C:/work/Projects/vcpkg/packages/boost-context_x86-windows/share/boost-context/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\myname\AppData\Local\vcpkg\archives\b4\b45aeba834f753e6bbcdeb52632b2115e6e46ef9.zip
Building package boost-context[core]:x86-windows... done
Installing package boost-context[core]:x86-windows...
Installing package boost-context[core]:x86-windows... done
Elapsed time for package boost-context:x86-windows: 13.06 s
Starting package 19/32: boost-coroutine:x86-windows
Building package boost-coroutine[core]:x86-windows...
-- Using cached C:/work/Projects/vcpkg/downloads/boostorg-coroutine-boost-1.75.0.tar.gz
-- Extracting source C:/work/Projects/vcpkg/downloads/boostorg-coroutine-boost-1.75.0.tar.gz
-- Using source at C:/work/Projects/vcpkg/buildtrees/boost-coroutine/src/ost-1.75.0-1e997afe30.clean
-- Building x86-windows-rel
-- Building x86-windows-rel done
-- Building x86-windows-dbg
-- Building x86-windows-dbg done
-- Packaging x86-windows-rel
-- Packaging x86-windows-rel done
-- Packaging x86-windows-dbg
-- Packaging x86-windows-dbg done
-- Installing: C:/work/Projects/vcpkg/packages/boost-coroutine_x86-windows/share/boost-coroutine/usage
-- Packaging headers
-- Packaging headers done
-- Using cached C:/work/Projects/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Up-to-date: C:/work/Projects/vcpkg/packages/boost-coroutine_x86-windows/share/boost-coroutine/usage
-- Installing: C:/work/Projects/vcpkg/packages/boost-coroutine_x86-windows/share/boost-coroutine/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\myname\AppData\Local\vcpkg\archives\84\84571bd560cbd365e96b8c1c845d43a6c4f114ef.zip
Building package boost-coroutine[core]:x86-windows... done
Installing package boost-coroutine[core]:x86-windows...
Installing package boost-coroutine[core]:x86-windows... done
Elapsed time for package boost-coroutine:x86-windows: 17.52 s
Starting package 20/32: openssl:x86-windows
Building package openssl[core]:x86-windows...
-- Downloading https://www.openssl.org/source/openssl-1.1.1j.tar.gz -> openssl-1.1.1j.tar.gz...
-- Extracting source C:/work/Projects/vcpkg/downloads/openssl-1.1.1j.tar.gz
-- Using source at C:/work/Projects/vcpkg/buildtrees/openssl/src/openssl-1-ff1006361a.clean
-- Copying openssl release source files...
-- Copying openssl release source files... done
-- Configure x86-windows-rel
-- Configure x86-windows-rel done
-- Build x86-windows-rel
-- Build x86-windows-rel done
-- Copying openssl debug source files...
-- Copying openssl debug source files... done
-- Configure x86-windows-dbg
-- Configure x86-windows-dbg done
-- Build x86-windows-dbg
-- Build x86-windows-dbg done
-- Installing: C:/work/Projects/vcpkg/packages/openssl_x86-windows/share/openssl/copyright
-- Installing: C:/work/Projects/vcpkg/packages/openssl_x86-windows/share/openssl/usage
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\myname\AppData\Local\vcpkg\archives\50\50bc828f27a35171147bc516b2b2c33144bfb9bb.zip
Building package openssl[core]:x86-windows... done
Installing package openssl[core]:x86-windows...
Installing package openssl[core]:x86-windows... done
Elapsed time for package openssl:x86-windows: 6.814 min
Starting package 21/32: boost-asio:x86-windows
Building package boost-asio[core]:x86-windows...
-- Using cached C:/work/Projects/vcpkg/downloads/boostorg-asio-boost-1.75.0.tar.gz
-- Extracting source C:/work/Projects/vcpkg/downloads/boostorg-asio-boost-1.75.0.tar.gz
-- Applying patch windows_alloca_header.patch
-- Applying patch inline_dummy_return.patch
-- Using source at C:/work/Projects/vcpkg/buildtrees/boost-asio/src/ost-1.75.0-6c20b39bd7.clean
-- Packaging headers
-- Packaging headers done
-- Using cached C:/work/Projects/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: C:/work/Projects/vcpkg/packages/boost-asio_x86-windows/share/boost-asio/usage
-- Installing: C:/work/Projects/vcpkg/packages/boost-asio_x86-windows/share/boost-asio/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\myname\AppData\Local\vcpkg\archives\c9\c95f6b9050cacbfb935ccec5b7a9e2ff98d89b07.zip
Building package boost-asio[core]:x86-windows... done
Installing package boost-asio[core]:x86-windows...
Installing package boost-asio[core]:x86-windows... done
Elapsed time for package boost-asio:x86-windows: 9.212 s
Starting package 22/32: boost-beast:x86-windows
Building package boost-beast[core]:x86-windows...
-- Using cached C:/work/Projects/vcpkg/downloads/boostorg-beast-boost-1.75.0.tar.gz
-- Extracting source C:/work/Projects/vcpkg/downloads/boostorg-beast-boost-1.75.0.tar.gz
-- Using source at C:/work/Projects/vcpkg/buildtrees/boost-beast/src/ost-1.75.0-59397af2dd.clean
-- Packaging headers
-- Packaging headers done
-- Using cached C:/work/Projects/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: C:/work/Projects/vcpkg/packages/boost-beast_x86-windows/share/boost-beast/usage
-- Installing: C:/work/Projects/vcpkg/packages/boost-beast_x86-windows/share/boost-beast/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\myname\AppData\Local\vcpkg\archives\4e\4ecbe7f7d5bd3369003c9424efd8fc8eb041a13c.zip
Building package boost-beast[core]:x86-windows... done
Installing package boost-beast[core]:x86-windows...
Installing package boost-beast[core]:x86-windows... done
Elapsed time for package boost-beast:x86-windows: 5.044 s
Starting package 23/32: boost-coroutine2:x86-windows
Building package boost-coroutine2[core]:x86-windows...
-- Using cached C:/work/Projects/vcpkg/downloads/boostorg-coroutine2-boost-1.75.0.tar.gz
-- Extracting source C:/work/Projects/vcpkg/downloads/boostorg-coroutine2-boost-1.75.0.tar.gz
-- Using source at C:/work/Projects/vcpkg/buildtrees/boost-coroutine2/src/ost-1.75.0-9000c4ec63.clean
-- Packaging headers
-- Packaging headers done
-- Using cached C:/work/Projects/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: C:/work/Projects/vcpkg/packages/boost-coroutine2_x86-windows/share/boost-coroutine2/usage
-- Installing: C:/work/Projects/vcpkg/packages/boost-coroutine2_x86-windows/share/boost-coroutine2/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\myname\AppData\Local\vcpkg\archives\e8\e8a8da0018b59098eeae189aedb61044aeae13b3.zip
Building package boost-coroutine2[core]:x86-windows... done
Installing package boost-coroutine2[core]:x86-windows...
Installing package boost-coroutine2[core]:x86-windows... done
Elapsed time for package boost-coroutine2:x86-windows: 859.6 ms
Starting package 24/32: boost-fiber:x86-windows
Building package boost-fiber[core]:x86-windows...
-- Using cached C:/work/Projects/vcpkg/downloads/boostorg-fiber-boost-1.75.0.tar.gz
-- Extracting source C:/work/Projects/vcpkg/downloads/boostorg-fiber-boost-1.75.0.tar.gz
-- Using source at C:/work/Projects/vcpkg/buildtrees/boost-fiber/src/ost-1.75.0-f0d75ae32d.clean
-- Building x86-windows-rel
-- Building x86-windows-rel done
-- Building x86-windows-dbg
-- Building x86-windows-dbg done
-- Packaging x86-windows-rel
-- Packaging x86-windows-rel done
-- Packaging x86-windows-dbg
-- Packaging x86-windows-dbg done
-- Installing: C:/work/Projects/vcpkg/packages/boost-fiber_x86-windows/share/boost-fiber/usage
-- Packaging headers
-- Packaging headers done
-- Using cached C:/work/Projects/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Up-to-date: C:/work/Projects/vcpkg/packages/boost-fiber_x86-windows/share/boost-fiber/usage
-- Installing: C:/work/Projects/vcpkg/packages/boost-fiber_x86-windows/share/boost-fiber/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\myname\AppData\Local\vcpkg\archives\8c\8c04836b7e8153d7fcdcc58129895e5c868379d0.zip
Building package boost-fiber[core]:x86-windows... done
Installing package boost-fiber[core]:x86-windows...
Installing package boost-fiber[core]:x86-windows... done
Elapsed time for package boost-fiber:x86-windows: 39.36 s
Starting package 25/32: boost-log:x86-windows
Building package boost-log[core]:x86-windows...
-- Using cached C:/work/Projects/vcpkg/downloads/boostorg-log-boost-1.75.0.tar.gz
-- Extracting source C:/work/Projects/vcpkg/downloads/boostorg-log-boost-1.75.0.tar.gz
-- Using source at C:/work/Projects/vcpkg/buildtrees/boost-log/src/ost-1.75.0-9304fa3736.clean
-- Building x86-windows-rel
-- Building x86-windows-rel done
-- Building x86-windows-dbg
-- Building x86-windows-dbg done
-- Packaging x86-windows-rel
-- Packaging x86-windows-rel done
-- Packaging x86-windows-dbg
-- Packaging x86-windows-dbg done
-- Installing: C:/work/Projects/vcpkg/packages/boost-log_x86-windows/share/boost-log/usage
-- Packaging headers
-- Packaging headers done
-- Using cached C:/work/Projects/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Up-to-date: C:/work/Projects/vcpkg/packages/boost-log_x86-windows/share/boost-log/usage
-- Installing: C:/work/Projects/vcpkg/packages/boost-log_x86-windows/share/boost-log/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: C:\Users\myname\AppData\Local\vcpkg\archives\47\47553799f6cb466772bcb65b0aee390c7d51c684.zip
Building package boost-log[core]:x86-windows... done
Installing package boost-log[core]:x86-windows...
Installing package boost-log[core]:x86-windows... done
Elapsed time for package boost-log:x86-windows: 2.325 min
Starting package 26/32: sqlite3:x86-windows
Building package sqlite3[core]:x86-windows...
-- Downloading https://sqlite.org/2021/sqlite-amalgamation-3350000.zip -> sqlite-amalgamation-3350000.zip...
-- Downloading https://sqlite.org/2021/sqlite-amalgamation-3350000.zip... Failed. Status: 28;"Timeout was reached"
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:184 (message):

      Failed to download file.
      If you use a proxy, please set the HTTPS_PROXY and HTTP_PROXY environment
      variables to "https://user:password@your-proxy-ip-address:port/".

      If error with status 4 (Issue #15434),
      try setting "http://user:password@your-proxy-ip-address:port/".

      Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues

Call Stack (most recent call first):
  ports/sqlite3/portfile.cmake:4 (vcpkg_download_distfile)
  scripts/ports.cmake:142 (include)

Error: Building package sqlite3:x86-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: sqlite3:x86-windows
  Vcpkg version: 2021-01-13-d67989bce1043b98092ac45996a8230a059a2d7e

Additionally, attach any relevant sections from the log files above.

C:\work\Projects\vcpkg>.\vcpkg upgrade --no-dry-run
All installed packages are up-to-date with the local portfiles.

C:\work\Projects\vcpkg>.\vcpkg update
Using local portfile versions. To update the local portfiles, use `git pull`.
No packages need updating.

C:\work\Projects\vcpkg>.\vcpkg upgrade --no-dry-run
All installed packages are up-to-date with the local portfiles.

C:\work\Projects\vcpkg>

Probably my network did not work temporarily. I can download https://sqlite.org/2021/sqlite-amalgamation-3350000.zip with a browser now.

Hi @nakag2020
Thanks for posting this issue.
Starting package 26/32: sqlite3:x86-windows
Building package sqlite3[core]:x86-windows...
-- Downloading https://sqlite.org/2021/sqlite-amalgamation-3350000.zip -> sqlite-amalgamation-3350000.zip...
-- Downloading https://sqlite.org/2021/sqlite-amalgamation-3350000.zip... Failed. Status: 28;"Timeout was reached"
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:184 (message):

      Failed to download file.
      If you use a proxy, please set the HTTPS_PROXY and HTTP_PROXY environment
      variables to "https://user:password@your-proxy-ip-address:port/".

      If error with status 4 (Issue #15434),
      try setting "http://user:password@your-proxy-ip-address:port/".

      Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues

Call Stack (most recent call first):
  ports/sqlite3/portfile.cmake:4 (vcpkg_download_distfile)
  scripts/ports.cmake:142 (include)

This is not related with upgrade. Seems something wrong with your network.
You can try to build it again. If it still failed, please download it manually, and then copy the archive to downloads/ folder.

@NancyLi1013 whatever causes the port build error is irrelevant to this issue – the issue reported here is that once the port build actually fails, the vcpkg upgrade will not trigger build again and returns false positive. I have seen this behavior multiple times during the last month and can absolutely confirm that.

@nakag2020, @wrobelda, this is a known issue in vcpkg upgrade command, duplicate to https://github.com/microsoft/vcpkg/issues/4360.


Duplicate icons when pinning in taskbar - Windows 10

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Duplicates the icon when pinned on taskbar in windows 10.
Steps to Reproduce

Open atom
Right click on atom in taskbar > Pin to taskbar
See the duplicated icon.

Expected behavior:
Pin the taskbar icon without creating a duplicate.
Actual behavior:
Duplicates taskbar item.
Reproduces how often:
100%, everytime. Although doesn't seem to happen on my machine at home.
Versions
apm  1.17.0
npm  3.10.5
node 6.9.5 ia32
python 2.7.12
git 1.9.5.msysgit.1
visual studio
Atom    : 1.17.2
Electron: 1.3.15
Chrome  : 52.0.2743.82
Node    : 6.5.0
Windows 10.
Additional Information

I am seeing the same behavior on Windows 10 Enterprise 2015 LTSB and Atom 1.18.0 x64.

I am also seeing the same behavior on exactly the same software are dfreese: Win10 Enterprise/Atom 1.18.0 x64

Is that not a issue from a issue? You should start with the first issue. For me the first issue here is that a second icon appeared from a already pinned icon. Like your animation, all other programs use exists icon (with blue bar).

Facing the same issue.

This problem occurs because the atom actually has two executable files:
'C:\ProgramData\user\atom\atom.exe'
'C:\ProgramData\user\atom\app-1.20.1\atom.exe' (insert your app version).
First atom.exe just run lastest version of atom.exe in app-* folder. If you pin first file, windows dont know about second. If you pin second, atom dont update.

Does the problem of two icons in the taskbar is an electron issue?

Have the same issue on the latest version (1.36.0 x64 Windows 10)

Closing as no longer really interested in this long outstanding issue. Switched to vscode 😜


Fix compilation using stack.

Currently stack build fails due to version incompatibilities. Bump some dependency versions to get it compiling.

Thanks!


Add WPF support

Add RNSqlite2.Net46 project file to WPF and moved out RNSqlite2Module.cs and RNSqlite2Package.cs out as shared code.
Thank @craftzdog and @hnq90 for the great work, that react-native-sqlite-2 is actually the first one RN's database solution on Windows.

Cool, man!
@hnq90, would you mind reviewing it? :)

@Kudo It's great :+1:

@hnq90 : this okie

@Kudo Thank you. I merged.
@craftzdog Could you please publish new version?

@craftzdog Btw, could you please change the project description because we support Android, iOS and Windows.

Thanks!
Updated the description and published it as v1.3.0.
Cheers 🚀

Thank you guys for the fast review and publish. Awesome!


Missing parameters for provide-list-of-connected-device

To execute the MATR cycle, I need to call the 'provide-list-of-connected-device' function.
However, unlike the diagram, in addition to authentication,
I also need to include 'user,' 'originator,' 'xCorrelator,' 'traceIndicator,' 'customerJourney,' and 'operationKey' (which should go in the request header).
Where can I retrieve this data?

I guess you need to build this yourself following the descriptions under the components sections:
components:
  parameters:
    user:
      name: user
      in: header
      required: true
      schema:
        type: string
        example: 'User Name'
      description: 'User identifier from the system starting the service call'
    originator:
      name: originator
      in: header
      required: true
      schema:
        type: string
        minLength: 3
        example: 'Resolver'
      description: >
        'Identification for the system consuming the API, as defined in
         [/core-model-1-4:control-construct/logical-termination-point={uuid}/layer-protocol=0/http-client-interface-1-0:http-client-interface-pac/http-client-interface-configuration/application-name]'
    x-correlator:
      name: x-correlator
      in: header
      required: true
      schema:
        type: string
        pattern: '^[0-9A-Fa-f]{8}(?:-[0-9A-Fa-f]{4}){3}-[0-9A-Fa-f]{12}$'
        description: 'Empty string accepted from external applications.'
        example: '550e8400-e29b-11d4-a716-446655440000'
      description: 'UUID for the service execution flow that allows to correlate requests and responses'
    trace-indicator:
      name: trace-indicator
      in: header
      required: true
      schema:
        type: string
        pattern: '^([0-9]+)(\.([0-9]+))*$'
        description: 'Empty string accepted from external applications.'
        example: '1.3.1'
      description: 'Sequence of request numbers along the flow'
    customer-journey:
      name: customer-journey
      in: header
      required: true
      schema:
        type: string
        example: 'Unknown value'
      description: 'Holds information supporting customer’s journey to which the execution applies'

how is this done for MWDI?

The service provide-list-of-connected-device should be called within a loop and is not invoked externally (for example, by Swagger, which passes the parameters). Where can I retrieve the data for the call? Perhaps using load.json? Or is there a service that can return the necessary data ('user,' 'originator,' 'xCorrelator,' 'traceIndicator,' 'customerJourney,' and 'operationKey')? Currently, I have them stubbed.

@SIAE: has this problem been resolved in the meantime?


How to implements OAuth2AuthorizationService and OAuth2AuthorizationConsentService base on Redis?

hello, How to implements OAuth2AuthorizationService and OAuth2AuthorizationConsentService base on Redis?
thanks.

@hawaiiandycao Thanks for getting in touch, but questions are better suited to Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements.
FYI, see gh-558

你好，
     你的邮件我已经收到，谢谢！

你好，
     你的邮件我已经收到，谢谢！


Nest (2nd Gen) fails because of empty displayName

Here's the stacktrace:
/home/user/homebridge/node_modules/hap-nodejs/lib/Accessory.js:45
  if (!displayName) throw new Error("Accessories must be created with a non-em
                          ^
Error: Accessories must be created with a non-empty displayName.
    at NestThermostatAccessory.Accessory (/home/user/homebridge/node_modules/hap-nodejs/lib/Accessory.js:45:27)
    at new NestThermostatAccessory (/home/user/homebridge/platforms/Nest.js:73:15)
    at /home/user/homebridge/platforms/Nest.js:38:49
    at /home/user/homebridge/node_modules/unofficial-nest-api/index.js:232:17
    at IncomingMessage.<anonymous> (/home/user/homebridge/node_modules/unofficial-nest-api/index.js:214:25)
    at IncomingMessage.emit (events.js:129:20)
    at _stream_readable.js:908:16
    at process._tickCallback (node.js:355:11)

This is the content of intialData:
initialData: {"$version":-8546,"$timestamp":1446130023690,"touched_by":{},
"auto_away":0,"auto_away_learning":"ready","hvac_heat_x3_state":false,
"compressor_lockout_enabled":false,"hvac_alt_heat_state":false,
"target_temperature_type":"heat","hvac_heater_state":false,"hvac_emer_heat_state":false,
"can_heat":true,"compressor_lockout_timeout":0,"hvac_cool_x2_state":false,
"target_temperature_high":26.5,"hvac_aux_heater_state":false,"hvac_heat_x2_state":false,"target_temperature_low":19,"hvac_ac_state":false,
"target_temperature":20.5,"hvac_fan_state":false,"target_change_pending":false,
"name":"","current_temperature":20.97,"hvac_alt_heat_x2_state":false,"can_cool":true}

Name is empty, so I changed line 36 of platforms/Nest.js from this:
                                var name = initialData.name;

to this:
                                var name = (initialData.name != "" ? initialData.name : "Nest");

Okay, it turns out the real problem is a missing "this." reference on line 72:
    Accessory.call(this, name, id);

should be:
    Accessory.call(this, this.name, id);

Looks like the fix was merged in.  If it doesn't fix it, let me know.  If it does, go ahead and close this out.


Expose HTTP response headers for HTTP::WebSocket

When opening a WebSocket connection, there's an option to set the request headers via an argument. However, the response headers from the server are not exposed at all. This means that a programmer is not able to access e.g. cookies sent by the server.
I would like to have something like this:
require "http/web_socket"
ws = HTTP::WebSocket.new("ws://example.com")
ws.response_headers["Set-Cookie"] # response_headers is an instance of HTTP::Headers

The new method in the Protocol class has a handshake_response that has these headers. My idea was to store this in an instance variable in Protocol and delegate it from the WebSocket class. However, @straight-shoota is saying that this is not The Right Way™ so I'm open for suggestions about how else to do this.

Thanks for clarifying! This actually helps a lot.
Your approach really couldn't work. This new method is used for establishing a client websocket connection. But those headers it receives are the request headers sent to the server. This argument can be used to send additional headers to the server. See 264-268 for the default headers added in this method.
What you want is to return handshake_response.headers. This looks like a logical enhancement. If you can send custom headers with the websocket handshake, you should also be able to receive them.
I would suggest to rename this new method to establish_connection and let it return {Protocol, Headers}. The headers don't belong into the Protocol class. This way they can be stored in an ivar in WebSocket.
We could consider if server-side WebSocket instances should also have the headers attached. This could be implemented by adding the headers to the hidden WebSocket.new methods.

@straight-shoota sorry for the late reply, busy times. So you want to call the establish_connection method in the two hidden WebSocket.new methods and pass the response headers into the instance, am I right?
Would it make sense to rename the headers to request_headers or should I keep it like it is? Asking because the response_headers sounds as a good name for this ivar and we might want to keep it symmetric.


psst: add darwin support; unstable-2024-10-24 -> 0-unstable-2024-11-12

Closes https://github.com/NixOS/nixpkgs/issues/359335
@vbrandl The update script needs to be modified a bit more to account for cargoHash, tho I don't know how to modify it and since you fixed it in the past, I'm going to ping you here in case you have an idea on how to do it.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Shouldn't @r-ryantm and https://github.com/r-ryantm/nixpkgs-update automatically update cargoHash? I'm not sure if this requires any changes to update.sh. I'm not 100% sure, if it does...

Tried updating it: nix-shell maintainers/scripts/update.nix --argstr package psst and yes, cargoHash was not updated with update.sh.
So instead, we can use nix-update-script which works.


Update examples with polish.

#556  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rohinb2 and the rest of your teammates on  Graphite


Selection Box Gets Stuck If Mouse Pointer Leaving Flowchart Window While Selection is Still Happening

Describe the bug
As the title says, and see the video below
https://user-images.githubusercontent.com/64100867/123263108-d12e2a00-d522-11eb-9c2d-73f0596b626f.mp4
To Reproduce
Start dragging (selecting) until mouse pointer leaving flowchart window or entering inspector area.
Expected behavior
Would auto scroll the flowchart window(like in any apps) OR at least prematurely deactivate the ongoing selection so it won't get stuck.
Versions & Platform (please complete the following information):

Unity version 2020 LTS

I see what's going on here. Basically, when selecting, it doesn't do any checks to move the flowchart view and loses detection once the cursor leaves the flowchart window. It might be a simple fix so I'll look into it.
More than likely, a function similar to dragging the window will need to be written and ran if at the edge. The challenge will be that it has to continue to track once the cursor has left the window so here's hoping that can be tracked by mouse events.

@Arylos07 fyi, just pushed a pr to fix this


Error CNTK Image Recognition Agent - possibly related to the use of non HTTPS addresses

Description from "'Koen' via Bugs & Issues"<EMAIL_ADDRESS>Error CNTK Image Recognition Agent - possibly related to the use of non HTTPS addressesSteps to reproduce:Use https://beta.singularitynet.ioStart a job on CNTK Image RecognitionReserve funds / Invoke the job.Any url image link will give the same result.EXPECTED RESULT:To Reproduce use:http://beta.singularitynet.io instead of the HTTPS1. Name of fields and their values are located on the same levelACTUAL RESULT: on HTTPSFriendly greetings,Koen

This requestObject seems to be the outdated one, it's using imgPath and not the img_path.
If user can provide the image URLs I can test them and check the result.


does the not parse correctly?

In the tests there is a section not a == b or c == d and this seems to be parsed as not ((a == b) or (c == d)) where python would parse this as (not (a == b)) or (c == d).
So bug or featrue?
In [6]: not 2 == 1
Out[6]: True

In [7]: 2 == 1
Out[7]: False

here is the test section I'm referencing:
================================================================================
Comparison operators
================================================================================

a < b <= c == d >= e > f
not a == b or c == d

--------------------------------------------------------------------------------

(module
  (expression_statement
    (comparison_operator
      (identifier)
      (identifier)
      (identifier)
      (identifier)
      (identifier)
      (identifier)))
  (expression_statement
    (not_operator
      (boolean_operator
        (comparison_operator
          (identifier)
          (identifier))
        (comparison_operator
          (identifier)
          (identifier))))))

Same problem here. It seems that the precedences are defined quite different than the precedence order
of Python.
Typically, I would expect that operator have the following precedence (in descending order):
parenthesis
call
...
comparison
not
and
or
...

However, it seems like the grammar.js defines the order as follows:
call
...
and
or
comparison
not
parenthesis
...

Is there a reason for that?

Interestingly enough, Issue #119 might be related to this (await higher precedence than comparison).


How to use rtree?

Maybe I'm just to new to Go, but can't get it to work:
package main

import (
  "github.com/Workiva/go-datastructures/rtree/hilbert"
)

func main() {
  rtree:= New(100,2) // 2D rtree with buffer size = 100
}

I get:
% go build
# go-datastructures_rtree.go
./go-datastructures_rtree.go:4:3: imported and not used: "github.com/Workiva/go-datastructures/rtree/hilbert"
./go-datastructures_rtree.go:8:11: undefined: New

Any idea?

Hi,
Should work this way:
package main

import (
  "fmt"

  "github.com/Workiva/go-datastructures/rtree/hilbert"
)

func main() {
  rtree:= hilbert.New(100,2) // 2D rtree with buffer size = 100
  fmt.Println(rtree)
}

Yep, thanks. Learned, that I have to use my declared variables, otherwise Go's not generating  binary.


vscode cucumber-language-server: Quoted parameters in steps cause undefined-step in editor

👓 What did you see?
When using the official Cucumber VSCode extension with the Python behave package, some steps with string variables are underlined and marked as "Undefined step".
✅ What did you expect to see?
A (string) parameter in Gherkin is passed in quotation marks as such: Given pass "foobar". The respective behave implementation is done as such:
@step('pass "{string}"')
def step_impl(context, string):
    assert string == "bar", f"pass <{string}> is not <bar>"

The problem is, that the Cucumber extension cannot find the implementation, as the quotation marks "{string}" are interpreted as part of the keyword. When removing them in the decorator, the quotation marks from the Gherkin keyword are not escaped and passed as part of the string. Therefor, the following implementation leads to an error:
@step("user {string}")
def step_impl(context, string):
    assert string == "foo", f"user <{string}> is not <foo>"    # --> Error Msg:  Assertion Failed: user <"foo"> is not <foo>

📦 Which tool/library version are you using?
VSCode: 1.88.0
Cucumber Extension: v1.10.0
🔬 How could we reproduce it?
Create a gherkin features/test_step.feature file:
Feature: Some new feature

  Scenario: Some Scenario
    Given user "foo"
    Given pass "bar"

Create the python step definition features/steps/steps.py:
from behave import step

@step("user {string}")
def step_impl(context, string):
    assert string == "foo", f"user <{string}> is not <foo>"

@step('pass "{string}"')
def step_impl(context, string):
    assert string == "bar", f"pass <{string}> is not <bar>"

Lastly, run it with $ behave features/
$ behave features/
Feature: Some new feature # features/test_step.feature:1

  Scenario: Some Scenario  # features/test_step.feature:3
    Given user "foo"       # features/steps/test_step.py:4 0.000s
      Assertion Failed: user <"foo"> is not <foo>

    Given pass "bar"       # None

Failing scenarios:
  features/test_step.feature:3  Some Scenario

📚 Any additional context?
I see two possibilities on how to solve this:

Either the Cucumber language-server is able to detected decorators with parameters in quotation marks (e.g. @step('pass "{string}"')
behave is able to strip quotation marks in the passed parameter, so decorators like this are possible @step("user {string}")

I am not sure, however, which may be the ideal solution. Maybe you can give me some feedback. I already posted the issue in the official behave repository, but was forwarded to the cucumber language-server repo.

Thanks for your answer. I did the following according to your guidance.

The feature & step file path matching works: I can automatically create undefined steps from the feature file or jump right to the implementation.
behave-cucumber-matcher was not installed, as you said, it should work with the default {string} parameters as well.
I tested positional arguments without specifying the type, this works out of the box!

However, I am still wondering, on which side (behave or cucumber) the error resides, when using {string} / "{string}" in the @step() annotation.
Feature: Some new feature

  Scenario: Some Scenario
    Given user "foo"           # implementation gets recognized
    Given pass "bar"           # underlined with "undefined step"
    Given item baz             # implementation gets recognized

from behave import step

# {string} contains the quotation marks, this messes with the python
# implementation. However, the cucumber language server recognizes this
# function.
@step("user {string}")
def step_impl(context, string):
    assert string == "foo", f"user <{string}> is not <foo>"

# This python implemenation works, however the cucumber language server does
# not recognize this function
@step('pass "{string}"')
def step_impl(context, string):
    assert string == "bar", f"pass <{string}> is not <bar>"

# This works -->
@step('item {}')
def step_given(context, string):
    assert string == "baz", f"item <{string}> is not <baz>"

The language server output contains the following
[Info  - 3:26:48 PM] * Found 1 feature file(s) in ["src/test/**/*.feature","features/**/*.feature","tests/**/*.feature","*specs*/**/*.feature"]
[Info  - 3:26:48 PM] * Found 3 steps in those feature files
[Info  - 3:26:48 PM] * Found 1 glue file(s) in ["*specs*/**/*.cs","features/**/*.js","features/**/*.jsx","features/**/*.php","features/**/*.py","features/**/*.rs","features/**/*.rb","features/**/*.ts","features/**/*.tsx","features/**/*_test.go","src/test/**/*.java","tests/**/*.py","tests/**/*.rs"]
[Info  - 3:26:48 PM] * Found 0 parameter types in those glue files
[Info  - 3:26:48 PM] * Found 3 step definitions in those glue files
[Info  - 3:26:48 PM] * Built 4 suggestions for auto complete

In here, the lang-server identified the 3 step definitions....

The extension evaluates {string} as a Cucumber Expression - which matches text surrounded by either single (') or double (") quotes.
Matching with {string}
As such, the following step definition pattern...
@step("user {string}")
def step_impl(context, string):
    assert string == "foo", f"user <{string}> is not <foo>"

... would match the following test steps:
Given user "foo"
Given user 'foo'

Behave will pass everything within the scope of {string} to the function body. This includes the quotes themselves; which is not what you intend in your assert; although you could modify the string you are checking against to also include the quotes.
Matching with "{string}"
Surrounding {string} with quotes creates a mismatch where Behave would only take the content within scope of the string (and work with your assert as intended); though as Cucumber Expressions expect {string} to also include quotes and you have them surrounding that keyword, you would need to include an additional set of quotes for the extension to create a match (see below) - which then wouldn't work with your assert unless modified as mentioned above.
@step('pass "{string}"')
def step_impl(context, string):
    assert string == "bar", f"pass <{string}> is not <bar>"

...would match the following test steps:
Given pass ""foo""
Given pass "'foo'"

Thus your existing step Given pass "bar" would pass only bar to the step definition function through the string argument; and the extension would not recognise the step definition pattern as matching this step as it expects the quotes to be part of {string} rather than surrounding it.
Alternatives
Use the Cucumber Expressions word keyword
word matches a single word only. Thus, you can surround it with quotes, and only the string content will be passed to the step definition; rather than also passing through the double quotes. This will work correctly with both the extension and Behave.
@step('pass "{word}"')
def step_impl(context, word):
    assert string == "bar", f"pass <{string}> is not <bar>"

Use the match anything {}
In both Behave and Cucumber Expressions, {} will match anything passed to it. Thus you could surround it with quotes; and only content within the quotes would be passed to the function.
@step('pass "{}"')
def step_impl(context, word):
    assert string == "bar", f"pass <{string}> is not <bar>"

Use Behave Cucumber Matcher
You can integrate Cucumber Expressions into Behave, which align that syntax with Cucumber Expressions. Note, you are using Cucumber Expressions syntax (such as {string}), but to behave this is treated as any other keyword argument (such as {name}, {book}, etc.) rather than having any special significance or association with quotes. This is understandably a source of confusion for many.
Summary
Hope this explanation is helpful, let me know how you get on @c92s 👍

Hi @kieran-ryan thanks for the information.
I guess I will stick to the {} and {word} matching then, escaping with double quotes or removing quotes in the function are not that nice to use tbh.


Error message when selling item and buying it back

Hi, I'm just checking out your asset now, and I got this error in the demo map. It was a freshly created project, v2.1.0.
I've tried a few times and get it each time.
Pick up the berries, then head to the shop and sell 1. Don't exit the shop menu. Click buy, then buy the stack of 1 back.
It only works when I buy the new stack of 1 after selling. If I sell a berry, then buy one from the stack of 5, I don't get the error.
Blueprint Runtime Error: "Accessed None trying to read property K2Node_CustomEvent_playerInventory_1". Node:  Get Graph:  EventGraph Function:  Execute Ubergraph BP Master Inventory Blueprint:  BP_MasterInventory

Thanks i will look to it.

Just found the bug was just a quick check in the widgets inside the vendor ui in the BP_MasterInventory
The next minor release will include the fix.


Add ability to pair model with mobile drive data and single ground site data

This is a draft PR for modifications to the develop_aircraft branch to add the ability to pair with mobile drive data and data from stationary ground sites.
Currently the functionality for pairing with mobile drive data is implemented and I will add the ability to pair with data from a single ground site, and clean up the code tomorrow.

@zmoon Wanted to get your suggestion on this error related to plotting I am getting with this PR:
Looks like the issue is potentially with pydecorate. @colin-harkins mentioned you actually fixed this in the github latest version of pydecorate (https://github.com/pytroll/pydecorate/issues/47) but a new version hasn't been put on conda?
Anyway we can limit version of pillow to a more depracated version (currently this PR uses 10.0) to avoid this error
                                  ---------------------------------------------------------------------------

AttributeError                            Traceback (most recent call last)
Cell In[47], line 2
1 #And this generates all the plots.
----> 2 an.plotting()
File ~/MM_developaircraft_ground_mobileadded_ColinPR185Test/MELODIES-MONET/melodies_monet/driver.py:1257, in analysis.plotting(self)
1255     # At the end save the plot.
1256     if p_index == len(pair_labels) - 1:
-> 1257         savefig(outname + '.png', logo_height=150)
1258         del (ax, fig_dict, plot_dict, text_dict, obs_dict, obs_plot_dict) #Clear axis for next plot.
1259 if plot_type.lower() == 'boxplot':
File ~/MM_developaircraft_ground_mobileadded_ColinPR185Test/monet/monet/plots/init.py:141, in savefig(fname, loc, decorate, logo, logo_height, **kwargs)
139 else:
140     raise ValueError(f"invalid loc {loc!r}")
--> 141 dc.add_logo(logo, **add_logo_kwargs)
143 # PIL.Image will determine format from the filename extension
144 img.save(fname)
File ~/anaconda3/envs/mm_colin_developaircraftPR185Test/lib/python3.9/site-packages/pydecorate/decorator_agg.py:48, in DecoratorAGG.add_logo(self, logo_path, **kwargs)
47 def add_logo(self, logo_path, **kwargs):
---> 48     self._add_logo(logo_path, **kwargs)
File ~/anaconda3/envs/mm_colin_developaircraftPR185Test/lib/python3.9/site-packages/pydecorate/decorator_base.py:357, in DecoratorBase._add_logo(self, logo_path, **kwargs)
354     nyi = int(round(nxi * aspect))
355     ny = nyi + 2 * my
--> 357 logo = logo.resize((nxi, nyi), resample=Image.ANTIALIAS)
359 # draw base
360 px = self.style["propagation"][0] + self.style["newline_propagation"][0]
AttributeError: module 'PIL.Image' has no attribute 'ANTIALIAS'

Yeah, current workaround is to install pydecorate<10 in your env.

Yeah, current workaround is to install pydecorate<10 in your env.
Currently I have the env for the docs and CI setup this way. But yeah once pydecorate does a release that shouldn't be needed.

Yes works now, once i switch to pillows 9.5 in my conda env

@colin-harkins is this ready for merge now, we can also work to merge #181 with this? @zmoon any further reviews for these two PRs ?


Getting the currently authenticated user's profile?

Is there a good way to do this?
I have seen mentions of API.me() searching around, but it doesn't seem to exist in the source code anymore.
The OAuthHandler's username field is also defaulted to None and never updated.
The best way I can think of is grabbing the user's timeline, finding the user's id or username in that, then using API.get_user().
Surely there is a better way than this?

You can use API.verify_credentials.


Carthage compatibility

Great if you could implement compatibility for Carthage

Added: https://github.com/bigfish24/ABFRealmGridController/commit/ad3cb683bd05f9c2feba1bb2840f6399112c1e33

:-)


How to get Tally Prime eInvoice data

Hi Sir@dhananjay1405
Greetings of the day!
First of all, Thanks a lot for your great utility.. it's an excellent utility for creating unbelievable reports on Google Sheets with the help of Query language.
Please help how to get the Tally Prime einvoicing data by using your tally connection utility.
Thanks in Adv
B4ALLB4U

@b4allb4u utility supports adding of fields from Tally as per your choice, which you require for capturing eInvoice data. First step is identification of field name in Tally. Just export voucher with eInvoice data into XML format. Open that XML file via Notepad++. Then try to search for that information, which you would find nested in XML tags, which is the field name used by the tally. Check the location of collection of that field in which it is nested. File named tally-export-config.yaml instructs utility to extract the fields from Tally. All the trn_xxx table correspond to some sub-collection of Voucher collection. Just add that field into respective trn_xxx and database-structure in same order (and then drop & re-create that specific table in database). You might require few trial-error.


run machine controller via leader election

What this PR does / why we need it: runs the machine controller via leader election this essentially means that we can have multiple instances and at the same time only one is operational.
before we acquire a lock we actually warm up caches mirroring the state of the API server.
machine controller will be run only if a proper lock was acquired.
note that the program terminates when the leadership was lost.
Which issue(s) this PR fixes: Fixes #58

@metalmatze I'm going to merge this PR, in case you would like to change something just let me know.


hacktober

Just creating this as it seems to contain a few of the changes you were going to make anyway in 3.2, so you can copy or use it for inspiration.
Specifically: #25 #47

Excellent. Thanks for this!

This is looking really great! I'd love to get the majority of this merged, but there are a couple of things to talk about.

For the frontend changes: can we drop the build.php file and just create and commit symlinks? Also, what's the reasoning for switching away from using a CDN? I was torn on the issue, so I'd love to hear your opinion.
The docker setup looks excellent.
auth.json generation: I don't think this will work. There are a couple of different use-cases I want to support in 3.2:

Multiple different tokens for github.com
Self-hosted gitlab
Self-hosted gitlab + multiple different tokens
Since auth.json specifies tokens on a domain-level, my understanding is only one token can be specified per domain. I would really love to get rid of the Composer patch, but we may have to find another way.

Switching to the v4 GitLab API means that we drop support for many, many versions of GitLab (including a GitLab I use!) Is it worth the benefit?
Dist archive stuff looks great
Code style: love it. That looks like strict PSR-1 and -2? Are you using a tool to format it automatically?

And two small criticisms:

It is very helpful to contain code-style changes to their own commit. Combining them with actual changes to the code makes it harder to see what actually changed.
Along the same lines as above, it's helpful (to me, mainly!) to develop one feature or some very closely related features per PR. With a bunch of changes, it's a bit hard to review.

All of the above is, of course, open to rebuttal.
Overall, fantastic stuff! I really appreciate the contribution. Let me know what you think about the changes and we can work on getting this merged. Thanks!

In response to the last part of your comment first. I agree with both, it's just that I'm not always certain whether Github maintainers are still active, or even care about merging pull requests, and if I'm developing only for our internal instance, there's not much need.
I've grown a bit cynical, and this has been the best response I've ever had to a pull request by far 👍

For the frontend changes: can we drop the build.php file and just create and commit symlinks?

Done.
As for moving away from the CDN's. I was trying to load the page locally, and it didn't work because one of the CDN's involved (or more likely my network connection) had apparently decided to have a bad day. When that happens there is little you can do, since you don't have any control over the CDN's. I enjoy the CDN's for prototyping, but not for production applications.

auth.json generation: I don't think this will work. There are a couple of different use-cases I want to support in 3.2:
Multiple different tokens for github.com
Self-hosted gitlab
Self-hosted gitlab + multiple different tokens
Since auth.json specifies tokens on a domain-level, my understanding is only one token can be specified per domain. I would really love to get rid of the Composer patch, but we may have to find another way.
Switching to the v4 GitLab API means that we drop support for many, many versions of GitLab (including a GitLab I use!) Is it worth the benefit?
Dist archive stuff looks great
Code style: love it. That looks like strict PSR-1 and -2? Are you using a tool to format it automatically?

@tyler-sommer Separate pull requests created. It's possible I've missed something obvious while splitting them up, so please let me know if you see something odd.

That said, I like the composer patch, as it's much cleaner, and I assume it would be merged, but it didn't seem to work when I tried it? Is there anything specific I have to do? I assumed the autoload would override the base composer files.

Yeah, it's super brittle I just now realized. You have to pass -o to composer install or update, then it generates a static class map and uses the lib/ versions instead of the vendor/composer versions. Otherwise, it doesn't work. The PSR-4 fix in your edit may be suitable.
As for the rest, thanks very much for the contribution!


Fix csproj for arm64 (how did i forget this????)

Summary of the PR
Fixes the native package csproj for ARM64 so the libs actually work (oops)

Build is failing

twas just me forgetting computers arent magic fairy dust

Would it be acceptable if GLFW and SDL imports a glob instead of a specific native version? we are hitting a chicken and egg scenario right now trying to update the native package version GLFW and SDL reference, which the only reasonable solution is to not update the native package version SDL and GLFW reference, and have users manually update them, but i believe you can glob versions like 3.3.* instead of referencing <IP_ADDRESS>

Yeah I'm fine with this


Undo for Deleting a Command Block

As the title says. Currently when a command block is deleted, there's no way to bring it back. There also isn't a confirm dialog box.
The broader goal is to have something like a Jupyter Notebook for shell commands.
Simple example of this vision:

All related issues:
https://github.com/wavetermdev/waveterm/issues/415 - Editable Command Blocks
https://github.com/wavetermdev/waveterm/issues/416 - Command Block Reordering
https://github.com/wavetermdev/waveterm/issues/417 - Editable Markdown Blocks
https://github.com/wavetermdev/waveterm/issues/418 - Export/Import Tab or Workspace
https://github.com/wavetermdev/waveterm/issues/419 - Allow All Blocks in a Tab To Be Executed Again
https://github.com/wavetermdev/waveterm/issues/420 - Allow Tab or Workspace Shell to be Restarted
https://github.com/wavetermdev/waveterm/issues/421 - Undo for Deleting a Command Block

I think a confirm for this might be annoying.  My thought here is to provide some small window of undo (maybe 5 seconds).  So, if you accidentally delete a block you have 5 seconds to "undo it" and it will come back.  This can be implemented by just deferring the actual delete for 5 seconds (although we'll visually remove it immediately).  For the first cut of this feature I'd also only allow one item to be "undone".
I know this isn't a fully general solution, but would this solve enough of the problem for you as a first pass?

Yes, that would certainly be better than what we have today. Maybe create an issue to implement a more robust undo system later once there's nothing better to do?
You're right, a confirm dialog would probably be too intrusive. It might only make sense without the undo feature, because the action is irreversible.


PBE algorithms

As part of our migration from Certicom to BC, we have stumbled upon the following issue:
Previously encrypted data using Certicom's PBEWithHmacSHA1AndAES-128 cannot be decrypted, or at least we couldn't manage to find the proper cipher.
Can you please advise?
Support contract holder: Axway Software

You'll need to contact us at the support address. We'll need to try a few vectors to work out what they've done.

Done. Escalated via mail.


add xmake.lua file to make it easier to build libuv

Hi, I found that libuv uses different build systems to build for different platforms. So I wrote a xmake.lua file to make it easier to build libuv.
We can use the following command to build and run tests.
For the current host platform (windows/macos/linux):
$ xmake
$ xmake run test

For the android platform:
$ xmake f -p android --ndk=/home/android-ndk-r10e
$ xmake

For the iphoneos platform:
$ xmake f -p iphoneos -a [arm64|armv7]
$ xmake

For the watchos platform:
$ xmake f -p watchos
$ xmake

For the cross toolchains platform:
$ xmake f -p cross --sdk=/home/xxx/toolchains/sdk
$ xmake

For the other platform(aix/sunos/os390/freebsd/openbsd/...):
$ xmake f -p [aix|sunos|os390|...] --sdk=/home/xxx/toolchains/sdk --cross=..
$ xmake

More cross compilation info, please see xmake.io and cross-compilation
Or generate vs project file and makefile:
$ xmake project -k vs2017 -m "debug,release"
$ xmake project -k makefile

If you feel that this does not help the libuv, please ignore this PR. 😄

Hi there! Welcome to libuv!
So, a similar thing happened yesterday, when someone submitted a gradle build system. Here is the answer: https://github.com/libuv/libuv/pull/1462#issuecomment-320466608
TLDR: we have enough build systems, sorry. Please do reach out next time before working on such things so you can avoid doing the work if it's not going to be merged.


Step Challenges: In Mobile version, Button Size is wrong and 'Go to previous' click not working

Hi,
When I render the page in mobile version and load [step challenge] (http://www.freecodecamp.com/challenges/waypoint-learn-how-free-code-camp-works), I could see two issues:

In step challenges, Go to next button is sized wrong. Only occupying half the space.
Go to my previous step button does not perform any action.

UserAgent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 like Mac OS X; en-us) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465 Safari/9537.53

Two obvious issues:
.challenge-step-counter.large-p.col-sm-2.col.xs-12.text-center (#{index + 1} / #{description.length})

should be col-xs-12
.btn.btn-primary.col-sm-5.col-xs-6.challenge-step-btn-next(id='#{index}' class=step[3] ? 'disabled' : '') Go to my next step

Should be col-xs-12

Cool.
I could identify the second one but dint see the first. I will do this.


Running tool outside the Docker-container throws some errors

I was running it from within the docker-container and from outside the container. From outside it throws some errors:
  Would you like to ...

  1)  Keep your current adlist configuration
  2)  Enable only adlists with covered unique domains
  3)  Enable the minimal number of adlists that cover all domains that would have been blocked

  Please select: 2

  [i]  Enabling adlists with covered unique domains....
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here
Error: in prepare, unrecognized token: "'"
  '
  ^--- error here

  [✓]  Adlists with covered unique domains enabled

  [i]  Of the 713 domains that would have been blocked by the adlist configuration you chose to analyze,
       711 domains are covered by your current adlist configuration.

  [i]  Removing temporary database...
  [✓]  Temporary database removed

I like the tool. I have about 40 adlists and after the check only 12 need to be enabled.

Does it also fail on other places? E.g. when you select another option?

With options 1 and 3 it continues without error. And after that another try with option 2 with the same errors.

That's interesting, because option 3 and 2 use the same syntax for their commands.
Could you generate a Pi-hole debug log and post the token here?

https://tricorder.pi-hole.net/aN93Lxlh/

Sorry for not getting back to you, your're not forgotten. Life is quite busy at the moment, I'll come back when I really have time to look into this.

No hurry. There are more important things in life then this issue. It's not a big deal for me. Haven't used it since then. I like the idea. Might add it to my pihole-unbound-image (which is a fork, but I try to keep it more up-to-date then the original one).

Fixed by https://github.com/yubiuser/pihole_adlist_tool/pull/83


TBCC bug still exist in beta2

Hi, new beta2 update still doesn't work. Cant click anything and the console doesn't work either. made a vid
https://www.youtube.com/watch?v=hYV-VCPZUnE
Originally posted by @betterftr in https://github.com/TimothyLuke/GnomeSequencer-Enhanced/issues/851#issuecomment-862229029

Working on in via #852

Try Beta 4 - it still has some interesting quirks but it’s behaving
TimothyLuke

On 16 Jun 2021, at 7:42 pm, betterftr @.***> wrote:

Hi, new beta2 update still doesn't work. Cant click anything and the console doesn't work either. made a vid
https://www.youtube.com/watch?v=hYV-VCPZUnE
Originally posted by @betterftr in #851 (comment)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Update PHP to support for Larvel 10 (php 8.2.3)

Any chance you can bump the PHP for the latest Laravel 10.x release?

You can use the latest version now!

Thank you!


Pagination Example- bullets are not working, when slide moves bullets are not changing its status and eve DOTS (bullets) are not clickable. This is in

This is a (multiple allowed):

[x] bug

[ ] enhancement

[ ] feature-discussion (RFC)

Swiper Version: EXACT RELEASE VERSION OR COMMIT HASH, HERE.

Live Link or JSFiddle/Codepen or website with isssue: PREFERABLY (IF YOU WANT YOUR ISSUE TO BE RESOLVED ASAP).

Expected Behavior
EXPLAIN WHAT IS TO BE EXPECTED, HERE.
Actual Behavior
EXPLAIN WHAT IS ACTUALLY HAPPENING, HERE.
P.S. Remember, an issue is not the place to ask questions. You can use Stack Overflow
for that.
Before you open an issue, please check if a similar issue already exists or has been closed before.

Pagination Example Demo
https://swiperjs.com/demos/

I can clearly see that pagination bullets work there


Could not find a shop to authenticate with. Make sure you are making your XHR request with App Bridge's authenticatedFetch method.

Issue summary
Write a short description of the issue here ↓
Getting Could not find a shop to authenticate with. Make sure you are making your XHR request with App Bridge's authenticatedFetch method. error when accessed installed development app from different partners staff account.
However it is working when when I have logged in and open app at any time.
Expected behavior
What do you think should happen?
It should open and run app without any issue.
Actual behavior
What actually happens?
`
Could not find a shop to authenticate with. Make sure you are making your XHR request with App Bridge's authenticatedFetch method.
`
Tip: include an error message (in a <details></details> tag) if your issue is related to an error
Steps to reproduce the problem

Install development shopify node app(public app) to a development store in partners account
Send invitation to another member so that he can access to partners account & development store
Once he has accepted invitation, logged in whenever he tried to open app it is giving an error.

Reduced test case
The best way to get your bug fixed is to provide a reduced test case.
Specifications

Browser: Chrome Version 102.0.5005.115 (Official Build) (x86_64)
Device: MacBook
Operating System: Montery

@LuckyGStar  have you fixed this error?  I have the same Error.

I want to make dynamic routing based on the user plan.    react side for routing I am using this package https://github.com/kyeotic/raviger ,  issue to set dynamic route  if the paid user then renders the app settings page. if the user doesn't have paid plan then always show the plan page. also, restrict the app settings page. settings page only access when the user has paid plan.

@LuckyGStar  Thanks a lot I have a similar one but now I am able to make fetch calls using the same function.


OWallet does not transfer ONG from one wallet to another

as above

Works perfectly.  Firstly,  subtract 0.01 ONG from the amount of ONG you want to transfer, and transfer the remainder.   xONG - 0.01ONG = amount to be transferred x-0.01ONG.


Use parquet metadata to calculate len

Dask does not currently save/leverage the parquet-metadata statistics tp calculate the length of a DataFrame collection.  This PR modifies read_parquet to save the size of each partition (when this information is available and correct), and then uses it in DataFrame.__len__.
I am confident that we definitely want to do something like this.  However, I will mark this PR as a draft until we can agree on "where" the partition-size metadata should be stored.  For now, I am adding it to collection_annotations, but it may also make sense to make it a DataFrameIOLayer attribute.

I like the idea of putting it in collection_annotations

Nice.  One of my primary concerns is that these annotations are printed in the Layer html repr, and printing every partition length can become pretty verbose.  Of course, that answer to that problem may just be to provide a mechanism to specify annotations that shouldn't be written.

Are we planning to track this information through other operations, or is
it only useful for len(dd.read_parquet(...)).
If the answer is yes, we plan to track it, then I think we need a plan for
that.  I think that high level expressions are that plan.  If the answer is
"no, this is only useful for the very specific case of
len(dd.read_parquet(...)) then I'm curious about how often that comes up.
On Mon, Jul 19, 2021 at 2:30 PM Richard (Rick) Zamora <
@.***> wrote:

I like the idea of putting it in collection_annotations
Nice. One of my primary concerns is that these annotations are printed in
the Layer html repr, and printing every partition length can become pretty
verbose. Of course, that answer to that problem may just be to provide a
mechanism to specify annotations that shouldn't be written.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/pull/7912#issuecomment-882874709, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKZTA7EXK2IMGHCDGUAVDTYSKQJANCNFSM5AUEXNHA
.

Are we planning to track this information through other operations, or is
it only useful for len(dd.read_parquet(...)).

I'm still uncertain if length information is worth tracking through other operations.  However, I can say for sure that the len(dd.read_parquet(...)) case is quite important for NVTabular, where we currently need to process the parquet metadata seperatly (and redundantly) to get the dataset size without calling len(ddf).  The motivation comes from the fact that many DL dataloading APIs (for out-of-core data) require the user to specify the total length of the dataset.  I am pretty annoyed by this requirement, but it's something we need to provide for now.

I would certainly recommend tracking the length information! Some operations like column-select/assign or map are guaranteed to preserve the row-count. The total count would be nice to include in the graphical or text output (since it's free).
I think you are using parquet statistics only here I think? The row count per row group and globally (if there is _metadata) does not require column statistics. Statistics are optional, but row counts are mandatory. If you don't have _metadata, then of course you need to open the constituent files to get their counts (which is still faster than loading ; and this might be loaded and cached upon len).

I have not yet found the discussion where we go over the idea of storing dataframe-level attributes/metadata (which predated high-level graphs).

I think you are using parquet statistics only here I think? The row count per row group and globally (if there is _metadata) does not require column statistics. Statistics are optional, but row counts are mandatory.

This is a good point.  The current implementation is using a statistics structure to collect the partition-wise row-counts, but the the row-count is not actually a real "statistic".  If there are no filters or index columns to deal with, the statistics list will not actually include any column-chunk information ("statistics") at all.  With that said, we avoid parsing/organizing any of this metadata-based information when the user explicitly defines gather_statistics=False.

we avoid parsing/organizing any of this metadata-based information when the user explicitly defines gather_statistics=False.

Understood - two slightly different things (parsing thrift footers versus constructing the statistics structure)

I just came across a version of this issue that has a really nice comment from Tom. Might be worth considering some of these questions:

FWIW, I think that this is exactly the case we'd first introduce length-aware DataFrame partitions. But the details are a tricky. If you're interested in pursing this, I think we would need

A proposal on how this will be stored on DataFrame / Series / Index (dask.array.Array stores ._chunks as a tuple
A way to pass through this information when creating these objects
A proposal on how methods can use this information (e.g. __len__ can be an example). This will likely need to describe how things fallback to the common unkown-length case (is that automatic? Can that be configured to error?).
A proposal for how methods can indicate that they're shape-preserving. e.g. DataFrame.rename(columns=...) will not affect the rows, so the lengths are preserved. But DataFrame[mask] would have to invalidate the rows.

So not insurmountable, but a good amount of work.

ref: https://github.com/dask/dask/issues/5633#issuecomment-558228192

Thanks for digging this up @jsignell ! I totally agree with @TomAugspurger

A proposal on how this will be stored on DataFrame / Series / Index (dask.array.Array stores ._chunks as a tuple

This is exactly what I am hoping to decide on here.  My original solution was to store the information at the Layer level in the collection_annotations attribute.  I also suggested the possibility of attaching this information to the Layer object as a dedicated _partition_lens attribute.  However, I am starting to believe that this particular type of information deserves to live as an optional _Frame attribute as _Frame._known_lens.

A way to pass through this information when creating these objects

If we store the partition lengths in a _known_lens attribute, we need to update the _Frame, DataFrame, and Series constructors to accept this optional attribute.  We would also need to add it to new_dd_object (since it is typically the “canonical” API for constructing a new _Frame collection in dask.dataframe).
Setting the length information this way becomes trivial in IO functions like read_parquet and from_pandas (you just pass the list into new_dd_object when it is available).  For simple length-preserving operations, like assign, we can also modify elemwise to propagate these lengths (if/when they are known).

A proposal on how methods can use this information (e.g. len can be an example). This will likely need to describe how things fallback to the common unkown-length case (is that automatic? Can that be configured to error?).

Methods in the dask.dataframe API should be free to use _known_lens when the attribute is not set to None.  For now, there are not many cases where we need this information (just __len__ for now), and there are many cases where we do not want to require a dask collection to keep track of the length of every partition (shuffling, filtering, merging, etc…).  So, we do not want to raise an error when the information is lost.
Note that there are probably other methods, besides __len__, that could make use of _known_lens.  I could also imagine that many users would find a (fast) drop_empty_partitions method to be very useful.

A proposal for how methods can indicate that they're shape-preserving. e.g. DataFrame.rename(columns=...) will not affect the rows, so the lengths are preserved. But DataFrame[mask] would have to invalidate the rows.

I think the primary concern is that we can propagate known lengths through elemwise methods, and some map_partitions operations.  Therefore, I suspect that we will only need to add something like a preserve_partition_lens kwarg to map_partitions (which will indicate that _known_lens should be passed into the final new_dd_object call).

In general I think that you should expect any change to the core metadata  of dataframes on top of meta/divisions/graph will be met with extreme levels of scrutiny :)

Thanks for taking a look @mrocklin !  I am not happy with this "proposal" yet, so your comments are helpful.

in general I think that you should expect any change to the core metadata of dataframes on top of meta/divisions/graph will be met with extreme levels of scrutiny :)

No worries. I absolutely expected a -1 from you :)
With that said, I am fairly certain that we do need to come up with a way to store/track this kind of information. So, I am doing my best to experiment with different solutions in an open-minded way.
Note that I locally implemented a Layer-centered solution that works fine, but I switched to the _Frame attribute when I realized this feature is very similar to Array._chunks, and would be much more useful at the dask.dataframe API level than at the HLG Layer level.  I also realized that, after I finish the required groundwork to ensure that all Dataframe-specific Layers were based on DataFrameLayer, we would probably be uncomfortable with partition-length information being tracked there as well.  Overall, the partition-length information does not feel like it should be attached to the graph to me.
To be clear, I am very hesitant to change the _Frame/DataFrame/Series APIs. I think it is a bit obvious that collection-specific information needs to be attached to the "collection" object itself in some way, but I don't want it to live at the same level as meta/divisions/graph.

For example, someone could easy "well, I want to compute max" and then we have to add maxes everywhere. Same with uniqueness, emptiness, min-ness, etc.. I think that we can still solve what you want to solve, but that we should find another way.

I also had the same "slippery-slope" thought that users may want to track other "collection statistics" to optimize similar operations.
Perhaps a reasonable compromise here is to (1) change _lens into a more-general  _partition_statistics attribute, and to (2) treat this attribute as a “second-class citizen”.  That is, we could add explicit set/get methods to attach/access these optional statistics, and leave the optional attribute/information out of _Frame/DataFrame/Series initialization.  This way, we would avoid any “public” API changes, but provide a formal mechanism/location for this type of information to be stored/propagated.   I realize that this idea is likely to get a -1 as well, but maybe I’m getting a bit closer?

Just as a note: Array has been doing a bit of this kind of pattern with cached_property. I personally would prefer to have  _len as a cached_property of dataframe objects rather than having a grab bag of _partition_statistics.

@jsignell - I decided to experiment with your cached_property idea.  Please feel welcome to advise :)

Is this PR still active? Are there plans to get this merged in anytime soon? @rjzamora

I suspect that this got superseded by the discussions around a high-level expression system for encapsulating all the dataframe metadata https://github.com/dask/dask/issues/7933


chore(build): update libs version to 7906f7e

Signed-off-by: Luca Guerra<EMAIL_ADDRESS>
What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

If contributing rules or changes to rules, please make sure to also uncomment one of the following line:

/kind rule-update

/kind rule-create

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area engine

/area rules

/area tests

/area proposals

What this PR does / why we need it:
Following the addition of https://github.com/falcosecurity/libs/pull/73 we can now update the list of fields since the order in the self documentation has changed.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: LucaGuerra
To complete the pull request process, please assign mstemm after the PR has been reviewed.
You can assign the PR to them by writing /assign @mstemm in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Welcome @LucaGuerra! It looks like this is your first PR to falcosecurity/falco 🎉

/milestone 0.31.0

@FedeDP: changing LGTM is restricted to collaborators

In response to this:

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leogr, LucaGuerra
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 09ef905ef64ba7efbde309c9dad8d49280014b94


Generalise the Force Field Content Field

Description
This PR renames the force field inner_xml attribute to inner_content as there is nothing that makes it specifically for XML, and it can in fact store any string representation of a force field.
Status

[X] Ready to go

Codecov Report

Merging #29 into master will decrease coverage by 3.75%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #29      +/-   ##
==========================================
- Coverage   87.03%   83.28%   -3.76%
==========================================
  Files         107      107
  Lines        4290     4290
==========================================
- Hits         3734     3573     -161
- Misses        556      717     +161

Impacted Files
Coverage Δ

nonbonded/backend/database/crud/projects.py
99.67% <ø> (ø)

nonbonded/backend/database/crud/results.py
100.00% <ø> (ø)

nonbonded/backend/database/models/forcefield.py
100.00% <100.00%> (ø)

nonbonded/library/models/forcefield.py
100.00% <100.00%> (ø)

...nbonded/library/factories/projects/optimization.py
24.32% <0.00%> (-72.98%)
:arrow_down:

nonbonded/library/templates/forcebalance.py
57.14% <0.00%> (-42.86%)
:arrow_down:

nonbonded/library/curation/components/selection.py
61.67% <0.00%> (-30.40%)
:arrow_down:

nonbonded/cli/optimization/generate.py
75.00% <0.00%> (-25.00%)
:arrow_down:

Continue to review full report at Codecov.

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


Add column definition function as a separate tab

What was changed:
Added "Column definitions" in the generated report as a tab after Duplicated rows. This tab shows the column definitions of the dataset as a table using the striped table format.
Why was it changed:
Our team has multiple data scientists, and we use pandas-profiling to generate exploratory analysis reports and share them among the team members and stakeholders. We want to distribute one file, instead of distributing both the pandas-profiling report and a separate column definitions file.
How was it changed:
Added column definitions into describe.py.
It is set as True in the config_default.yaml and False in the config_minimal.yaml.
The ProfileReport constructor takes a new parameter (definition_file). The path to the column definition file is passed in as the argument. Currently, only the JSON file format is implemented, and It defaults to None.
The example is implemented in examples/census/census.py and the column definition is in examples/census/census_column_definition.json.
profile = ProfileReport(
    df,
    title="Census Dataset",
    explorative=True,
    definition_file=f'{filepath}/census_column_definition.json'
)

The required dataset_column_definition.json format is:
{
    "column name 1": "column 1 definition",
    "column name 2": "column 2 definition"
}

@mereldawu thank you for this pull request.
pandas-profiling already has the option to add descriptions to individual columns (see this example). The difference between the current implementation and your work is that the descriptions are (1) loaded from a file and (2) displayed in their own section.
Loading the descriptions from a file can be easily achieved in the current implementation like this:
import json
import pandas as pd
import pandas_profiling

with open('census_column_definition.json', 'r') as f:
    definitions= json.load(f)

report = df.profile_report(variable=dict(descriptions=definitions))
report.to_file('report.html')

The second difference would be useful to incorporate, since his provides a better overview of the descriptions. Would you be interested in changing the PR in such a way that the descriptions are provides as a tab under "Overview"?
See https://github.com/pandas-profiling/pandas-profiling/blob/develop/src/pandas_profiling/report/structure/overview.py

Hey @sbrugman,
I didn't know that there was already a variable description option in place!
In any case, I moved the implementation to the Overview tab and updated the example as you suggested.
Apologies for the multiple commits, I didn't see your edit so had to add the example separately.

@mereldawu Thanks for your contribution. I've changed a few things:

Rather than using two sources for the descriptions, we now use the variables.descriptions parameter for both and have an additional parameter to disable displaying the descriptions for each variable.
Restructured part of the overview to be consistent with the changes.

Could you review?


Implement native support for RPC timeouts

It's possible to use tokio timeout but this leads to unwieldy types containing numerous nested Results. I think default and per-RPC timeouts should be a native feature of the code generated RPC services in anemo. Timeout should be a supported error type within anemo::rpc::Status. Bonus if we also make client propagate its timeout to server so that the server can behave accordingly (eg fail-fast, or use it to set appropriate timeouts on Child RPCs).

This doesn't even need to be implemented directly inside of anemo and could be completely handled via a tower layer

Maybe but I think it's worth natively supporting. It could be its own error code in anemo::rpc::Status, and propagation of timeouts as a native header. This is a pretty basic RPC framework-level feature in most systems.

Closed by dd5d32549f03f51e16843ab91530727392894eb3 and 06585a7d407e029e1bb70af110b31e3db23689fd


no error during compile,but "nheqminer Command not found"

~/nheqminer/nheqminer/build$ cmake ..
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   system
--   log_setup
--   log
--   date_time
--   filesystem
--   thread
--   regex
--   chrono
--   atomic
-- Configuring done
-- Generating done
-- Build files have been written to: /home/zhou/nheqminer/nheqminer/build

~/nheqminer/nheqminer/build$ make
Scanning dependencies of target nheqminer
[  5%] Building CXX object CMakeFiles/nheqminer.dir/main.cpp.o
[ 11%] Building CXX object CMakeFiles/nheqminer.dir/amount.cpp.o
[ 17%] Building CXX object CMakeFiles/nheqminer.dir/api.cpp.o
[ 23%] Building CXX object CMakeFiles/nheqminer.dir/arith_uint256.cpp.o
[ 29%] Building CXX object CMakeFiles/nheqminer.dir/crypto/ripemd160.cpp.o
[ 35%] Building CXX object CMakeFiles/nheqminer.dir/crypto/sha256.cpp.o
[ 41%] Building CXX object CMakeFiles/nheqminer.dir/json/json_spirit_reader.cpp.o
[ 47%] Building CXX object CMakeFiles/nheqminer.dir/json/json_spirit_value.cpp.o
[ 52%] Building CXX object CMakeFiles/nheqminer.dir/json/json_spirit_writer.cpp.o
[ 58%] Building CXX object CMakeFiles/nheqminer.dir/libstratum/StratumClient.cpp.o
[ 64%] Building CXX object CMakeFiles/nheqminer.dir/libstratum/ZcashStratum.cpp.o
[ 70%] Building CXX object CMakeFiles/nheqminer.dir/primitives/block.cpp.o
[ 76%] Building CXX object CMakeFiles/nheqminer.dir/speed.cpp.o
[ 82%] Building CXX object CMakeFiles/nheqminer.dir/trompequihash/blake2/blake2bx.cpp.o
[ 88%] Building CXX object CMakeFiles/nheqminer.dir/uint256.cpp.o
[ 94%] Building CXX object CMakeFiles/nheqminer.dir/utilstrencodings.cpp.o
[100%] Linking CXX executable nheqminer
[100%] Built target nheqminer

nheqminer/nheqminer/build$ nheqminer -h
nheqminer：Command not found

Its ./nheqminer -h with the dot and the slash


Include folder in project does not get recognised by the linter

Extension version: 1.11.3
SourcePawn: 1.10
When a .inc file is included is a sourcepawn file the linter will treat it as if the file can not be read. But the content of the .inc files do get properly linked and documentation still appears over methods from the .inc file, meaning that the script will still get compiled just fine due to the folder being included when the run button is hit.
Scenario:

Expected result:
No error warnings.
Actual result:
error warning: fatal error 183: cannot read from file: "include/VSH2Utils.inc"

Hi thanks you for reporting this issue. Right now the extension doesn't support .sp files outside of the scripting folder, but I plan on making this available.
If you move the file in the scripting folder it should work.

Closing this for now, as this file pattern is currently not supported by the extension.


Refactor schemas

Given we're now working on different types of schemas (we have an NMC one, we're developing a FEFF one and I'm hoping to develop more in the future), does it make sense to refactor schemas.py into a module itself? E.g.
schemas/
|---- base.py
|---- xas.py
|---- nmc.py
|---- feff.py
|---- ...

Where base.py contains GenericDocument, xas inherits base and the others inherit xas?
@danielballan @jmaruland thoughts?

Fine by me!

I like this idea. It keeps files simple, as well

Excellent! I'll probably work with Mike a bit on this.  Once we have a FEFF schema in place we'll make a new branch dedicated to the refactor.


Artist Invite Impression API

https://www.pivotaltracker.com/story/show/151895707

          1 Warning

:warning:
Please provide a linked tracker story for this PR in the description

  Generated by :no_entry_sign: danger

@alanpeabody I gave up on AR because I couldn't figure out how to get the data in the format that I wanted (e.g. { "artist_invite_id"=>"1", "date"=>"2017-01-01", "impressions"=>10 }). After giving up and copy + pasting the Periscope query and having what I wanted in 5 minutes, I was pretty happy with my decision haha.


move cosmos implementation to its own file

@tamarrow rebase

@jsancio updated

LGTM. I have some questions around "source", "url" and "version" but we can address when we try to make the tests pass.

:shipit:


missing main.py

You have mentioned to run the train model need to run python main.py once we put test images into test folder. but unable to find the main.py in the repo

Thank you. I am trying to train a model on some captcha. I couldn't connect you on discord.

discord :  enderty


Wide-spectrum anomaly locator

About the PR

Adds a new item to the game "Wide-spectrum anomaly locator", being a modified anomaly locator. It has a 2-fold increased anomaly search range, but the distance detection function for it is disabled.
Why / Balance

On large maps, the process of finding anomalies is difficult. This locator helps to detect the approximate location of anomalies, but does not remove the need to use conventional anomaly locators.
Media

https://github.com/space-wizards/space-station-14/assets/96445749/c226b5a0-0c07-4e86-b7b3-db8ee4128382

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl:

add: Added wide-spectrum anomaly locator.

interesting concept, i like it @EmoGarbage404

@EmoGarbage404
Ha, this is my first PR, and I'll say right away that I can't make a full-fledged second mode yet, I need time and experience on other PRs before trying to do this.

I'm not sure how useful this would be, a 40 tile radius is a big area to search (5000+ tiles). And without directionality, if you have more than one anomaly on the station (e.g. when science has contained one and is farming it for points), it's highly likely that this device will pick up both of them at the same time, and you won't be able to distinguish between them

@chromiumboy
This locator has no purpose to find a specific location of the anomaly, but rather to answer the question "is it even here somewhere?", and this is necessary for really large maps, such as this one I'm working on:
https://github.com/TheShuEd/Gate-Station-SS14/tree/main

@chromiumboy This locator has no purpose to find a specific location of the anomaly, but rather to answer the question "is it even here somewhere?", and this is necessary for really large maps, such as this one I'm working on: https://github.com/TheShuEd/Gate-Station-SS14/tree/main

I see what you mean. But it still runs into the problem I mentioned before, when you have overlapping anomalies. At that distance it can be hard to tell if there is another anomaly nearby that you don't already know about. Also it would only be useful for detecting unannounced anomalies (as ones that are generated are always announced to the whole of science). This would require the science team to be proactive in looking for them. But given that anomaly spawns are very rare, no one in science is going to be doing that

Well yeah, it's not perfect. It merely gives you a general area. That's the point.
And i don't see how this wouldn't help with manual spawns? Because you know one exists doesn't mean you have the least idea of where it actually is. PLUS you can still use the normal locator to find it once close enough.
This is meant to HELP find anomalies, not do so on it's own.

Personally I'm not convinced, it's uses seem too niche to me
Maybe this could work as an alternate mode for the base scanner, but it doesn't warrent being its own separate device

Well, as EmoGarbage suggested, this is probably the objective in the future.
But it would probably be a new PR if anything.

@EmoGarbage404
I will reopen the PR a little later, I want to make changes from the master to the branch, and be able to make another other PR


Copyright and authorship

The old YACS page has meta tags naming Jeff Hui as the author and marking the site "(c) 2011 Jeff Hui". I don't know what to put in the author/copyright tags on our page; while we are using Jeff's ideas, we are using none of his code.

By Sam Gallagher's and Moorthy's advice the new YACS site is authored by the three of us and copyright 2015 the three of us.


Cannot start scrcpy (exec: no such file or directory)

When I try to start scrcpy (using either scrcpy or ADB=$(which adb) scrcpy, I get this error:
$ ADB=$(which adb) scrcpy
INFO: scrcpy 1.12 <https://github.com/Genymobile/scrcpy>
exec: No such file or directory
ERROR: Command not found: [/usr/lib/android-sdk/platform-tools/adb], [push], [/usr/local/share/scrcpy/scrcpy-server], [/data/local/tmp/scrcpy-server.jar]
ERROR: (make 'adb' accessible from your PATH or define its fullpath in the ADB environment variable)
ERROR: Could not execute "adb push"

If I run adb (using adb, $ADB, /usr/lib/android-sdk/platform-tools/adb, or /usr/bin/adb), it works fine.
$ adb --version
Android Debug Bridge version 1.0.41
Version 29.0.6-6198805
Installed as /usr/lib/android-sdk/platform-tools/adb

What does scrcpy actually try to do to execute adb? Is there something else I need to change?
OS: Ubuntu 19.10
scrcpy version: 1.12, installed as snap (apt package was not found)

/usr/lib/android-sdk/platform-tools/adb is not accessible from the snap container.
You need to use scrcpy.adb (or use a non-snap version of scrcpy).

The version of scrcpy.adb is 39, but scrcpy wants version 41. How should I upgrade it?
INFO: scrcpy 1.12 <https://github.com/Genymobile/scrcpy>
adb server version (41) doesn't match this client (39); killing...

scrcpy does not expect a specific version. It's just that you have an adb v41 daemon started (and maybe restarted again and again by some software if it keeps happening).
I don't know how to update adb from snap. Use a non-snap version if you need to.

cc @sisco311

I'd use the apt package if I could, but it doesn't exist for me. Maybe because I'm on Ubuntu 19.10?
$ sudo apt install scrcpy
Reading package lists... Done
Building dependency tree
Reading state information... Done

No apt package "scrcpy", but there is a snap with that name.
Try "snap install scrcpy"

E: Unable to locate package scrcpy

Yes, unfortunately, that means you need to BUILD it.

Cool, I built it and it works now.


chisel5p0 mill0p11

[build system] remove legacy dependencies, bump to chisel master
[build system] bump to mill 0p11

Whatttttttt? 3b6c87b


[Checkbox] Inconsistent behavior with plain label

Bug report
Current Behavior
When the Checkbox primitive is used with controlled state, is wrapped in a plain <label>, and has an Indicator with conditionally-rendered children, the checkbox's click handler competes with the label's native browser behavior and eventually becomes "stuck" when interacting with the indicator.
Expected behavior
Checkbox should not get stuck when interacting with the indicator.
Reproducible example
https://codesandbox.io/s/crazy-sutherland-vxqoj?file=/src/App.js
Suggested solution
N/A
Additional context
This doesn't happen when using the Label primitive from radix-ui.
Your environment
(any)

@nderscore Thanks for reporting. We've just merged a fix for this which should be available in our next release.

Hey @nderscore, this fix has now been released.