fix(tonlibjson-sys): fix support for macos in build.rs

Hey Team, thank you for these bindings! ❤
I tried to use `tonlibjson-client and encountered an issue:
[dependepcies]
tonlibjson-client = { git = "https://github.com/getgems-io/ton-grpc.git" }

It didn't compile successfully on my MacBook M1:

cargo build output
cargo build
    Updating git repository `https://github.com/getgems-io/ton-grpc.git`
   Compiling tonlibjson-sys v0.3.1 (https://github.com/getgems-io/ton-grpc.git#f257c0da)
   Compiling tl_parser v0.1.0 (https://github.com/getgems-io/ton-grpc.git#f257c0da)
   Compiling tonlibjson-client v0.17.2 (https://github.com/getgems-io/ton-grpc.git#f257c0da)
error: failed to run custom build command for `tonlibjson-sys v0.3.1 (https://github.com/getgems-io/ton-grpc.git#f257c0da)`

Caused by:
  process didn't exit successfully: `/dev/project/target/debug/build/tonlibjson-sys-1480e5ed93844183/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=OPENSSL_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=OPENSSL_STATIC
  cargo:rerun-if-env-changed=OPENSSL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_aarch64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_aarch64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_aarch64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_aarch64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=OPENSSL_STATIC
  cargo:rerun-if-env-changed=OPENSSL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
<EMAIL_ADDRESS>  cargo:rustc-link-lib=ssl
  cargo:rustc-link-lib=crypto
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=OPENSSL_STATIC
  cargo:rerun-if-env-changed=OPENSSL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_aarch64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_aarch64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_aarch64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_aarch64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rustc-link-lib=static=c++
<EMAIL_ADDRESS>  cargo:rustc-link-lib=static=crypto
  cargo:rustc-link-lib=static=ssl
  cargo:rustc-link-lib=static=sodium
  cargo:rustc-link-lib=static=secp256k1
  CMAKE_TOOLCHAIN_FILE_aarch64-apple-darwin = None
  CMAKE_TOOLCHAIN_FILE_aarch64_apple_darwin = None
  HOST_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_aarch64-apple-darwin = None
  CMAKE_GENERATOR_aarch64_apple_darwin = None
  HOST_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_aarch64-apple-darwin = None
  CMAKE_PREFIX_PATH_aarch64_apple_darwin = None
  HOST_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_aarch64-apple-darwin = None
  CMAKE_aarch64_apple_darwin = None
  HOST_CMAKE = None
  CMAKE = None
  running: cd "/dev/project/target/debug/build/tonlibjson-sys-84f116fed36e0b68/out/build" && CMAKE_PREFIX_PATH="" "cmake" "/root/.cargo/git/checkouts/ton-grpc-8931e6ba334d2bde/f257c0d/tonlibjson-sys/ton-testnet" "-DCMAKE_OSX_ARCHITECTURES=arm64" "-DTON_ONLY_TONLIB=ON" "-DCMAKE_C_COMPILER=clang" "-DCMAKE_CXX_COMPILER=clang++" "-DCMAKE_CXX_STANDARD=14" "-DBUILD_SHARED_LIBS=OFF" "-DSODIUM_USE_STATIC_LIBS=OFF" "-DPORTABLE=ON" "-DTON_ARCH=x86-64" "-DCMAKE_SYSTEM_NAME=Darwin" "-DCMAKE_SYSTEM_PROCESSOR=arm64" "-DCMAKE_INSTALL_PREFIX=/root/dev/project/target/debug/build/tonlibjson-sys-84f116fed36e0b68/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=arm64-apple-darwin -mmacosx-version-min=10.11 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" "-DCMAKE_CXX_FLAGS= -std=c++14 -stdlib=libc++ -ffunction-sections -fdata-sections -fPIC --target=arm64-apple-darwin -mmacosx-version-min=10.11 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=arm64-apple-darwin -mmacosx-version-min=10.11 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Debug"
  -- The C compiler identification is AppleClang <IP_ADDRESS>00100
  -- The CXX compiler identification is AppleClang <IP_ADDRESS>00100
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: /usr/bin/clang - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /usr/bin/clang++ - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Performing Test CRC32C_HAVE_SSE42
  -- Performing Test CRC32C_HAVE_SSE42 - Failed
  -- Performing Test ROCKSDB_HAVE_SSE42
  -- Performing Test ROCKSDB_HAVE_SSE42 - Failed
  -- Performing Test CRC32C_HAVE_NO_DEPRECATED
  -- Performing Test CRC32C_HAVE_NO_DEPRECATED - Success
  -- Performing Test CRC32C_HAVE_NO_SIGN_COMPARE
  -- Performing Test CRC32C_HAVE_NO_SIGN_COMPARE - Success
  -- Performing Test CRC32C_HAVE_NO_UNUSED_PARAMETER
  -- Performing Test CRC32C_HAVE_NO_UNUSED_PARAMETER - Success
  -- Performing Test CRC32C_HAVE_NO_MISSING_FIELD_INITIALIZERS
  -- Performing Test CRC32C_HAVE_NO_MISSING_FIELD_INITIALIZERS - Success
  -- Performing Test HAVE_BUILTIN_PREFETCH
  -- Performing Test HAVE_BUILTIN_PREFETCH - Success
  -- Performing Test HAVE_MM_PREFETCH
  -- Performing Test HAVE_MM_PREFETCH - Failed
  -- Performing Test HAVE_ARM64_CRC32C
  -- Performing Test HAVE_ARM64_CRC32C - Success
  -- Performing Test HAVE_STRONG_GETAUXVAL
  -- Performing Test HAVE_STRONG_GETAUXVAL - Failed
  -- Performing Test HAVE_WEAK_GETAUXVAL
  -- Performing Test HAVE_WEAK_GETAUXVAL - Failed
  -- Could NOT find ccache
  -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
  -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
  -- Found Threads: TRUE
  -- Found PkgConfig: /opt/homebrew/bin/pkg-config (found version "0.29.2")
  -- Found ZLIB: /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/lib/libz.tbd (found version "1.2.12")
  -- Performing Test COMPILER_OPT_ARCH_SUPPORTED
  -- Performing Test COMPILER_OPT_ARCH_SUPPORTED - Failed
  -- Performing Test HAVE_CXX_FLAG_WALL
  -- Performing Test HAVE_CXX_FLAG_WALL - Success
  -- Performing Test HAVE_CXX_FLAG_WEXTRA
  -- Performing Test HAVE_CXX_FLAG_WEXTRA - Success
  -- Performing Test HAVE_CXX_FLAG_WIMPLICIT_FALLTHROUGH_2
  -- Performing Test HAVE_CXX_FLAG_WIMPLICIT_FALLTHROUGH_2 - Failed
  -- Performing Test HAVE_CXX_FLAG_WPOINTER_ARITH
  -- Performing Test HAVE_CXX_FLAG_WPOINTER_ARITH - Success
  -- Performing Test HAVE_CXX_FLAG_WCAST_QUAL
  -- Performing Test HAVE_CXX_FLAG_WCAST_QUAL - Success
  -- Performing Test HAVE_CXX_FLAG_WSIGN_COMPARE
  -- Performing Test HAVE_CXX_FLAG_WSIGN_COMPARE - Success
  -- Performing Test HAVE_CXX_FLAG_WDUPLICATED_BRANCHES
  -- Performing Test HAVE_CXX_FLAG_WDUPLICATED_BRANCHES - Failed
  -- Performing Test HAVE_CXX_FLAG_WDUPLICATED_COND
  -- Performing Test HAVE_CXX_FLAG_WDUPLICATED_COND - Failed
  -- Performing Test HAVE_CXX_FLAG_WALLOC_ZERO
  -- Performing Test HAVE_CXX_FLAG_WALLOC_ZERO - Failed
  -- Performing Test HAVE_CXX_FLAG_WLOGICAL_OP
  -- Performing Test HAVE_CXX_FLAG_WLOGICAL_OP - Failed
  -- Performing Test HAVE_CXX_FLAG_WTAUTOLOGICAL_COMPARE
  -- Performing Test HAVE_CXX_FLAG_WTAUTOLOGICAL_COMPARE - Success
  -- Performing Test HAVE_CXX_FLAG_WVLA
  -- Performing Test HAVE_CXX_FLAG_WVLA - Success
  -- Performing Test HAVE_CXX_FLAG_WNON_VIRTUAL_DTOR
  -- Performing Test HAVE_CXX_FLAG_WNON_VIRTUAL_DTOR - Success
  -- Performing Test HAVE_CXX_FLAG_WUNUSED_PARAMETER
  -- Performing Test HAVE_CXX_FLAG_WUNUSED_PARAMETER - Success
  -- Performing Test HAVE_CXX_FLAG_WCONVERSION
  -- Performing Test HAVE_CXX_FLAG_WCONVERSION - Success
  -- Performing Test HAVE_CXX_FLAG_WSIGN_CONVERSION
  -- Performing Test HAVE_CXX_FLAG_WSIGN_CONVERSION - Success
  -- Performing Test HAVE_CXX_FLAG_QUNUSED_ARGUMENTS
  -- Performing Test HAVE_CXX_FLAG_QUNUSED_ARGUMENTS - Success
  -- Performing Test HAVE_CXX_FLAG_WUNUSED_PRIVATE_FIELD
  -- Performing Test HAVE_CXX_FLAG_WUNUSED_PRIVATE_FIELD - Success
  -- Performing Test HAVE_CXX_FLAG_WREDUNDANT_MOVE
  -- Performing Test HAVE_CXX_FLAG_WREDUNDANT_MOVE - Success
  -- Could NOT find LATEX (missing: LATEX_COMPILER)
  -- Could NOT find LATEX (this is NOT an error)
  -- Found ZLIB: /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/lib/libz.tbd
  -- Found OpenSSL<EMAIL_ADDRESS>(found version "3.3.0")
  -- Checking for module 'liblz4'
  --   Found liblz4, version 1.9.4
  -- Found LZ4 lz4 /opt/homebrew/Cellar/lz4/1.9.4/include
  -- Performing Test GNU_READLINE_FOUND
  -- Performing Test GNU_READLINE_FOUND - Failed
  -- Could NOT find Readline (missing: READLINE_INCLUDE_DIR READLINE_LIBRARY)
  -- Could NOT find Readline (this is NOT an error)
  -- Found Secp256k1: /opt/homebrew/lib/libsecp256k1.dylib
  -- Found Secp256k1: /opt/homebrew/include
  -- Found Sodium: /opt/homebrew/Cellar/libsodium/1.0.19/lib/libsodium.dylib
  -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
  -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
  -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
  -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
  -- Performing Test COMPILER_HAS_DEPRECATED_ATTR
  -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
  -- Configuring done (4.9s)

  --- stderr
  ton dir is ton-testnet
  Add crc32c
  CMake Deprecation Warning at third-party/crc32c/CMakeLists.txt:5 (cmake_minimum_required):
    Compatibility with CMake < 3.5 will be removed from a future version of
    CMake.

    Update the VERSION argument <min> value or use a ...<max> suffix to tell
    CMake that the project does not need compatibility with older versions.

  Add ton
  CMake Error at crypto/CMakeLists.txt:378 (add_library):
    Cannot find source file:

      /root/.cargo/git/checkouts/ton-grpc-8931e6ba334d2bde/f257c0d/tonlibjson-sys/ton-testnet/crypto/block/block-auto.cpp

    Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm
    .ccm .cxxm .c++m .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90
    .f95 .f03 .hip .ispc

  CMake Error at crypto/CMakeLists.txt:378 (add_library):
    No SOURCES given to target: ton_block

  CMake Generate step failed.  Build files cannot be regenerated correctly.
  thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cmake-0.1.50/src/lib.rs:1098:5:

  command did not execute successfully, got: exit status: 1

  build script failed, must exit now
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Turns out that there are two issues:

aarch64 is not supported by tonlibjson-sys/build.rs
cmake::Config::use_cxx11() breaks code generation somehow, I didn't dig too deep, so it's still an open question for me. I removed it and it works 🤔

Here is a small fix for the build script to make it compile to native arch. It uses the same approach as in build-macos-portable.rs except for couple of unnecessary(?) dependencies.
Hope it helps!

Hello, @mitinarseny! Thank you for your work!
It seems there is an issue with the build on x86-64 platforms. The CARGO_CFG_TARGET_ARCH is set to x86_64, but cmake expects x86-64. Could you please look into this? Fixing this might not resolve all issues, but it’s a necessary first step.
UPD: I'm also unsure if using native architecture is an option, as it will likely affect the binary's portability.

Thanks again, I will fix regression in next PRs.


Change ref to _Fref in Promise object

TL;DR
Please replace this text with a description of what this PR accomplishes.
Changes ref to _Fref to make sure there's no conflict with tasks that have ref as output.
closes https://github.com/flyteorg/flyte/issues/3923
Type

[x] Bug Fix
[ ] Feature
[ ] Plugin

Are all requirements met?

[x] Code completed
[ ] Smoke tested
[x] Unit tests added
[ ] Code documentation added
[ ] Any pending items have an associated Issue

Complete description
How did you fix the bug, make the feature etc. Link to any design docs etc
Renamed ref to _Fref
Tracking Issue
https://github.com/flyteorg/flyte/issues/3923
Follow-up issue
NA

I want to hold off on this PR actually... need to revisit the code around this a bit.  want to understand a bit more how this ref property is used.

See https://github.com/flyteorg/flytekit/pull/1794


"@grpc/grpc-js only works on Node ^8.13.0 || >=10.10.0"

If you are still having issues, please be sure to include as much information as possible:
Environment details

OS: Windows 10
Node.js version: 9.11.2
npm version: 5.6.0
@google-cloud/firestore version: 2.0.0

Steps to reproduce

db = new Firestore(config)
db.collection("/stuff").doc("a");
doc.create( {hi: "world"} );

This will give you the "Error: @grpc/grpc-js only works on Node ^8.13.0 || >=10.10.0"

I realize I only have node 9.11.2, but I can't change that on the server.. Is there any way to have this work with node 9.11.2?

@cyraid Thanks for reporting this issue and sorry for disappointing you! Node 9 was End of Lifed in June 2018. We currently only support releases considered active by the Node working group. If you need to use an older version of Node, your best bet is to stick with 1.x Firestore until you can upgrade your Node environment.
You should also be able to pass in your GRPC module to the Firestore constructor. I have never tested this, but it looks like it would work as such:
const firestore = new Firestore( { grpc:require('grpc') } );


Selecting a data collection tier in Azure Security Center WITHOUT auto provisioning

Hi
Is it not possible to select how much security events are collected without turning on auto-provisioning ?
Links to manual steps point to pages ending up in log analytics -> advanced and there Security Event log is not listen.

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

ID: 8267e218-3748-2820-3eee-80479705eec2
Version Independent ID: 8c6d5fce-6383-a0f8-7df3-f5e0a77bbad6
Content: Data Collection in Azure Security Center
Content Source: articles/security-center/security-center-enable-data-collection.md
Service: security-center
GitHub Login: @memildin
Microsoft Alias: memildin

Thanks for the feedback! We are currently investigating and will update you shortly.

@PatrikHanssonIntersolia  In order to collect the data from machines you need to have log analytics agent installed either manually or via auto provisioning.

@PatrikHanssonIntersolia No, it cannot be done as to collect the data from machines you need to have log analytics agent installed either manually or via auto provisioning.

I'm sorry but that response makes no sense, if the agent is installed by previous log analytics enrollment the agent is already there and the dependency you mention is met.

@PatrikHanssonIntersolia As mentioned in the Automatic provisioning in cases of a pre-existing agent installation in case your scenarios falls under any these categories.
Also, you need to turn on the auto provisioning to configure what all security events (all, common, minimal) you want to capture.

Hi
Ok Thanks. I also found a setting under the Workspaces that has the same settings without enabling auto provisioning. Are those not in effect either until auto provisioning are enabled ?

@PatrikHanssonIntersolia  yes, that is correct - you need to enable auto provisioning to configure those settings.

@PatrikHanssonIntersolia We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


Failed to get kubernetes address: No kubernetes source found.

Hi!
I try to deploy metrics-server to my kubernetes cluster(bare metal):
[root@node1 metrics-server]# kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.5", GitCommit:"f01a2bf98249a4db383560443a59bed0c13575df", GitTreeState:"clean", BuildDate:"2018-03-19T15:50:45Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.5", GitCommit:"f01a2bf98249a4db383560443a59bed0c13575df", GitTreeState:"clean", BuildDate:"2018-03-19T15:50:45Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
[root@node1 metrics-server]# kubectl get pods --namespace=kube-system --selector=k8s-app=metrics-server
NAME                              READY     STATUS    RESTARTS   AGE
metrics-server-6cf87b9c8d-nvm9j   0/1       Error     8          16m
[root@node1 metrics-server]# kubectl logs metrics-server-6cf87b9c8d-nvm9j -n kube-system
I0814 08:12:57.748260       1 heapster.go:71] /metrics-server
I0814 08:12:57.748292       1 heapster.go:72] Metrics Server version v0.2.1
F0814 08:12:57.748300       1 heapster.go:79] Failed to get kubernetes address: No kubernetes source found.
[root@node1 metrics-server]# kubectl get apiservice v1beta1.metrics.k8s.io -o yaml
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
creationTimestamp: 2018-08-14T07:40:59Z
name: v1beta1.metrics.k8s.io
resourceVersion: "13893882"
selfLink: /apis/apiregistration.k8s.io/v1beta1/apiservices/v1beta1.metrics.k8s.io
uid: 63107df3-9f95-11e8-a53f-00259047efc9
spec:
caBundle: null
group: metrics.k8s.io
groupPriorityMinimum: 100
insecureSkipTLSVerify: true
service:
name: metrics-server
namespace: kube-system
version: v1beta1
versionPriority: 100
status:
conditions:

lastTransitionTime: 2018-08-14T07:40:59Z
message: endpoints for service/metrics-server in "kube-system" have no addresses
reason: MissingEndpoints
status: "False"
type: Available

Please helm with this issue!
Thank you!

When I pulled the project yesterday, I got an updated deploy/1.8+/metrics-server-deployment.yaml which is missing a command: stanza for the container: definition. I was able to fix by deleting the deployment, editing the file so the container definition reads:
containers:
      - name: metrics-server
        image: gcr.io/google_containers/metrics-server-amd64:v0.2.1
        imagePullPolicy: Always
        command:
        - /metrics-server
        - --source=kubernetes.summary_api:''
        volumeMounts:
        - name: tmp-dir
          mountPath: /tmp

..then re-deploying. I suspect change a823af8 ("Refactor Makefile and update Dockerfile") is the cause, but I can't explain why (as I'd pulled the project onto another cluster after that change and had it work OK).

Ok! work fine after this changes but please tell me:
E0814 14:46:05.004234       1 summary.go:97] error while getting metrics summary from Kubelet node1(<IP_ADDRESS>:10255): Get http://89.108.x.x:10255/stats/summary/: dial tcp 89.108.x.x:10255: getsockopt: connection refused
my kubelet on port 10250.
kubelet   1477   root   19u  IPv4  26755      0t0  TCP 89.108.x,x:10250 (LISTEN)
how to change port  for metrics-server?
maybe documentation? could not find

Aha, there's been a recent change and the read-only port used for metric gathering is disabled by default now. The quick hack to fix this is to add:
readOnlyPort: 10255

...to the bottom of /var/lib/kubelet/config.yaml and re-start kubelet (systemctl stop kubelet; sleep 10; systemctl start kubelet).

please don't do that.  You should be using the authenticated port when possible.  There's a reason the unauthenticated (read-only) port was disabled.

@DirectXMan12 Instructions for configuring metrics-server to do so would be greatly appreciated, because I looked but I did not find.

yep.  That'll be the default (and only) option in the next released version (master today).  Speaking of which, @kawych can we get a beta release pushed so people can try out the new version more?

Hi!
Any updates?
Thank you!

Sorry, can't help you. At a guess - and it is only a guess - you might need to re-run metrics-server/deploy/1.8+/auth-reader.yaml to (re-)create the role?

yes. i recreate role, but ... no effect.

same troubles

Same problem here.
1 heapster.go:72] Metrics Server version v0.2.1
1 heapster.go:79] Failed to get kubernetes address: No kubernetes source found.```

I have the same issue as well, seems that deploy/1.8+/ is broken

FYI anyone getting:
heapster.go:79] Failed to get kubernetes address: No kubernetes source found.

@unclok found a solution that seems to be working for a lot of people over in: https://github.com/kubernetes-incubator/metrics-server/issues/97#issuecomment-412394545

Hi!
At this moment error in pod metrics-server
E0814 19:14:05.017995 1 summary.go:97] error while getting metrics summary from Kubelet node1(89.108.x.x:10250): request failed - "401 Unauthorized", response: "Unauthorized"
E0814 19:14:05.018016 1 summary.go:97] error while getting metrics summary from Kubelet node2(89.108.x.x:10250): request failed - "401 Unauthorized", response: "Unauthorized"
E0814 19:14:05.027822 1 summary.go:97] error while getting metrics summary from Kubelet node3(89.108.x.x:10250): request failed - "401 Unauthorized", response: "Unauthorized"

I am also getting unauthorized 401 error

I don't know if it's the same for minikube, but I've just installed it and cloned this repo.
Running the creation of Metrics Server, I got this error:
I0830 14:55:46.240497       1 heapster.go:71] /metrics-server
I0830 14:55:46.240548       1 heapster.go:72] Metrics Server version v0.2.1
F0830 14:55:46.240555       1 heapster.go:79] Failed to get kubernetes address: No kubernetes source found.

Any hint?

Has anyone found a solution to fix it?

Can you try to reproduce it on newer version of metrics-server v0.3+?


Service and some shared templates not generated by extract tool

Description:
When trying to extract the ARM templates, the service template and some shared templates, like the identity providers for example, are not generated resulting in not been able to provision new APIM instances or deploy important features.
I have verified that release 0.7 presents the same problem but I am not sure when this problem started to appear since some ARM templates previously generated (not sure what version was used) do not present this problem.
DevOps Resource Kit version:
1.0.0-beta.2 release binaries
dotnet version:
6.0.100-rc.2.21505.57
OS and version:
Windows 11 Pro, build 22000.651
Command:
.\ArmTemplates.exe extract --sourceApimName "my-apim-instance-dev" --destinationApimName "my-apim-instance-ci" --resourceGroup "my-apim-instance-dev-rg" --fileFolder "C:\Temp\my-apim-instance-ci" --splitAPIs true --linkedTemplatesBaseUrl "https://somewhere.blob.core.windows.net/apim-templates" --linkedTemplatesSasToken "token-here" --policyXMLBaseUrl "https://somewhere.blob.core.windows.net/apim-templates/policies" --policyXMLSasToken "token-here" --baseFileName "apim" --paramServiceUrl true --paramNamedValue true --paramApiLoggerId true --paramLogResourceId true --paramNamedValuesKeyVaultSecrets true --paramBackend true
API Management Instance set up:
SKU: Developer
Full admin rights to the service: yes
Service in a VNET: issue occurs with and without Vnet.

Description:
When trying to extract the ARM templates, the service template and some shared templates, like the identity providers for example, are not generated resulting in not been able to provision new APIM instances or deploy important features.
I have verified that release 0.7 presents the same problem but I am not sure when this problem started to appear since some ARM templates previously generated (not sure what version was used) do not present this problem.
DevOps Resource Kit version:
1.0.0-beta.2 release binaries
dotnet version:
6.0.100-rc.2.21505.57
OS and version:
Windows 11 Pro, build 22000.651
Command:
.\ArmTemplates.exe extract --sourceApimName "my-apim-instance-dev" --destinationApimName "my-apim-instance-ci" --resourceGroup "my-apim-instance-dev-rg" --fileFolder "C:\Temp\my-apim-instance-ci" --splitAPIs true --linkedTemplatesBaseUrl "https://somewhere.blob.core.windows.net/apim-templates" --linkedTemplatesSasToken "token-here" --policyXMLBaseUrl "https://somewhere.blob.core.windows.net/apim-templates/policies" --policyXMLSasToken "token-here" --baseFileName "apim" --paramServiceUrl true --paramNamedValue true --paramApiLoggerId true --paramLogResourceId true --paramNamedValuesKeyVaultSecrets true --paramBackend true
API Management Instance set up:
SKU: Developer
Full admin rights to the service: yes
Service in a VNET: issue occurs with and without Vnet.

Do you have a canonical list of things that are not extracted?
We can, of course, just extract the identity providers, but we'll bump into the next thing and the next thing.  It would be better to get a list of what's not working for you.

So far I am missing the service ("type": "Microsoft.ApiManagement/service") and identity providers ("type": "Microsoft.ApiManagement/service/identityProviders") templates.
Also on release 0.7 the top level groups were missing as well ("type": "Microsoft.ApiManagement/service/groups") but I noticed that beta 2 now generates the groups template (but doesn't link this template). I was going to open a new bug for this issue.

Do you have a canonical list of things that are not extracted?
We can, of course, just extract the identity providers, but we'll bump into the next thing and the next thing. It would be better to get a list of what's not working for you.

See below, so far missing service and identity providers.

Please open a new issue for the service/groups not being linked.  We can handle that one separately.

Hello @JCallico.
Two PRs were merged recently which introduced extraction of

Microsoft.ApiManagement/service PR
Microsoft.ApiManagement/service/identityProviders PR

Please feel free to open a new bug in case you will face problems with those two extracted services/resources, or feature request.
Identity providers resources are available in 1.0.0-beta.7
Microsoft.ApiManagement/service is available in main branch and will be available in future releases.
Closing the issue, since two resources are covered and merged.
Best regards


Missing 'JSON' files or 'full_experiment_real_data' directory

Hi all,
Thanks for your time and attention. I am debugging the 'Processing new data' step. However, it seems there was no '../data/ggnn_input/devign_cfg_full_text_files.json' file and 'full_experiment_real_data' directory. I have downloaded all the data with the script 'bash get_data.sh'. Would anyone could give me some advice?
Kind regards,

ggnn_input/devign_cfg_full_text_files.json is inside the replication package for me (replication.zip), so it should be unzipped at the right place. Maybe you should check that your current working directory is correct.
full_experiment_real_data is the output of create_ggnn_data.py, see here: https://github.com/VulDetProject/ReVeal/blob/ca31b783384b4cdb09b69950e48f79fa0748ef1d/data_processing/create_ggnn_data.py#L387
Hope this helps.

Hi @bstee615 ,
Thanks for your kindly reply. I have unzipped and checked the again and still cannot find the ggnn_input/devign_cfg_full_text_files.json file. Would u plz provide me the latest download link of the replication.zip package?
Regards,
jywuxi

Believe it's the link from get_data.sh, here: https://drive.google.com/file/d/1Mn0jLaZWiPFQ8ejzlz_zXnx_TcSzbwu1

@bstee615 @QiuJYWX Can you re-provide a link? The original link is not working. Thanks.

@bstee615 the link is not working now,can you share the data downloaded by the link?

@silver-en @zzhisthebest I did not create this link, I only echo the link inside get_data.sh (I was not involved in writing this paper). Looks like it's up to the original authors to provide a new link.


permission to other users to create dashboards.

Purpose

Resolves https://github.com/wso2/docs-apim/issues/1838 for 3.1.0

@Mariangela Looks like it is already there[1,2]
[1] https://apim.docs.wso2.com/en/latest/learn/analytics/customizing-analytics-dashboards/
[2] https://github.com/wso2/docs-apim/issues/1838#issuecomment-727851966


fix: Aviation Test

Following the failure here: https://github.com/datafaker-net/datafaker/actions/runs/9324424830/job/25669623466#step:4:1
Which apparently only had a 1 in 4037 chance of happening on any given test run, lucky us :grinning:
I threw together this temporary test (I'm sure there are more elegant ways to do this, it was just a quick thing):
@Test
void checkLengths() {
	List<String> entries = getBaseList("aviation.airport");
	System.out.println(entries.size());
	Map<Integer, Integer> lenMap = new HashMap<>();
	lenMap.put(1, 0);
	lenMap.put(2, 0);
	lenMap.put(3, 0);
	lenMap.put(4, 0);
	lenMap.put(5, 0);
	lenMap.put(6, 0);
	for (String entry : entries) {
		Integer count = lenMap.get(entry.length());
		count++;
		lenMap.put(entry.length(), count);
		if (entry.length() != 4) {
			System.out.println(entry);
		}
	}
	System.out.println(lenMap);
}

Which produced:
4037
N55
{1=0, 2=0, 3=1, 4=4036, 5=0, 6=0}

Indeed N55 is a valid airport: https://www.google.com/search?q=N55+airport - Jaluit Airport
So I've adjusted the regex in the test to allow length 3 or 4.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.71%. Comparing base (b37c566) to head (ad08e81).
Report is 144 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #1241      +/-   ##
============================================
- Coverage     92.35%   91.71%   -0.64%
- Complexity     2821     3032     +211
============================================
  Files           292      309      +17
  Lines          5609     5986     +377
  Branches        599      629      +30
============================================
+ Hits           5180     5490     +310
- Misses          275      331      +56
- Partials        154      165      +11

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


Device Linking and better linking ui

About the PR

This basically moves machine linking on top of of device networking, allowing it to use device networking to invoke ports and send data along.
Functionality wise device linking is a drop in replacement for machine linking except some renamed stuff.
Most notably transmitters are called sources and receivers are called sinks now.
Using device networking is optional and if either the source or the sink doesn't have a DeviceNetworkComponent it just raises the SignalReceivedEvent without using networking or sending data along.
When using device networking, links can use connection checks like the WirelessNetworkConnection or the StationBoundNetworkConnection (form #7542) and work alongside normal device networking.
The UI for linking also got updated and now uses bézier curves to display links instead of straight lines.
Linking is done with the Network Configurator, which also does configuring device lists.
The Network Configurator has two modes: List and Link.
You can switch between modes by pressing the alt interact hand key bind. Which is alt+z or alt+y by default.
Linking devices together using device linking is done by switching the Network Configurator to Link mode and clicking on a source device and a sink device. Just link machine linking.
Device linking also supports machine linkings alt interaction and auto linking.
Media

The new linking ui

The item status added for the network configurator

[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: The network configurator. A tool used to link devices together.
tweak: Configuring device lists is now done using the network configurator instead of the multitool.

I'm almost done with this PR but I still need to do some things:

[ ] Write proper doc comments
[ ] Write a guidebook entry
[ ] Add ways to obtain the network configurator

The yaml linter says CC-0 is not a proper license

The yaml linter says CC-0 is not a proper license

I think you need CC0-1.0

The yaml linter says CC-0 is not a proper license

Licenses must be in the format of SPDX Identifiers

This is probably ready for review now :sweat_drops:

Links done with machine linking already present on maps won't break because device linking translates them to device linking links on map init but mappers should still update their maps when this gets merged.

I've fixed conflicts for you

This PR is getting unrelated test failures from the PR that renames the janicart.

Should be fixed after tests finish running

Its kinda late so tell me if something i rambled about here doesnt make sense/isnt possible/is out of scope:
...

Thanks for the review 👍
Most of the points you mentioned aren't out of scope.
Changing the overlay is a little bit out of scope though and I want to improve it anyway so I will do that together with the improvement I plan on doing in another PR.
A few machines that used machine linking and got ported over to device linking have the device list component for some reason, even though they don't use device lists. I'm just gonna remove that component from them.

An item mapper for the network configurator in the belt would be nice (if there is one already it isnt working)

What do you mean by that?

I'm also not 100% sure if I like the mode switching or if I should just make it open the right ui by default. Most things wouldn't use linking and lists at the same time and if they do I can just have the list ui open using alt interact.
What are your thoughts on switching modes vs just opening the correct UI and using alt interact for edge cases?

What do you mean by that?

the belt prototype has a item mapper component thats used for the tools appearance in the belt sprite

What are your thoughts on switching modes vs just opening the correct UI and using alt interact for edge cases?

I think opening the correct UI and still having the option to switch modes would be best, with a message in the ui or a popup telling you that the device doesnt support linking/listings and maybe a "switch to list /link" in the UI, having a way to differentiate the target list UI from the network configurator list would also help (maybe separate some of their behavior because if you close the target one it closes the configurator one)

Make net config link BUI open centered to the right, not in the middle (the small one does, the big one with copy, show, etc buttons doesnt)
@AJCM-git It opens centered to not conflict with the small one (the saved devices ui)


1445/wpml urls

Ticket: #1445

Coverage increased (+0.09%) to 93.396% when pulling 0622beb6f0f89776488a568f00bb7e3d3738ba86 on 1445/wpml_urls into ddf0031fc99c8a48d601193cca0a7be17ae91320 on master.

Coverage increased (+0.08%) to 93.393% when pulling 1b37058117c02d8d215e8497779cd9f6966827e1 on 1445/wpml_urls into ddf0031fc99c8a48d601193cca0a7be17ae91320 on master.

Thanks @jarednova , your solution looks much more robust.. which can only come from having good knowledge of the library I guess ;)


Unable to access the api !

I have deployed my own forked instance on vercel ,but when i try using my vite react application, it gives unauthorized error:-
this is the error:-
XHRGET
http://localhost:5173/api/anime/search?q=dd&page=1
[HTTP/1.1 401 Unauthorized 121ms]
Response { type: "basic", url: "http://localhost:5173/api/anime/search?q=dd&page=1", redirected: false, status: 401, ok: false, statusText: "Unauthorized", headers: Headers(11), body: ReadableStream, bodyUsed: false }
App.tsx:20:14
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data App.tsx:30:14
but when I open it on the browser, there is slight confirmation of authorization success from vercel and it gives the response...
am i missing something?

I solved it , i tweaked the settings in vercel.

Nice


Adds support for og:locale

This pull request adds the possibility to set and/or overwrite the Open Graph content language property:
seo()->locale('de_DE');

Output:
<meta property="og:locale" content="de_DE" />

Clean PR, thanks for contributing!


Can you share the origin data with ground of the processed KITTI scene flow dataset?

Can you share the origin data with ground LiDAR info?

Hi,
Is there any update on this issue? I am also looking for the kitti scene flow point cloud data (lidar) without removing the ground plane.
Many thanks.

Hi, Is there any update on this issue? I am also looking for the kitti scene flow point cloud data (lidar) without removing the ground plane. Many thanks.

found. Weakly Supervised Learning of Rigid 3D Scene Flow


Create 69 Frogs Collection

The slug in meta.json must be consistent with the file name, please modify it. thanks~


[FEATURE REQUEST] Make Ruby spec tests code compliant with rubocop lint rules

Is your feature request related to a problem? Please describe.
After adding rubocop linter to Azure Pipeline it reports many failures in tests/spec code and as we don't want to have workaround for checking failures threshold we have to correct tests/spec code.
Describe the solution you'd like
After running autocorrect proposed by rubocop we can manually updated rest of the failures. As the result there should be no failures reported by rubocop.
Additional context
This needs to be tested to ensure that any change in code is not breaking the tests.

DoD checklist

[ ] Changelog updated
[ ] COMPONENTS.md updated / doesn't need to be updated
[ ] Schema updated / doesn't need to be updated
[ ] Feature has automated tests
[ ] Automated tests passed (QA pipelines)

[ ] apply
[ ] upgrade

[ ] Idempotency tested
[ ] Documentation added / updated / doesn't need to be updated
[ ] All conversations in PR resolved
[ ] Solution meets requirements and is done according to design doc
[ ] Usage compliant with license
[ ] Backport tasks created / doesn't need to be backported

All test cases run correctly. The failures reported by linter have been significantly reduced.


Migrate to Polymer 1.0

Now that Polymer is 1.0, will this package get an update?

I'm in the middle of a complete refactor of useraccounts.
I don't think I'll have time to look at this for a while... :(
Would you be willing to create a PR for this?
@meteor-useraccounts/polymer?

I'm migrating my current project to Polymer 1.0 so I'll happily do useraccounts as well while I'm at it and submit a PR when it's done. No guarantees on the timeline though.

:+1:
no worries for the timeline, you're welcome to contribute.
Thanks!

Would be great to have useraccounts with Polymer 1.0 :+1:

@meteor-useraccounts/polymer?

@ThaumRystra Can you migrate it to Polymer v1.0? I am thinking of using the package.

I would second that request from @itsashis4u . Any chance someone can migrate it to Polymer 1.0?
@ThaumRystra Stefan?
@splendido Luca, any update on the refactor?

i for myself am not planning to work on this package in the foreseable
future, i've dropped Polymer with Meteor all together.
but never say never, we never know, might come back some day :)
On Sat, Sep 26, 2015 at 8:26 PM Andreas West<EMAIL_ADDRESS>wrote:

I would second that request from @itsashis4u
https://github.com/itsashis4u . Any chance someone can migrate it to
Polymer 1.0?
@ThaumRystra https://github.com/ThaumRystra Stefan?
@splendido https://github.com/splendido Luca, any update on the
refactor?
—
Reply to this email directly or view it on GitHub
https://github.com/meteor-useraccounts/polymer/issues/9#issuecomment-143478185
.

Hi all, I tried to make the update a couple weeks ago, but I had some problem figuring out wich package to use to test with polymer 1.0.
I tried boxxa:polymer but got this issue.
Do you know whether ecwyne:polymer is up to date and working?
Which package are you using to get<EMAIL_ADDRESS>

@kevohagan am I understanding it right? No more Meteor?!

NOooooo never!! I will never drop meteor, just not Meteor + Polymer! ;)
On Sun, Sep 27, 2015 at 11:07 AM Luca Mussi<EMAIL_ADDRESS>wrote:

@kevohagan https://github.com/kevohagan am I understanding it right? No
more Meteor?!
—
Reply to this email directly or view it on GitHub
https://github.com/meteor-useraccounts/polymer/issues/9#issuecomment-143532403
.

Well, close to give up on Meteor on front-end as well as it doesn't seem to
work well with Polymer which is more important for me.
I don't understand why you guys are focussing so much on Angular (which is
about to change and so out of fashion). At least I understand the focus on
the new darling React.js
On 27 Sep 2015 17:07, "Luca Mussi"<EMAIL_ADDRESS>wrote:

@kevohagan https://github.com/kevohagan am I understanding it right? No
more Meteor?!
—
Reply to this email directly or view it on GitHub
https://github.com/meteor-useraccounts/polymer/issues/9#issuecomment-143532403
.

Yes, there has not been a good solution for Meteor + Polymer yet...
I disagree with you, even though I haven't tried Angular 2 , from what i've
seen it's not going to be out of fashion.
And React is definitely great news, so easy to work with, plus react native
is very promising.
On Sun, Sep 27, 2015 at 12:01 PM Andreas West<EMAIL_ADDRESS>wrote:

Well, close to give up on Meteor on front-end as well as it doesn't seem to
work well with Polymer which is more important for me.
I don't understand why you guys are focussing so much on Angular (which is
about to change and so out of fashion). At least I understand the focus on
the new darling React.js
On 27 Sep 2015 17:07, "Luca Mussi"<EMAIL_ADDRESS>wrote:

@kevohagan https://github.com/kevohagan am I understanding it right?
No
more Meteor?!
—
Reply to this email directly or view it on GitHub
<
https://github.com/meteor-useraccounts/polymer/issues/9#issuecomment-143532403
.

—
Reply to this email directly or view it on GitHub
https://github.com/meteor-useraccounts/polymer/issues/9#issuecomment-143534289
.

@splendido I am using loneleeandroo:polymerize to include Polymer 1.0 and replace Shady DOM with Shadow DOM. It somewhat works.
Also, ecwyne:polymer doesn't feel like updated to 1.0.
I had used boxxa:polymer but then I ran into some errors and had to remove it.

I would second that request from @itsashis4u . Any chance someone can migrate it to Polymer 1.0?
@ThaumRystra Stefan?

This got put on the back-burner for me, since I delayed migrating one of my projects to 1.0 for a bunch of other reasons. I'll take a look at it again today.

Which package are you using to get<EMAIL_ADDRESS>
@splendido I'm using Bower to install Polymer 1.0 and differential:vulcanize to get it imported, you can check out this project for an example of Polymer 1.0 running in Meteor. differential:vulcanize should be updated to run on Meteor 1.2 soon.


[BUG] select from table limit reads the full dataset and persists in memory.

What happened:
When performing a SELECT * FROM table LIMIT 10, from a table read in via parquet, I notice the full dataset being read and persisted on query execution.
What you expected to happen:
Nothing to happen at query execution and when the user does decide to persist/compute the result only the relevant subset of data is read in.
Minimal Complete Verifiable Example:
from dask_cuda import LocalCUDACluster
from distributed import Client, wait
import cudf
import dask_cudf
from dask_sql import Context
import dask

write_data = False

if __name__ == "__main__":
    cluster = LocalCUDACluster()
    client = Client(cluster)
    c = Context()

    if write_data:
        dask.datasets.timseries(start="2022-01-01", end="2024-01-01").to_parquet("test_data.parquet")

    ddf = dask_cudf.read_parquet("test_data.parquet")
    c.create_table("test", ddf, persist=False)

    # This results in the whole dataset persisted in memory and even though `len(res)==5` all the data is in memory
    res = c.sql("SELECT * from test LIMIT 10")

Anything else we need to know?:
Environment:

dask-sql version: 2022.1.0
Python version: 3.8
Operating System: ubuntu 18.04
Install method (conda, pip, source): conda

Looks like this is happening because of a direct call to persist() in _apply_offset:
https://github.com/dask-contrib/dask-sql/blob/b571a600a639f0dcabd9d0162d01d078472e3e51/dask_sql/physical/rel/logical/limit.py#L61
Which is used by the DaskLimitPlugin to handle offsets and limits on select statements.

Thanks for triaging. So there's a couple of things I'd like to discuss.

Explore if not persisting is an option.
Irrespective of the persist, do we need to read in the full data or can we read in a subset similar to doing ddf.head()

do we need to read in the full data or can we read in a subset similar to doing ddf.head()

It looks like this is what's being done immediate after the persist; we check if the requested data is located in the first partition, and if so, simply use df.head():
https://github.com/dask-contrib/dask-sql/blob/b571a600a639f0dcabd9d0162d01d078472e3e51/dask_sql/physical/rel/logical/limit.py#L62-L66
Failing this, we end up computing the length of each partition, which IIUC ends up persisting the dataframe anyways?
https://github.com/dask-contrib/dask-sql/blob/b571a600a639f0dcabd9d0162d01d078472e3e51/dask_sql/physical/rel/logical/limit.py#L69-L71
If that's the case, then I see nothing wrong with removing this persist call, as all it really does is ensure that we persist the dataframe even when we don't need to - although perhaps the idea here was similar to the persist calls in sort where we want to compute potentially complex operations before computing the subset of data we want?

Relevant PR attempting to add ioc to dask dataframes https://github.com/dask/dask/pull/6661

Relevant PR attempting to add ioc to dask dataframes dask/dask#6661

Nice! Once this lands do you think we can leverage some of this logic within our limit plugin?

Yeah, I think even some smaller changes being discussed there (such as the addition of a pre-computed partition_sizes attribute) could be used to reduce the amount of cases where we would be forced to partially / fully persist a frame

Thanks for that context. I think we should be good to close this issue but should raise another issue in dask-sql to explore operations where we could leverage iloc and/or just precomputing partition_sizes instead of persisting once that PR lands.


Convert the spec to AsciiDoc format

Converted using pandoc:
pandoc -s OldSpec.md -t asciidoctor -o README.adoc

Minor manual cleanup of document header and warning note

@marvgmail @CraigSellars @achamely @dexX7
You can see the differences introduced by the format conversion here: https://github.com/OmniLayer/spec/pull/335/commits/4ba532548b1ae9b34b3e10fe2148d0a85a12b344

@achamely @CraigSellars @marvgmail @dexX7 This is ready for approval and merging.

it looks ok to me.

Ok for me

Approved.


fix: add conditions for when to ignore additionalProperties and additionalItems

Description
This PR fixes the two options always ignoring additionalProperties and additionalItems when it should be conditional on two things:

Should only apply on when defaulting, not when explicitly defined.
ignoreAdditionalProperties should only apply when the schema has properties, otherwise its normally later interpreted as a map type which is intended.
ignoreAdditionalProperties should only apply when the schema has explicit types defined, otherwise its the same as setting types explicitly.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

10 of 10 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.07%) to 92.409%

Totals

Change from base Build<PHONE_NUMBER>:
0.07%

Covered Lines:
4734

Relevant Lines:
4993

💛  - Coveralls

I can accept PR, but if properties/items aren't defined it not means that given object cannot have it, e.g. schemas like:
type: object

or
type: array

means that every property/item can be defined, so I think that ignoreAdditionalItems and ignoreAdditionalProperties should have higher priority than logic in PR.

If you dont explicitly define properties and items, it defaults to additionalProperties and additionalItemswhich allow everything. This is why you cannot ignore the keywords in that scenario, cause then the type defined in those is thebest possible type` you have access to.


createDirs doesn't seem to be working when run from debug mode in VS 2010

Not sure if this an issue with nLog or Visual Studio, but with most recent build of version 2 from 7/13/2010 it seems that createDirs is not actually creating the directory when I run in debug mode.

Error:
 at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
 at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
 at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
 at NLog.Internal.FileAppenders.BaseFileAppender.TryCreateFileStream(Boolean allowConcurrentWrite) in c:\NLogBuild\src\NLog\Internal\FileAppenders\BaseFileAppender.cs:line 234

snippet from config
<target name="file" createDirs="true" xsi:type="File" maxArchiveFiles="100"
 archiveFileName="${basedir}/logs/archive/application_{#####}.log"
 archiveEvery="Hour" fileName="${basedir}/logs/application.log"

What's interesting is that my WPF app can create the folders either way when I do a Directory.CreateDirectory, so why does nlog not have permission? Weird.
Comments:
xfighter wrote Jun 24 2011 at 2:41 AM
I have the same issue and adding the nlog source file it errors on the line 225 of the basefileappender.cs for me which is inside the "WindowsCreateFile" method:
var safeHandle = new Microsoft.Win32.SafeHandles.SafeFileHandle(handle, true);

This seems a permissions issue. Closing this on.

This can be a first chance exception — an exception that is thrown, but caught by NLog later and handled. If the directory is created eventually, than it works as designed.


test: fix android build error.

Do not compile 'tty_pty' test for android.

LGTM

Code changes LGTM, but is the change in file permissions necessary?

@cjihrig good catch! it's certainly not necessary.

Thank you for review. I remove unnecessary file permissions.

Android isn't tested, but CI to make sure it doesn't break anything else: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/89/

Landed in 791c817891fdfde806a3814e1eeed94502eb56b8. Thanks!


Use OpenSlides specific styles for HtmlToPdfServices

Closes #2118
Created pdfMake styles that as best as possible approach the OpenSlides header styles

Can #2271 be integrated into this PR?

Certainly it could, but I would prefer to keep this PR limited to the topic of fixing/changing pdf styling.

@Eich-hoernchen @MSoeb This may change the styles in pretty much all pdf exports, please check if this outcome is desirable from a design perspective

for example pdfs, see https://testintern.staging.openslides.com/150/mediafiles/228

waiting for #2728

the issue from this PR should be fixed after the other issues from the display are implemented
When that happened a new more up-to-date PR should be created


[decomp] Creation of s6-n from no where, results in un-compilable code

A bit hard to describe, but there are very few functions where s6 gets assigned to another variable for some reason -- despite there being no set! that i can find.
I'll use (code robber-debug) in rolling-robber, label L76 as an example.
    c.lt.s f0, f1             ;; [ 69] (b! (>=.s f0-11 f1-0) L82 (set! v1-24 #f)) [] -> [v1: '#f ]
    bc1f L82
    or v1, s7, r0

B8:
    lwc1 f0, L183(fp)         ;; [ 70] (set! f0-12 (l.f L183)) [] -> []
    lwc1 f1, 172(s6)          ;; [ 71] (set! f1-1 (l.f (+ self 172))) [s6: robber ] -> []
    add.s f0, f0, f1          ;; [ 72] (set! f0-13 (+.s f0-12 f1-1)) [] -> []
    swc1 f0, 172(s6)          ;; [ 73] (s.f! (+ self 172) f0-13) [s6: robber ] -> []
    mfc1 v1, f0               ;; [ 74] (set! v1-25 (fpr->gpr f0-13)) [] -> [v1: float ]
    beq r0, r0, L83           ;; [ 75] (b! #t L83 (nop!)) [] -> []
    sll r0, r0, 0

B9:
L82:
    lwc1 f0, 172(s6)          ;; [ 76] (set! f0-14 (l.f (+ self 172))) [s6: robber ] -> []
    mtc1 f1, r0               ;; [ 77] (set! f1-2 0) [] -> []
    c.lt.s f0, f1             ;; [ 78] (b! (>=.s f0-14 f1-2) L83 (set! v1-26 #f)) [] -> [v1: '#f ]
    bc1f L83
    or v1, s7, r0

B10:
    lwc1 f0, L187(fp)         ;; [ 79] (set! f0-15 (l.f L187)) [] -> []
    lwc1 f1, 172(s6)          ;; [ 80] (set! f1-3 (l.f (+ s6-1 172))) [s6: robber ] -> []
    add.s f0, f0, f1          ;; [ 81] (set! f0-16 (+.s f0-15 f1-3)) [] -> []
    swc1 f0, 172(s6)          ;; [ 82] (s.f! (+ s6-1 172) f0-16) [s6: robber ] -> []
    mfc1 v1, f0               ;; [ 83] (set! v1-27 (fpr->gpr f0-16)) [] -> [v1: float ]

In B10 it uses s6-1, which results in the following expressions:
((< (-> self curve-position) 0.0)
                                         (set!
                                          (-> s6-1 curve-position)
                                          (+ 1.0 (-> s6-1 curve-position))
                                          )
                                         )
                                        )

Which does not have the proper self syntax, and fails to compile.
This also effects the following files:

training-obs
villagep-obs
lavatube-obs
for an up to date list search #"DI: S6-1 Issue" on https://app.gitkraken.com/glo/board/YJx-xCFNpQARwri4

Atleast fixed enough to no longer be a blocker in the above mentioned PR


[1.20.1] [Forge] Non-op players get stuck on carpets

This issue has 2 different problems, but the solution might fix both of them.
Playing multiplayer on a dedicated server using Forge 47.0.35 and Bongo 1.20.1-4.0.1 + BingoLobby 1.20.1-4.0.1
After completing a game and returning from the overworld:

Non-op players get stuck on colored carpets and the message that "you can't join a team when there is no game started" gets spammed in their chat. They are unable to move. Op players just get sent to the middle of the lobby when they step over the carpets.

After creating a new game, the non-op, non-vip players get stuck when stepping on the yellow carpet (vip team) and their chat is spammed that they are not vip and cannot join the vip team. Again, they cannot move. They just freeze in place. Op players just get teleported to the middle as usual.

I am going to close this now due to lack of response. If the issue still persist, please feel free to open a new one and provide the requested information.


Release our lock when we encounter a canceled task

This early-out condition would exit while still holding our lock, resulting in
Very Bad Things (tm) down the line.

:thumbsup:


Change message title conflicts with "Show More / Show Less"

From the demo where the message is long and has the 'Show More' link
click the link to show more
Change the message title from the input
click the 'show less' then 'show more' again, the title reverts back to its original value

@appagg I tweaked your message a little. The words "Show More" are not getting appended, they're already present in that "message title" input box (you may have to scroll right to see them). But you are correct that the show less / show more links are causing it to revert back to the original value for message-title. We'll have to look into whether this is an actual bug, or just a weird artifact of the way the demo page does binding between the inputs and the alert-message demo.

Fixed in v0.9.2.


Flaky panic in concurrent AppendToStream error handling

I have seen this panic a couple of times in our integration tests:
{"level":"error","msg":"subscription has dropped. Reason: [rpc error: code = Unavailable desc = error reading from server: EOF]"}
panic: send on closed channel

goroutine 6833 [running]:
github.com/EventStore/EventStore-Client-Go/v4/esdb.(*grpcClient).handleError(0xc0007bc120, 0xc0003a1830, 0xec7f80?, 0xc000649b90, {0x101a620, 0xc00006ecf8})
	/home/runner/go/pkg/mod/github.com/!event!store/!event!store-!client-!go/v4@v4.1.0/esdb/impl.go:78 +0x5f8
github.com/EventStore/EventStore-Client-Go/v4/esdb.(*Client).AppendToStream(0xc000891e70, {0x1024240, 0x1691160}, {0xc000136f80, 0x69}, {{0x1018180, 0x1691160}, 0x0, 0x0, 0x0}, ...)
	/home/runner/go/pkg/mod/github.com/!event!store/!event!store-!client-!go/v4@v4.1.0/esdb/client.go:87 +0xbae
project-othermodule/eventstore.ESDBCoreService.AppendToStream(...)
	/home/runner/work/someproject/someproject/backend/go-common/eventstore/core.request.go:331
project-othermodule/eventstore/service.ESDBDataService.updateDataProgress.func1()
	/home/runner/work/someproject/someproject/backend/go-common/eventstore/service/service.progress.go:170 +0x4d7
created by project-othermodule/eventstore/service.ESDBDataService.updateDataProgress in goroutine 6793
	/home/runner/work/someproject/someproject/backend/go-common/eventstore/service/service.progress.go:147 +0x234
FAIL eventstore/service.TestFlakyGraphqlReads (-1.00s)
=== RUN   TestFlakyGraphqlReads/DoesNotGetErrorStreamNotFound

The line that panics from impl.go in handleError():

Just before the panic we have a failing AppendToStream, that returns an error, that i'm afraid i have not logged. I suspect there is a problem with intermittent network errors in the github runners, because we get quite a few random flaky tests at the moment (we're running integration tests against eventstore via testcontainers-go).
Any way i'm not completely sure on the order of calls, but the net result is that func (client *grpcClient) close() {} must have been called before func (client *grpcClient) handleError() which causes the panic above.
Some details about the test i'm running:

I'm testing a complex service doing both reads, appends and subscribes
I'm using multiple esdb clients from 5 different go routines (due to https://discuss.eventstore.com/t/grpc-connection-pool-for-subscriptions/5210)
I'm not explicitly closing any of those clients
I might cancel contexts to the different esdb operations

I see there has already been some mitigation of concurrency errors with the closeFlag in the type grpcClient struct. I don't think it's sufficient though. If AppendToStream are to be thread safe i don't really see any way around a regular sync.Mutex being locked on all writes to the channel of the grpcClient struct as well as on closure.
Let me know if you need any more details, thanks in advance

@wiegell Thanks for reporting this. I'll reassess how that part of the code works and see if we missed something.

@wiegell I identified some code paths that might lead to the panic you encountered. Could you test the patch above and let me know if it improves the situation?

Yes i have been a little hung up at work lately, but will do it shortly! Thank you for looking into this.

I'm sorry that i didn't get back to you. The thing is, that i cannot reproduce this locally, since i would need to introduce a flaky network connection (maybe via toxiproxy) and then reconstruct the test to only fail in case of the panic above and then run that many, many times...
We don't see this problem in production (but we don't have much traffic yet) and only very rarely in the integration tests, so i cannot really justify spending much time on constructing a test like that to our customer.
But if we ever see it after applying your patch i will let you know!
Once again thank you for looking into this.


Fixes readme typo (node-modules)

Fixes simple typo on the README.md file.

Thank you @FrankKair ! An article that coincides with this demo will be live on https://elastic.co/blog this Thursday, if you are interested. Enjoy your week.


Accept IO objects as HTTP request bodies

Previously only strings (or nil) would have been accepted by the HTTP::Client.exec methods.

Tests pass now.

This is a good change, we forgot about request's body being able to be an IO.
We should also think if we want to have an IO in the server, so I guess this will need some more thought from our side.

This was implemented in #3406


fix(component): updates to build to compile and babel translate the p…

…lugin code
Additon of Makefile and updates to build process to typescript compile and babel translate the
plugin code
fix for open-cluster-management/backlog/issues/12072

:tada: This PR is included in version 3.0.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Warning: As of<EMAIL_ADDRESS>the getNodesAtRange method has been renamed to getDescendantsAtRange.

I'm getting the following warning when using the lists plugin:
As of<EMAIL_ADDRESS>the `getNodesAtRange` method has been renamed to `getDescendantsAtRange`.

I looked at fixing it but it seems doing so would be a breaking change for this library since it would change the Slate version, but I'm unsure.

Thanks for filing the issue! We have a PR open for this, but I'm going to hold off addressing it until the function is removed.
https://github.com/ConvertKit/slate-plugins/pull/37

Thanks for taking a look @brendancarney. One issue with not addressing this now is that when Slate upgrades and removes it, it will break anyone who upgrades Slate before there is a fix here and this is upgraded. If not addressing this now, would you be open to at least setting a peerDependency for Slate for this package so people know which versions are supported?


Build ODB API module

keyword_APS3_Executable_WG   |    by<EMAIL_ADDRESS>
To build OPS32.0.0 executable, it is required to have access to a pre-build odbapi module.
The required source code is at
https://access-svn.nci.org.au/svn/odb/trunk/odb_api/OdbAPI-0.10.3-Source
Currently our APS3 build environment is defined as below:
module load intel-cc/<IP_ADDRESS>
module load intel-fc/<IP_ADDRESS>
module load intel-mpi/<IP_ADDRESS>
This environment may change in the future.
Tan is the most suitable person to do this task. The estimate time for Tan is 1 day.

Issue migrated from trac:212 at 2024-01-31 18:15:24 +1100

<EMAIL_ADDRESS>commented

odb api version 0.10.3 has been compiled and installed on raijin, and is available for linking with ops32 for testing of ODBcreate.
module load odbapi/0.10.3
the following env settings and options are use in the building of odbapi/0.10.3
module use ~access/modules
module unload netcdf intel-cc intel-fc intel-mpi
module del openmpi
module load cmake
#module load netcdf/4.1.3
module load netcdf/3.6.3
module load intel-cc/<IP_ADDRESS>
module load intel-fc/<IP_ADDRESS>
module load intel-mpi/<IP_ADDRESS>
module unload python/2.7.6-matplotlib
module load odb/1.0.0
cmake ../..


IR-497: Add a utility to check NOMIS report config validity

This can be used as part of the import process of NOMIS configuration into our code base.
The key thing is to ensure that all routes through a report’s set of questions are valid: there are no loops.
Once we start making our own config for future report types, we can convert this to check our config instead of NOMIS’.

FYI: @ushkarev I've been working on doing validation on the DPS config and I'm cooking a PR which should be ready for review soon: https://github.com/ministryofjustice/hmpps-incident-reporting/pull/184
I think some of the logic in there could be reused (I've made the data structure generic for this reason). I'm happy to 1) show you what I've done and 2) chat when you're back as I have ideas :)

this PR was the predecessor for DPS config validation and that exists now. there's probably nothing here to keep


Add delayPeriod for tendermint client

Description

closes: #7133

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against the correct branch (see CONTRIBUTING.md).
[ ] Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/).
[ ] Added relevant godoc comments.
[ ] Provide a conventional commit message to follow the repository standards.
[ ] Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
[ ] Re-reviewed Files changed in the GitHub PR explorer.
[ ] Review SonarCloud Report in the comment section below once CI passes.

closing as per comment https://github.com/cosmos/ibc-go/issues/7133#issuecomment-2470297111


Unity crashes when breaking ros bridge communication

My OS is: Windows 10 (and Ubuntu 16.04)
My Unity Version is: 2018.3.0f2
My ROS Distribution is: Kinetic
My Build Target Platform is: Windows

Here is my bug description:
When playing the unit simulation example, if rosbridge communication is broken, after a while Unity crashes by a message "Fatal Error in GC. Unexpected mark stack overflow".
Perform the following steps reproduce the bug:

Launch unity_simulation_scene in ROS.
Start simulation in Unity.
Kill ROS (Ctrl+C in the terminal).
Wait for the window with the message to appear.

Observed results:
Unity crashes.

It's a bother for me to check if the ROS server exists every time.
I want ROS# to check if the server exists before connection...

We improved WebSocketNetProtocol in the meantime
and can no longer reproduce the error.
@nlamprian Please let me know if this issue persists on your side with the latest ROS# version.


predict-fingerprints takes so much time, it is normal?

Hi everyone
I just installed q2-qemistree. I am trying to run it using the demo data. I successfully generate the i) fragmentation trees and ii) molecular formulas. However, when I try to predict the fingerprints, it takes so much time running and never ends. For example, I left it running overnight. is this normal?
Thank you so much for your help,
Cheers,
Eber

Hi Eber,
Since the end of December, Sirius 4 has reached its end of life. Therefore, currently, Qemistree is not working.
We are now working on another update for Qemistree to connect with Sirius 5. We will let you know when we complete the update.
All the best,
Helena

Thank you so much for your answer Helena.
Is there any other way to use Qemistree?. I saw that you mentioned Proteomics2 platform in other of questions, but I tried to use it and it didn't work.
Thanks in advance,
Cheers,
Eber

Thanks Helena!


Support MinGW as a wasmtime target

It looks like Go at least only supports MinGW as a toolchain to link with, but wasmtiem does not currently have MinGW support. If we'd like to support Windows support for Wasmtime in Go I think we'll need to add a MinGW target as well as CI/releases for it.

Do you know how complicated that would be initially—and how much of a maintenance burden it'd be on an ongoing basis? If neither is a concern, this makes sense to me. Otherwise, I think we should let the be driven by use cases.

Ah, I now see the wasmtime-go issue. I guess the question is how many people will want to run Go programs on Windows, which I don't have a good handle on.

Oh sorry I should have clarified, but I definitely agree that we should let use cases and difficulty of implementation guide this in terms of priorities. I don't think it's clear how motivated this is right now (I don't know how often it'd be wanted on Go for Windows). I suspect this would be relatively difficult because of stack unwinding, but I might give this a go later today and see if it "trivially works" or "trivially doesn't work". Basically I think it's probably worth a little bit of effort to see how much effort it would take for us to support this.

That makes a lot of sense to me, yes. Thank you for the clarification!

Turns out that with https://github.com/bytecodealliance/wasmtime/pull/1490 all tests pass. I think there's probably some difference in how big the stack is when a segfault comes in which causes issues today, but once https://github.com/bytecodealliance/wasmtime/pull/1490 lands I can look into adding this to CI. Don't think it'll be too too hard!


Support showing status bar, and in the problems section

doesn't do actual error line stuff yet, but let's not make perfect the enemy of done


Feature/current time cursor

A feature that marks the current time in the day view and the week view display.
This, in order to help the user orientate in his schedule and get a better experience:)

Codecov Report

Merging #288 (386cd22) into develop (9724685) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##           develop     #288    +/-   ##
=========================================
  Coverage    99.04%   99.05%
=========================================
  Files           50       52     +2
  Lines         2310     2428   +118
=========================================
+ Hits          2288     2405   +117
- Misses          22       23     +1

Impacted Files
Coverage Δ

app/routers/dayview.py
100.00% <100.00%> (ø)

app/routers/weekview.py
100.00% <100.00%> (ø)

app/database/models.py
96.29% <0.00%> (-0.33%)
:arrow_down:

app/main.py
96.66% <0.00%> (ø)

app/internal/utils.py
100.00% <0.00%> (ø)

app/routers/export.py
100.00% <0.00%> (ø)

app/internal/agenda_events.py
100.00% <0.00%> (ø)

app/internal/export.py
100.00% <0.00%> (ø)

app/internal/comment.py
100.00% <0.00%> (ø)

app/routers/event.py
97.68% <0.00%> (+0.37%)
:arrow_up:

Continue to review full report at Codecov.

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

Please fix conflicts :)


nixos/sshd: don't validate mock host key, permit RequiredRSASize

Description of changes
Currently one cannot set the option services.openssh.settings.RequiredRSASize to anything higher than 3072.  This is due to the validation step in https://github.com/NixOS/nixpkgs/blob/9999996fd6f33c12f2f341dcdbac7a9c926d0a87/nixos/modules/services/networking/ssh/sshd.nix#L31 which generates a fake rsa host key with 3072 bits length: If the host key does not satisfy the RequiredRSASize, the validation step fails.
With OpenSSH 9.3 sshd learned the -G option that "allows usage of the option before keys have been generated and for configuration evaluation and verification by unprivileged users", which is what we need to avoid testing a mock host key.  A quick check (adding an "abc abc" line to sshd_config) shows that configuration errors are also caught by this method.
Alternatively, one could add a -b option to increase the key length for the mock host key, but even then we would have to choose an arbitrary size and thereby an arbitrary limit of RequiredRSASize.  Also, higher key lengths require a considerable amount of CPU time to be generated.
Notifying author of validation mechanism: @Ma27
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] 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

[x] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.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.

Result of nixpkgs-review run on x86_64-linux 1

1 package blacklisted:

nixos-install-tools

This apparently breaks Match rules:
      Match Group rsync LocalPort 10022
        ForceCommand ${pkgs.rrsync}/bin/rrsync /chroot

This at least fails with
'Match LocalPort' in configuration but 'lport' not in connection test specification.

In total, I need sshd -G -T -C lport=22 -f $out (or lport=10022) to make sshd happy here. (Originally replied to the Commit, will delete the messages now).


Color Profiles

This PR adds support for detecting color profiles within a PDF file. This allows us to implement rules that allow the blacklisting of specific color profiles.
Preflight::Rules::ImageColorspace.new(:DeviceRGB, blacklist: ['ProPhoto RGB'])

Love it!!


[New Abbreviations]

What would you like to share?
I was talking to one of my friend and I got something to add!

idts - I Don't think So
idli -  I Don't Like It
ili - I Like it

Additional information
No response

Go ahead @rupali-codes :heart: Assigning you!

Hey there @rupali-codes will you be submitting another pull request for this?

oh, yeah, sure Emy!


ZLibDecoder/ZLibEncoder: corruped data

ZLibEncoder is intended to compress data.
ZLibDecoder is intended to decompress compressed data.
The following example demonstrates the problem:
import "dart:io";

main() {
  List<int> data1 = new List.generate(260, (int i) => i); // anything greater than 256 is ok
  List<int> data2 = new ZLibDecoder().convert(new ZLibEncoder().convert(data1));
  if (data1.length!=data2.length){
    print("data1.length: ${data1.length} data2.length: ${data2.length}");
  }
  for (int i=0; i<data1.length; i++){
    if (data1[i]!=data2[i]){
      print("mismatch at index $i: source: ${data1[i]} decoded: ${data2[i]}");
    }
  }
}

Output:

mismatch at index 256: source: 256 decoded: 0
mismatch at index 257: source: 257 decoded: 1
mismatch at index 258: source: 258 decoded: 2
mismatch at index 259: source: 259 decoded: 3

Dart VM version: 1.24.2 (Thu Jun 22 08:55:56 2017) on "windows_x64"

Input integers must be bytes (0..255). We need to document what happens if they are not.


Dio force header to lowercase

Issue Info

Info
Value

Platform Name
flutter

Platform Version

Dio Version
3.0.10

Android Studio / Xcode Version
Android Studio 4.1.2

Repro rate
all the time (100%)

Repro with our demo prj

Demo project link

Dart SDK
2.12.0

Issue Description and Steps
When I set Dio header like this
dio.options.headers['Authorization'] = 'dGVzdDp0ZXN0';

I expect request header to look like this
Authorization: Basic dGVzdDp0ZXN0

Not like this (notice that capital "A" was transformed to "a")
authorization: Basic dGVzdDp0ZXN0

I found problem in io_adpater.dart

I think this is related to this

I also having this issue, this is mainly due to our flutter app is connecting to a service that is using AWS API Gateway and for the service, header field name is case-sensitive.

Header names and query parameters are processed in a case-sensitive way.
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html


suggestion to add a reforge station

maybe you could add a reforge station similar to the "Quality tools" or in case a function with the blacksmithing table like the "modifiers" mod

Thank you,


better README.md templating

insert project name into md
show generator version
remove unnecessary info?

related:  #157


fix: updated package.json for windows users

craco start/craco build script were were causing JavaScrip heap overloads. Added --max_old_space_size=4096 to both scripts to allocate more memory.
Fix was found here:
https://stackoverflow.com/questions/55613789/how-to-fix-fatal-error-ineffective-mark-compacts-near-heap-limit-allocation-fa

LGTM, would recommend you include documentation either on Trello or a closed issue on the tracker in case the 4gb min/max would affect client needs as the client grows.

I'm merging this so windows users can pull this down to get their local deployment working since the rest of the team only has read access.


Add file information to save in database

I look we must add photo_dir field to save directory address, can add optional feature to save in database like :

photo_size
photo_type

To save original image size and image type

Currently the plugin doesn't support changing these elements, which means the you will be able to query the file on the filesystem to find out these details.
$pathToFile = '/example/file.jpg';
list($width, $height, $type, $attr) = getimagesize($pathToFile);

http://php.net/manual/en/function.getimagesize.php

For my case that collected a total of amount of size that is uploaded, I think it would benefit, so from that information could know the total picture that they upload. But it does not matter if you think it will not be profitable. Is there a manual option when uploaded image to include information about the size to the database?

You could probably hook into the event in the plugin to store extra data in the entity before it is persisted.


Practical links when using webviews

Maybe add http://stackoverflow.com/questions/26005641/are-cookies-in-uiwebview-accepted to the readme ? As it saved me I think others might be interested. Please close if irrelevant.

@Elyx0 thank you for this link, however, the purpose of this library is to simply create a bridge between react-native and webview.
One way of solving this issue is using JWT token and pass the it to webview with this library.


Add "multibuild" subcommand to Forge

Motivation
Many Solidity libraries accept a wide range of Solidity versions by using the ^ and >= comparison operators in their version pragma, e.g. this is what forge-std currently uses:
pragma solidity >=0.6.0 <0.9.0

But, with time, it becomes difficult to continuously check that the library code remains compatible with all compiler versions allowed by the version pragma. For instance, when new maintainers come in and propose a new feature, they might not realize that their change broke compatibility with an older version of Solidity. Or there might be cases when the library is not compatible with one specific version of Solidity, due to a bug in that version.
Here's a list of issues that occurred due to a lack of an easy way to build a library with multiple Solidity versions:

https://github.com/foundry-rs/forge-std/pull/56
https://github.com/foundry-rs/forge-std/issues/117
https://github.com/paulrberg/prb-test/issues/5

Solution
Add a multibuild subcommand to the Forge CLI that can be used like this:
forge multibuild [OPTIONS] --from <SOLC_VERSION> --to <SOLC_VERSION>

This will compile the project's smart contracts with all Solidity versions starting with from and ending with to. This would be very useful to Solidity library developers, especially as a check performed in CI.
Notes

To make this work, I had to disable the --use and --no-auto-detect build flags, which I did by refactoring them out of cli/src/cmd/forge/build/core.rs to a new struct SolcArgs in cli/src/cmd/forge/build/solc.rs. I added the new struct SolcArgs in all subcommands where CoreBuildArgs is used, so that this PR doesn't introduce any breaking changes.
I have written tests - though naturally due to the nature of this feature, tests take some time to run because of the many Solidity versions that need to be installed. Happy to lower the interval of Solidity versions tested if you think that that would be worth it (currently it tests from 0.7.0 to 0.8.15).

Alternative Implementations
The approach I have chosen to implement this was to add a  project method in the new MultibuildArgs struct, which can create an instance of Project with a specific solc.
But this is the first time that I fiddled with the Foundry code base, so I'm not sure that this approach can be considered good. I'm very open to refactoring the PR if you can guide me in the right direction.
For example, I was thinking to add a project_with_solc method in BuildArgs, since that would make the method callable from multiple places (maybe other subcommands will in the future need to create an instance of Project with a specific solc).

This is great! Will defer to @onbjerg and @mattsse on implementation, just wanted to add some comments around UX suggestions:
In https://github.com/foundry-rs/foundry/issues/1131, I pictured this being a subcommand of build and test, that way you can also run your test suite over the full range. Example usage:

CLI: forge build --sweep "<comma separated array of versions>" and forge build --sweep <minVersion> <maxVersion> and forge build --sweep
Config file: solc-sweep-versions = [ "0.7.6", "0.8.15" ] and solc-sweep-versions = { min = "0.7.6", max = "0.8.15 } or solc-sweep-versions = true

In both of the above examples:

build could be replaced with test (i.e. both should work)
The first version lets you run specific versions, the second lets you select a range, and the third auto-detects the range.

Totally open to UX feedback/pushback and sticking with the current approach if people like it better, and of course can stick to just support build in this PR and adding test support separately.
Also just wanted to call out https://github.com/foundry-rs/foundry/issues/391 which is related

Is this not the same as https://github.com/foundry-rs/foundry/issues/1131? The --sweep on forge test proposed in there would really mostly affect the build process, only minimal changes would be needed for the testing process itself.

Is this not the same as https://github.com/foundry-rs/foundry/issues/1131? The --sweep on forge test proposed in there would really mostly affect the build process, only minimal changes would be needed for the testing process itself.
Also re: UX, I think we should use a flag for this, not a new command. --sweep could just (optionally) take a version range

It would be much more ergonomic to have it as a command rather than a flag, I am imagining using this in a container and just inheriting the compiler artifact and having that mapped to forge so that the entrypoint has it hooked in. Either way still works, just leaves the possibility of using this stdin as well

Also, how will forge handle options that are not consistent across major versions? I guess having a profile would be warranted no?

Is this not the same as https://github.com/foundry-rs/foundry/issues/1131? The --sweep on forge test proposed in there would really mostly affect the build process, only minimal changes would be needed for the testing process itself.
Also re: UX, I think we should use a flag for this, not a new command. --sweep could just (optionally) take a version range

Yea my understanding is this is basically #1131 with different UX, though I agree a --sweep flag would be preferable to a new command.

how will forge handle options that are not consistent across major versions? I guess having a profile would be warranted no?

I've been thinking about this and so far where I'm at is:

For the first version of this PR, it's ok if sweep either uses solc defaults for that version, or lets you specify optimizer on/off + number of runs, and that config applies to all versions in the sweep (I think the optimizer flags have been the same for the last few major solc versions).
Eventually I think "solc profiles" is the way to go, e.g. you can setup [solc.default] and [solc.optimizer], then in a [profile.default] or [profile.ci] you have a key that maps file names / contract names to which solc profile to use. This is similar to an idea discussed for supporting more granular fuzz profiles in https://github.com/foundry-rs/foundry/issues/744 so I think the same pattern can be used in both, though this probably needs some more spec'ing out

Is this not the same as #1131?

Welp, I haven't seen that 😅
I agree that a --sweep flag would be better than a new subcommand, especially if the flag would be applied to both the build and the test subcommands.
But the --use and --no-auto-detect flags would still have to be disabled when running --sweep, so we may have to use clap's conflicts_with macro to disable them. That, or we keep the new struct I introduced in this PR, SolcArgs.
At any rate - happy to close this PR.

I don't think we necessarily need to close it, perhaps just refactor to put the logic as a flag instead of a separate command? I agree the --use and --no-auto-detect flags should be disabled (or just ignored if that's simpler) in favor of the versions specified/detected by --sweep

perhaps just refactor to put the logic as a flag instead of a separate command?

Sounds good, though I might not be able to do this refactor in the near future.
Re sweep naming - been thinking about it and there's something I don't like about it. I feel like sweep doesn't accurately capture the meaning of this functionality.
Though I also don't have a good alternative in mind.

Yeah, no need to close, even if you don't have bandwidth to address the reviews/feedback - in that case, just mark this as a draft (convert to draft in the right side) so we know :) Someone might pick it up when bandwidth is available. It's ok to disable flags using conflicts_with as well. As for the naming of --sweep, I don't have strong feelings, but I 100% think this should be a flag in some capacity

Closing due to conflicts + in an attempt to clean up the issue tracker. We can re-open if we reconsider.


Block image push when Clair severity is High

Is possible block push of images when severity on clair is High and the issue has "fixed version"
I have found this environment variables on ui:
PROJECT_CONTENT_TRUST=1
PROJECT_VULNERABLE=1
PROJECT_SEVERITY=high
What this variables does?

Hi
Do you mean block image "pull" or "push"?
It can't be scanned before it's pushed.
But if you mean pull, we added some code but it's now controlled by env variable of the "ui" container.

Push. But is possible block pull of "unsecure" images?
In my case, I want block push images with high security issue with corrections. I want prevent new images with critical issues.

Blocking on pull seems like the right approach here, that however would require Harbour to not make an image available to pull until it has been scanned and meets the criteria; effectively quarantines the image.

Block pull is not good on Auto scaling environments.
Imagine the scenario:
The user has been pushed a OK image, after a time, this image comes insecure, I'll block the scaling of application...
On pull I think it needs to be handled in a diferent layer...

That's exactly how it could work and it would break the application; that can be part of a policy. For example, it is detected as having high CVEs, the user has X days to update and beyond that time it is blocked, a critical one could be a full block.
Having an option where you can pull the API for "bad" images based on policy without blocking anything could help feed into other tools (ASGs, other security tools, etc)
A push (while I would also like that) would only block the problem at this point in time, not help protect against images that are basically bit-rotting.
All of that depends on each person taste and security teams perspective. That's why it can be a configurable policy, I would think.

@helgi Let's make this pull request together? Did you have time for this?

@vasartori I do not, sorry. Not actively using Harbour. Evaluating it still.

@helgi no problem :)


Show filter dialog is too wide

Almost as wide as screen in portrait.
Lot's of empty space left to right in landscape and portrait.

Looks fine on 5.1 phone.


[Quant] Add FX support in quantization examples

Stack from ghstack (oldest at bottom):

-> #5797

Summary: Previously, the quantization examples use only eager
mode quantization. This commit adds support for FX mode
quantization as well.
Test Plan:
# ==================== PTQ ====================
# MODEL is one of googlenet, inception_v3, resnet18, resnet50, resnext101_32x8d,
# shufflenet_v2_x0_5, shufflenet_v2_x1_0

# eager
python train_quantization.py --device="cpu" --post-training-quantize --backend="fbgemm"\
  --model="$MODEL" --weights="IMAGENET1K_V1" --quantization-workflow-type="eager_mode_quantization"

# fx
python train_quantization.py --device="cpu" --post-training-quantize --backend="fbgemm"\
  --model="$MODEL" --weights="IMAGENET1K_V1" --quantization-workflow-type="eager_mode_quantization"

# ==================== QAT ====================
# mobilenet_v2 eager
python train_quantization.py --device="cuda" --backend="qnnpack" --model="mobilenet_v2"\
  --epochs=10 --workers=64 --weights="IMAGENET1K_V1" --lr=0.0001 --weight-decay=0.0001\
  --quantization-workflow-type="eager_mode_quantization"

# mobilenet_v2 fx
python train_quantization.py --device="cuda" --backend="qnnpack" --model="mobilenet_v2"\
  --epochs=10 --workers=64 --weights="IMAGENET1K_V1" --lr=0.0001 --weight-decay=0.0001\
  --quantization-workflow-type="fx_graph_mode_quantization"

# mobilenet_v3_large eager
python train_quantization.py --device="cuda" --backend="qnnpack" --model="mobilenet_v3_large"\
  --epochs=10 --workers=64 --weights="IMAGENET1K_V1" --lr=0.001 --weight-decay=0.00001\
  --quantization-workflow-type="eager_mode_quantization"

# mobilenet_v3_large fx
python train_quantization.py --device="cuda" --backend="qnnpack" --model="mobilenet_v3_large"\
  --epochs=10 --workers=64 --weights="IMAGENET1K_V1" --lr=0.001 --weight-decay=0.00001\
  --quantization-workflow-type="fx_graph_mode_quantization"

Reviewers: jerryzh168, vkuzo
Subscribers: jerryzh168, vkuzo

I updated the description with numbers from mobilenet_v2 and mobilenet_v3_large. The results are good: the eager mode accuracies match FX accuracies across all models. This is ready from my side. Any other comments @vkuzo @datumbox?

There was a problem with the way I set up the FX experiments. After fixing this problem I uncovered a new blocking issue that I summarized here https://github.com/pytorch/pytorch/issues/75825. I will rerun all the experiments after we fix that issue.

Hi @datumbox, as of the latest set of changes, both FX and eager code paths go through the "custom model builders" (e.g. torchvision.models.quantization.googlenet). Note that FX still uses the original unmodified model (e.g. GoogLeNet), while eager mode still uses the version with manually inserted quant and dequant stubs (e.g. QuantizableGoogLeNet) as before.
The main reason why I decided to route both FX and eager mode through the "custom model builder" was to handle the test_only use case. For some context, train_quantization.py has three different modes: PTQ, QAT, and test_only. The way PTQ and QAT differ from test_only mode is as follows:
# PTQ / QAT eager
weights = get_pretrained_fp32_weights()
model = torchvision.models.quantization.QuantizableResNet50(...)
model.load_state_dict(weights.get_state_dict())
model = prepare(model) # or prepare_qat
calibrate(model, data) # or train
model = convert(model)
evaluate(model)

# test_only eager
weights = get_quantized_weights()
model = torchvision.models.quantization.QuantizableResNet50(...)
model = prepare(model)
calibrate(model, dummy_data)
model = convert(model)
model.load_state_dict(weights.get_state_dict())
evaluate(model)

For test_only, the weights are quantized and so they must be loaded after the call to convert. However, this ordering constraint was difficult to implement cleanly in FX if we used the original model builders (e.g. torchvision.models.googlenet), as it would require adding quantization logic to these FP32 builders. This is why FX now also goes through the quantized model builders (e.g. torchvision.models.quantization.googlenet) as in eager mode, but additionally performs a check to ensure the original unmodified model is used. This leads to the following behavior:
# PTQ / QAT FX
weights = get_pretrained_fp32_weights()
model = torchvision.models.ResNet50(...)
model.load_state_dict(weights.get_state_dict())
model = prepare_fx(model) # or prepare_qat_fx
calibrate(model, data) # or train
model = convert_fx(model)
evaluate(model)

# test_only FX
weights = get_quantized_weights()
model = torchvision.models.ResNet50(...)
model = prepare_fx(model)
calibrate(model, dummy_data)
model = convert_fx(model)
model.load_state_dict(weights.get_state_dict())
evaluate(model)

This approach has the additional advantage of allowing the user to use these quantized model builders with FX outside the context of train_quantization.py as follows:
googlenet = models.quantization.googlenet(
    weights=GoogLeNet_QuantizedWeights.IMAGENET1K_FBGEMM_V1,
    quantize=True,
    quantization_workflow_type=QuantizationWorkflowType.FX_GRAPH_MODE)

Hi @datumbox, continuing our discussion here:

What steps if any do I have to take to load PTQ/QAT weights?

I'm trying to figure out what are the steps for loading pre-trained quantized weights to a model. Can this be done directly to the original model without any conversions? Or some FX convert call is needed prior loading?

For the test_only mode, we use quantized weights so convert must happen before loading the weights. For PTQ and QAT, however, we use pretrained FP32 weights so convert must happen after loading the weights. This is the same for eager mode and FX graph mode. In some more detail, here is the behavior today (pseudocode):
# PTQ / QAT eager
weights = get_pretrained_fp32_weights()
model = torchvision.models.quantization.QuantizableResNet50(...)
model.load_state_dict(weights.get_state_dict())
model = prepare(model) # or prepare_qat in QAT mode
calibrate(model, data) # or train in QAT mode
model = convert(model)
evaluate(model)

# test_only eager
model = torchvision.models.quantization.QuantizableResNet50(...)
model = prepare(model)
calibrate(model, dummy_data)
model = convert(model)
weights = get_quantized_weights()
model.load_state_dict(weights.get_state_dict())
evaluate(model)

What we want is the equivalent for FX. The only differences here are (1) We use prepare_fx (and the like) instead of prepare, and (2) We use the unmodified FP32 model (e.g. torchvision.models.ResNet50) instead of the model with manually inserted quant and dequant stubs (e.g. torchvision.models.quantization.QuantizableResNet50).

@andrewor14 Thanks a lot for your work on this. Let's discuss the design doc you shared with me offline to decide on the approach and minimize throw away work. :)

As discussed offline, I'm closing this PR for now since the FX graph mode quantization API is subject to change. I will reopen this PR again and rerun all the experiments once the new API is ready. Thank you everyone for your comments so far!


chore: bump derive more 1.0

closes #724
I used full for primitives because didn't want to enable ~10 features
@DaniPopes this now requires 1.75
can we bump msrv?

https://github.com/alloy-rs/core/pull/712

-.-


Add more logs for FT and journaling

Codecov Report

Merging #14508 (3579056) into master (1a5376f) will decrease coverage by 18.58%.
The diff coverage is 15.38%.

@@              Coverage Diff              @@
##             master   #14508       +/-   ##
=============================================
- Coverage     35.52%   16.94%   -18.59%
+ Complexity     7683     2701     -4982
=============================================
  Files          1494     1494
  Lines         87637    87666       +29
  Branches      10447    10450        +3
=============================================
- Hits          31135    14851    -16284
- Misses        53900    71573    +17673
+ Partials       2602     1242     -1360

Impacted Files
Coverage Δ

...alluxio/master/journal/raft/RaftJournalSystem.java
0.00% <0.00%> (-54.87%)
:arrow_down:

...uxio/master/FaultTolerantAlluxioMasterProcess.java
0.00% <0.00%> (ø)

...o/worker/grpc/DataMessageServerStreamObserver.java
0.00% <0.00%> (ø)

...a/alluxio/cli/fs/command/DistributedCpCommand.java
0.00% <0.00%> (ø)

...a/alluxio/cli/fs/command/DistributedLoadUtils.java
0.00% <0.00%> (ø)

...main/java/alluxio/master/AlluxioMasterProcess.java
67.41% <66.66%> (-0.24%)
:arrow_down:

...mon/src/main/java/alluxio/shell/CommandReturn.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mon/src/main/java/alluxio/util/ExceptionUtils.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/src/main/java/alluxio/wire/AlluxioProxyInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../src/main/java/alluxio/wire/AlluxioMasterInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 568 more

Continue to review full report at Codecov.

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

alluxio-bot, merge this please

alluxio-bot, cherry-pick this to branch-2.7 please

alluxio-bot, cherry-pick this to branch-2.6 please


Update aws sdk code from v1 to v2

Tested the method getS3Bucket locally using work credentials (empty s3Credentials essentially)
had to update gocloud.dev/blob to a version that supports aws sdk v2
xref: https://github.com/kubernetes-sigs/prow/issues/212

cc @micahhausler

/assign @stevekuznetsov @krzyzacy

@krzyzacy we use a custom format for the creds config - https://github.com/dims/prow/blob/b21d1cf485474d6da2623ccc40849e2c8b24b2e5/pkg/io/providers/providers.go#L97-L107
So i don't think we need any changes in the job configs (famous last words!)

@petr-muller @krzyzacy i am one of the folks who keep an eye on things failing. want to land this (and happy to revert immediately if anything fails). I am NOT at kubecon as well, might as well do this exercise before folks return from there.

lol sorry I meant to let you unhold yourself, but :shipit:
/unhold


Search

Search works.
Fetches initial data. Uses queries to filter the content from the data.
Projects rendering cards. Need user card, but it doesn't use live data. James is going to refactor user card to use live data. Will update for user cards after.
Inputs are disabled when loading data from db and when db gives errors. Will add alerts with sweet alert during polish week.

All changes included with latest PR