Added Power Measurement State to DCMI collector

Added DCMI metric to definitely determine avail of Power Measurement feature
In some cases, for example with cheap Power Supply Units power consumption may be not available at all, to control this added ipmi_dcmi_power_measurement_state metric. The value is 1 for power measure is available on, and 0 otherwise.
The main point for this changes is a try to knowledge: the measurements isn't accessed due PSU broken (FW/cable/etc issues) or not avail at all on system level (and system know about that)
The host with "normal PSU":
root@host# curl -Ss "http://<IP_ADDRESS>:9291/ipmi?module=default&target=<IP_ADDRESS>" | grep -i dcmi
# HELP ipmi_dcmi_power_consumption_watts Current power consumption in Watts.
# TYPE ipmi_dcmi_power_consumption_watts gauge
ipmi_dcmi_power_consumption_watts 353
# HELP ipmi_dcmi_power_measurement_state Availability of Power Measurement (0=false, 1=true).
# TYPE ipmi_dcmi_power_measurement_state gauge
ipmi_dcmi_power_measurement_state 1
ipmi_up{collector="dcmi"} 1

The host with "strange PSU's"
root@host# curl -Ss "http://<IP_ADDRESS>:9291/ipmi?module=default&target=<IP_ADDRESS>" | grep -i dcmi
# HELP ipmi_dcmi_power_consumption_watts Current power consumption in Watts.
# TYPE ipmi_dcmi_power_consumption_watts gauge
ipmi_dcmi_power_consumption_watts 0
# HELP ipmi_dcmi_power_measurement_state Availability of Power Measurement (0=false, 1=true).
# TYPE ipmi_dcmi_power_measurement_state gauge
ipmi_dcmi_power_measurement_state 0
ipmi_up{collector="dcmi"} 1

Ping @bitfehler

Hi @k0ste, sorry and thanks for the ping. Thanks for the patch! In general, this is a welcome addition. One issue though: I'd much prefer the metric to simply not be there if it is unsupported. Could this be done, or is there a reason why the additional metric is needed? For example, is it possible for the ipmi_dcmi_power_measurement_state to change in the lifetime of a PSU? From what I understand it just depends on the hardware and never changes? If so, I'd prefer using the result of the availability check to simply drop the power consumption metric completely if not available.

Hi, @bitfehler! When I was imagine, how's better to handle this, I'm also thinked to this side, but:

Zero watts is also a metric, i.e. 0 != Nan
This will be breaking changes - some teams may use ipmi_dcmi_power_consumption_watts == 0 as query, and this queries should be rewritten (to unless(), I guess)
If we drop the ipmi_dcmi_power_consumption_watts, when the measurement is zero, this will not help to debug: why the power metrics was absent or lowered:

This because the "Intel Cloud Redundancy" is not setup'ed? [by default, Intel servers use power only from one PSU, we use raw ipmi command for turn on "shared mode"
This because something bad between PSU and Motherboard? In case, when ipmi_dcmi_power_measurement_state == 1 & ipmi_dcmi_power_consumption_watts == 0
This because measurement impossible on system level? In case, when ipmi_dcmi_power_measurement_state == 0 & ipmi_dcmi_power_consumption_watts == 0

Thanks!

Zero watts is also a metric, i.e. 0 != Nan

Absolutely!

3. If we drop the ipmi_dcmi_power_consumption_watts, when the measurement is zero

I was actually thinking more like this: do perform the test for active/not available that you added, if "active" output metric regardless of value, if not available drop metric. Shouldn't that do?

I was actually thinking more like this: do perform the test for active/not available that you added, if "active" output metric regardless of value, if not available drop metric. Shouldn't that do?

The 3rd point ☝ exactly about this idea 🌚

I am not sure I understand. Your 3rd point says

If we drop the ipmi_dcmi_power_consumption_watts, when the measurement is zero

but my suggestion is to only drop it if the new test you added in this PR says not available (i.e. when ipmi_dcmi_power_measurement_state would be 0).
As I understand it, with your current patch, the decision table would be:

ipmi_dcmi_power_consumption_watts
ipmi_dcmi_power_measurement_state
Deduction

0
0
BMC/PSU don't support it

0
1
something is amiss, investigation needed

>0
0
impossible

>0
1
metric as intended

Or am I missing something?
My suggestion would simply be to translate this into the following decision table:

ipmi_dcmi_power_consumption_watts
Deduction

N/A
BMC/PSU don't support it

0
something is amiss, investigation needed

> 0
metric as intended

Note the absence of an "impossible" state, hence I think it would make for a better solution. Sorry if I am misunderstanding s/t, maybe you can elaborate on your third point?

Note the absence of an "impossible" state, hence I think it would make for a better solution. Sorry if I am misunderstanding s/t, maybe you can elaborate on your third point?

You understanding is totally correctly. (But) If we translate "my table" to "your table" - this will be breaking changes in current how ipmi_exporter performed, where ipmi_dcmi_power_consumption_watts is always present

If the project okay for small breaking changes, I can prepare the release 1.7 with notes to CHANGELOG 🙂

@k0ste a breaking change is totally fine. can you update the patch accordingly? thanks a lot!

@bitfehler updated! The checks:
Host with Power Measurement
root@host# curl -Ss "http://localhost:9291/ipmi?module=default&target=<IP_ADDRESS>" | grep -i power
# HELP ipmi_chassis_power_state Current power state (1=on, 0=off).
# TYPE ipmi_chassis_power_state gauge
ipmi_chassis_power_state 1
# HELP ipmi_dcmi_power_consumption_watts Current power consumption in Watts (no value if Power Measurement is not avail)
# TYPE ipmi_dcmi_power_consumption_watts gauge
ipmi_dcmi_power_consumption_watts 372
ipmi_sensor_state{id="4024",name="PS1 Status",type="Power Supply"} 0
ipmi_sensor_state{id="4091",name="PS2 Status",type="Power Supply"} 0
ipmi_sensor_value{id="4024",name="PS1 Status",type="Power Supply"} NaN
ipmi_sensor_value{id="4091",name="PS2 Status",type="Power Supply"} NaN

Host without Power Measurement
root@host# curl -Ss "http://localhost:9291/ipmi?module=default&target=<IP_ADDRESS>" | grep -i power
# HELP ipmi_chassis_power_state Current power state (1=on, 0=off).
# TYPE ipmi_chassis_power_state gauge
ipmi_chassis_power_state 1
ipmi_sensor_state{id="4158",name="PS1 Status",type="Power Supply"} 0
ipmi_sensor_state{id="4225",name="PS2 Status",type="Power Supply"} 0
ipmi_sensor_value{id="4158",name="PS1 Status",type="Power Supply"} NaN
ipmi_sensor_value{id="4225",name="PS2 Status",type="Power Supply"} NaN

ping @bitfehler

Changes maden 🙏


Temporarily prevent new MNO requests

Remove new request button until MNO is extended

@benilovj I don't know if you want to do anything more thorough to disable requests, such as redirecting pages.

Closing since #591 has been merged instead.


remove preview

updated the page to remove all the content that indicates "in preview".

@duongau
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


one to many can not be used on kotlin

version = 4.0.5
I make project, IDE create a file like this:
@Override
public final boolean delete(DataPojo model) {
boolean successful = super.delete(model);
if (model.getProjList() != null) {
ModelAdapter adapter = FlowManager.getModelAdapter(Proj.class);
adapter.deleteAll(model.getProjList());
}
model.projList = null;// why not model.setProjList(null); ????
}
why "model.projList = null" ? I think it should be "model.setProjList(null)".
this throw an error is 「error: projList could call private in MainPojo」

use @OneToMany(isVariablePrivate = true)

in 4.1.0 lib will detect visibility.

in develop.

I will try this ,thanks!

in 4.1.0 lib, one to many can support  data classes ?


[WIP] ENH add wandb support for benchopt run

Frist support of Weight and Biases report for long running tasks.
Todo:

[x] Find a way to group solver per dataset and objective value (else it is not readable).
[ ] Add documentation
[ ] Add tests

Codecov Report

Merging #520 (b319e42) into main (f7523e5) will decrease coverage by 0.49%.
The diff coverage is 36.17%.

@@            Coverage Diff             @@
##             main     #520      +/-   ##
==========================================
- Coverage   54.55%   54.06%   -0.50%
==========================================
  Files          43       44       +1
  Lines        2753     2830      +77
  Branches      506      518      +12
==========================================
+ Hits         1502     1530      +28
- Misses       1137     1182      +45
- Partials      114      118       +4


ClickModel is missing from folder tools

It seems that a click.py file which contains class ClickModel  is missing  from folder tools.
For example, when I ran the run_data.py, it tried to import ClickModel from tools.click, and raised an ModuleNotFoundError .
`
from future import absolute_import
from future import division
from future import print_function
import tensorflow as tf
import numpy as np
import argparse
import os.path as osp
import sys
sys.path.append('../')
from tools.click import ClickModel
from tools.base import *
from tools.utility import *
`

Sorry for the delayed reply. These click models are collected to https://github.com/ULTR-Community/ULTRA. You can refer to the above repo to find these models.


<EMAIL_ADDRESS>doesn't work with eosjs v20.0.0-beta3

First of all, thanks for this awesome project.
I think there might be a breaking change introduced in eosjs beta3 that requires a fix for plugin-eosjs2. The error I am getting in the console is "ERROR Error: Uncaught (in promise): TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))". However it doesn't tell much.
After digging into the code, I think eosjs beta3's signatureProvider's sign method is returning of type PushTransactionArgs { signatures: string[]; serializedTransaction: Uint8Array; }. However scatter's sign method is resolving of type string[], https://github.com/GetScatter/scatter-js/blob/master/packages/plugin-eosjs2/src/index.js#L42. What's your suggestion to get around this issue? I am currently downgrading eosjs to beta2, it works perfectly.

There's an open ticket here about this: https://github.com/GetScatter/scatter-js/pull/71
We're still trying to find a good way to implement as it would break some dapps.

Yes, it is the same issue. I am closing this issue.


Can't create Archive for Android

After installing version <IP_ADDRESS> beta02-0615 when I go to create an archive it gives me this message. "AndroidManifest.xml //uses-sdk/@android:minSdkVersion '10' is less than API-16, this configuration is not supported."
This the first android project I'v created. I installed VS2019 with Xamarin.  I have Android SDK Platform 27 installed. I also have Android SDK Tools 26.1.1 installed and Android SDK Build Tools 28.0.3 & 25.0.3 installed

I fixed this by changing my AndroidManifest.xml minSdkVersion to 16

Reopening: we need to fix our project templates to use minSdkVersion 16 as well.


Linux network interface disconnection hangs existing/new gRPC requests

Please answer these questions before submitting your issue.
What version of gRPC and what language are you using?
v1.9.0
What operating system (Linux, Windows, …) and version?
Linux - CentOS amd64, Ubuntu 17.04 amd64
What runtime / compiler are you using (e.g. python version or version of gcc)
Ubuntu - gcc v7.2
CentOS - gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
What did you do?
When a session is established from the Linux client, and the interface goes down (either by physically disconnecting the [virtual] network cable or calling ifdown), the client's socket doesn't close itself (still ESTABLISHED in netstat). The server-client response streams remain open (Read() keeps blocking) without failing, and the client keeps trying to send requests.
What did you expect to see?
On interface disconnection, the socket should be closed and all active requests should fail. In addition, new requests should not try to work and return error value immediately.
What did you see instead?
The client's socket doesn't close itself and the client keeps trying to send requests and wait for responses
Anything else we should know about your project / environment?
The server is written in C#. There is at least one server-to-client stream, with a while-loop in one of the client's threads, that reads messages from the stream. There are also client-to-server non-streaming RPC calls that are being called periodically

Is the hang forever or until TCP timeout? Socket is not closed just because interface went down. TCP will detect this with it's own timeout. If you want gRPC to timeout faster use keepalive setting on channel. I am not sure if this is available in C#. May be @jtattermusch  can answer.

@srini100 The hang is forever (I've put a mechanism in place to kill the process after 10 minutes of hang, so it is definitely at least for 10 minutes).
The deadline for the gRPC call is forever - under the assumption that network disconnection will throw an error (other than a timeout).
The problematic client code is written in C++ (only the server is C#), and happens only on Linux subsystems.

I wouldn't underestimate the time it takes for TCP to timeout in stock linux. It can go on for several hours depending on various settings and activity. Have you tried TCP keepalive to isolate the issue to gRPC?

We use stock version of CentOS 7.2 and Ubuntu 17.04. Both suffer from the same issue.
I agree the TCP timeout is a good candidate, but it seems weird we wait for 10 minutes without any timeout. What gRPC channel configuration/option should I use to check the TCP keepalive?

@srini100 It appears that the TCP keepalive interval is set to 2+ hours on the Ubuntu and CentOS. So it might be the problem.

Try gRPC deadline and keepalive features. Let us know how easy or difficult you find it to use these features. Closing this issue.

Thanks @srini100. We already use the deadline feature for the 10-minutes timeout. This feature is pretty much straightforward. We will look into the keepalive feature. Thanks!


Enum semantic highlighting

In the more recent semantic highlighting feature (I am testing with clangd master, but I think this involves every server supporting the new highlighting protocol) there is some inconsistency in how enums are rendered (using vscode screenshots but this should apply to other editors too).

Enum declaration (highlighted as expected):

Enum usage (actual vs expected):

Possible reason
I think this is due to the fact that in the SemanticHighlighting.cpp file the type HighlightingKind::EnumConstant is assigned to LSP explicitly nonstandard type enumConstant, whereas LSP specification already provides enumMember (see https://github.com/llvm/llvm-project/blob/4c5e0c7fd801ccc52d3b137fa685d4215a6c57ed/clang-tools-extra/clangd/SemanticHighlighting.cpp#L573)
I tried substituting enumConstant with enumMember that, to me, seem to refer to the same concept, and the highlighting works now as expected. Is there a reason it is this way?

An otherwise quick workaround is to add in your configuration (this is of course vscode specific):
    "editor.semanticTokenColorCustomizations": {
        "[Default Dark+]": {
            "rules": {
                "enumConstant:cpp": "#4FC1FF",
                "enumConstant:c": "#4FC1FF"
            }
        }
    },

Reporting in case anyone needs this, as a separate message

Unsure why it was that way, I've put a patch in to address this shortcoming https://reviews.llvm.org/D93113

A quick look suggests that in LSP 2.x enumMember wasn't defined, that may be the reason why it was added as an extension.

Fixed in https://github.com/llvm/llvm-project/commit/62b4a69969c38158ce0c49803c50c32a76bbbe14 Made a typo so github wont auto close this


Deprecation warnings running cab_package

c:/opscode/chef/embedded/lib/ruby/gems/2.7.0/gems/chef-16.0.287-universal-mingw32/lib/chef/provider/package/cab.rb:77:in `block in dism_command': warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call (StructuredWarnings::BuiltInWarning)

Deprecation warnings running powershell_script · Issue #9849 · chef_chef


lapack-reference: 3.11 -> 3.12.0

Description of changes
Changelog: https://www.netlib.org/lapack/lapack-3.12.0.html
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 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

[x] Fits CONTRIBUTING.md.

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

The header files from lapack-reference  are exposed in via the wrapper, hence the large number of rebuilds. The new functions introduced in lapack-reference-3.12.0 are already present in the latest OpenBlas. I thus expect no problems.
I picked a few packages depending lapack, which did not reveal any problems.


[BUG] Cython 3 incompatibility with pycocotools 2.0.4

Install of pycocotools 2.0.4 broken after Cython 3.0 release.
Unable to install pycocotools 2.0.4 on a new Conda environment with python 3.10 version after Cython 3.0 release.
Code to reproduce the behaviour:
# example code

conda create -n myenv python=3.10
conda activate myenv
pip install pycocotools==2.0.4

Error:
``
Building wheels for collected packages: pycocotools
Building wheel for pycocotools (pyproject.toml) ... error
error: subprocess-exited-with-error
× Building wheel for pycocotools (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [25 lines of output]
running bdist_wheel
running build
running build_py
creating build
creating build\lib.win-amd64-cpython-310
creating build\lib.win-amd64-cpython-310\pycocotools
copying pycocotools\coco.py -> build\lib.win-amd64-cpython-310\pycocotools
copying pycocotools\cocoeval.py -> build\lib.win-amd64-cpython-310\pycocotools
copying pycocotools\mask.py -> build\lib.win-amd64-cpython-310\pycocotools
copying pycocotools_init_.py -> build\lib.win-amd64-cpython-310\pycocotools
running build_ext
C:\Users\omkarm\AppData\Local\Temp\pip-build-env-qgsimos4\overlay\Lib\site-packages\Cython\Compiler\Main.py:381: FutureWarning: Cython directive 'language_level' not set, using '3str' for now (Py3). This has changed from earlier releases! File: C:\Users\omkarm\AppData\Local\Temp\pip-install-x9kot9f1\pycocotools_a663713636de490ca1424930554632a9\pycocotools_mask.pyx
tree = Parsing.p_module(s, pxd, full_module_name)
Compiling pycocotools/_mask.pyx because it changed.
[1/1] Cythonizing pycocotools/_mask.pyx
building 'pycocotools._mask' extension
creating build\temp.win-amd64-cpython-310
creating build\temp.win-amd64-cpython-310\common
creating build\temp.win-amd64-cpython-310\Release
creating build\temp.win-amd64-cpython-310\Release\common
creating build\temp.win-amd64-cpython-310\Release\pycocotools
"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin\HostX86\x64\cl.exe" /c /nologo /O2 /W3 /GL /DNDEBUG /MD -IC:\Users\omkarm\AppData\Local\Temp\pip-build-env-qgsimos4\overlay\Lib\site-packages\numpy\core\include -I./common -IC:\Python310\include -IC:\Python310\Include "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt" /Tc../common/maskApi.c /Fobuild\temp.win-amd64-cpython-310\Release../common/maskApi.obj
maskApi.c
c1: fatal error C1083: Cannot open source file: '../common/maskApi.c': No such file or directory
error: command 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin\HostX86\x64\cl.exe' failed with exit code 2
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for pycocotools
Failed to build pycocotools
ERROR: Could not build wheels for pycocotools, which is required to install pyproject.toml-based projects
WARNING: Ignoring invalid distribution -ip (c:\python310\lib\site-packages)
WARNING: Ignoring invalid distribution -ip (c:\python310\lib\site-packages)
WARNING: Ignoring invalid distribution -ip (c:\python310\lib\site-packages)
Expected behaviour
Should have installed. but fails.
OS
Windows, Linux
Python version
3.10
Cython version
3.0
Additional context
No response

This could be more widespread.
The current experience is just creating new Conda environment and installing pycocotools specific version fails. Exact same thing was working yesterday before Cython 3.0 release.

Thank you @omkarmore83 for your report. I think the fastest fix is to pin the version of Cython side to < 3.0 on pycocotools:
https://github.com/ppwwyyxx/cocoapi/blob/9e9164f979fe4265c6f387f10e234f8697a15922/PythonAPI/pyproject.toml#L3
But I am not telling that there is no issue on Cython side though. We need to investigate.

It works with the latest pycocotools version 2.0.6. But issue is with installations that have pinned pycocotools version.

This could be more widespread.

It probably is. If projects did not specify versions or version ranges for their Cython dependency, their build might break. The two possible fixes are to either stick to an older version of Cython (0.x) or to adapt their code to Cython 3 and move on. Possibly the first for now and the second as time permits.
We have tried our best to keep Cython 3.0 backwards compatible in most regards, but it's a major release that we intentionally used to resolve issues with the usability of the language, so existing code might need adaptations.
Please report issues like this to the respective projects so that they can take the right steps on their side.

In the pycocotools 2.0.4 _mask.pyx there is this stanza
# distutils: language = c
# distutils: sources = ../common/maskApi.c

That is gone in 2.0.6. I wonder if something changed around handling of the # distutils: sources directive between Cython2 and Cython3

The details are in the commit message: https://github.com/ppwwyyxx/cocoapi/commit/b6ff8f65e03065e8f57462653a1ecc165e809389. It sounds like the current behaviour is the correct one so I don't think there's anything to fix here

I'll close this because I think it is fixed in pycocotools 2.0.6.

Because Python2-compatible pycocotools is <=2.0.3, Python2 users have no choice but to install Cython<3.0.0 before pycocotools installation.


Remote data

Description
Reverts a memset lost from my previous merge.
Type of change
Adding a memset in block_verifiers_update_functions.c
Please delete options that are not relevant.

[X] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Ran as a delegate on the testnet
Test Configuration:

Hardware: Ubuntu 20.04.4

Zach already addressed the issue

ah did not see their was already a PR for this


Supported Status for Versions

Greetings -
It would be great if angularjs.org could maintain a simple page that indicates AngularJS versions and their EOL/Security Patch/LTS status.
For example, PHP has a similar page here: http://php.net/supported-versions.php
It clearly outlines the bug fix / security patch strategy for each supported version of PHP.
For angular, there are blog entries that elude to support (security fixes for 1.2.x in the 1.6.0 announcement post, for example). But even if there was just a list, not necessarily with timelines, of the most recent version of each significant release of Angular, and the current status of support for that release, it would make it simple for a developer to choose a supported version...
Or in our case, justify staying on a 1.2.x version because security patches are still maintained.
Thanks!
C

I think this should be part of the angular/angular.js repo as it changes with the versions.

@Narretz No issue from me. One could make an argument to have it in either or both locations. However it's not published anywhere today in an overt/obvious location that I could find. I'm happy to cross-post this request if needed.

Yes, please open in angular/angular.js instead
cjsfj<EMAIL_ADDRESS>schrieb am Do., 15. Juni 2017 19:47:

@Narretz https://github.com/narretz No issue from me. One could make an
argument to have it in either or both locations. However it's not published
anywhere today in an overt/obvious location that I could find. I'm happy to
cross-post this request if needed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/angular/angularjs.org/issues/220#issuecomment-308817765,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABGYSTlTyjk6SMLKnLY-ZQvpAZZMjLpjks5sEW4ogaJpZM4N7U_x
.


An example illustrating the need for variance and structural subtyping on inductives (+ a related possible bug that needs to be factored into a separate issue)

Why failed assumption:
module Test
open FStar.List.Tot
assume Flatten: forall (a:Type) (ss:list (s:list a {is_Cons s}) {is_Cons ss}) .
    is_Cons (flatten ss)

when didn't fail assumption:
module Test
open FStar.List.Tot
assume Flatten: forall (a:Type) (ss:list (s:list a)) .
    for_all is_Cons ss /\ is_Cons ss ==> is_Cons (flatten ss)

I think this fails because F* is too stupid to figure out that the inner type of ss is also a list, because the inner refinement gets in the way:
/examples/bug-reports/bug590.fst(6,21-6,23): Subtyping check failed; expected type (Prims.list (Prims.list a)); got type (ss#19:(Prims.list (s#22:(Prims.list a){(Prims.b2t (Prims.is_Cons s@0))})){(Prims.b2t (Prims.is_Cons ss@0))})

If this is indeed the problem then the real fix requires implementing polarities and structural subtyping for inductives (https://github.com/FStarLang/FStar/issues/65#issuecomment-65823677). Wouldn't hold my breath on that one though, so in the meanwhile here are some workaround:

Just turn the s:list a {is_Cons s} into list a, if possible
If not write an explicit coercion:

let rec coerce (#a:Type) (ss:list (s:(list a){is_Cons s}))
  : Pure (list (list a)) (requires True)
                         (ensures (fun ss' -> ss === ss')) = admit()
  (* match ss with *)
  (* | [] -> [] *)
  (* | h::t -> h :: (coerce t) *)

let flatten_lemma (a:Type) (ss:list (s:list a {is_Cons s}) {is_Cons ss}) :
  Lemma (requires True) (ensures (is_Cons (flatten (coerce ss)))) = ()

For some reason F* cannot type coerce now:
./examples/bug-reports/bug590.fst(6,4-10,27): could not prove post-condition
./examples/bug-reports/bug590.fst(6,4-10,27): could not prove post-condition

Wouldn't hold my breath on that one though

Although it seems that @aseemr-msr  might be up to something: https://github.com/FStarLang/FStar/issues/319#issuecomment-229926382

For some reason F* cannot type coerce now:

It seems that F* has troubles proving that two Nils of different types are ===. It does prove that the conses are equal though, so something is fishy here.

@beurdouche  I don't think @nikswamy will agree calling the original problem a bug, since it seems just a missing feature we already know about https://github.com/FStarLang/FStar/issues/65#issuecomment-65823677. As for my workaround failing, we should first figure out what's going on and once we do that maybe file a separate issue for that. Finally, I thought of needinput a label for issues where we're waiting for information (say precise reproduction steps) from the original poster ... which is not the case here. I can already very well reproduce this.

@catalin-hritcu @nikswamy: I labelled it a bug because it is in a file named bug590 ... Be my guest in changing it to "question" or something else. Also if you can add a label when opening the issue it will prevent me from mislabelling it ;)

Did a few more experiments on this with Kenji and we think there is no bug here. The type I was trying to give to coerce is wrong because the type indices of Nil and Cons do affect equality. In particular, it's expected that Nil #(list a) is different from Nil #(s:(list a){Cons? s}) in the current system.
Now the reason the Cons case of coercion was succeeding is maybe a bit surprising, but still correct. Because of the recursive call to coerce t F* can prove that coerce t === t from which it can show eq2 (list (list a)) (list (s:(list a){Cons? s})), which is enough to type-check the rest of the term. In fact, eq2 (list (list a)) (list (s:(list a){Cons? s})) makes the environment inconsistent, just that F* needs a tiny bit of help to prove it.


Feat/health check229

Resolves #229
Changes:

Add Health check for user so they can confirm whether node is synced, syncing, or running at all.

Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Other (please describe):

Testing
Requires testing

[x] Yes
[ ] No

In case you checked yes, did you write tests??

[ ] Yes
[x] No (but plan to!)

Putting this on hold for a bit, if somebody else would like to have a go, please feel free. My main trouble is consulting the block manager service from the health check service


Squeezebox JSON-RPC

Description:
Refactor the Squeezebox code to use the more reliable (and modern) JSON-RPC method.
Related issue (if applicable): fixes #1462 #4222
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here> - to come. This change uses a different port. The discovery method for Squeezebox will also need to alter.
Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] New dependencies are only imported inside functions that use them ([example][ex-import]).

Would prefer this this not to be released just yet, since although I've tested, I'm sure there will be other cases. Could it be merged into dev and to get feedback for a week or two?

I think this sets up Squeezebox for making it async, as per #4995. I've used aiohttp as a replacement for the telnet interface. @armills, @pvizeli, @lwis, would you be interested in reviewing?

There's a lot of unrelated changes in this PR. Can you use the instructions here to rebase your changes onto dev, rather than merging in the latest? https://home-assistant.io/developers/development_catching_up/ You might need to do an interactive rebase to drop the unrelated changes.

Oh gosh, thanks for spotting @armills. All rebased and the superfluous stuff has gone. Apologies for letting it slip by.

LGTM after linter fixes. We should still wait for #4995 to be merged and update the commands accordingly.

Thanks for the reviews. I've made a separate PR on netdisco and tweaked the init here a little to use the new information. If I've overstepped what should be in this PR, I'll remove that commit.

I had one comment on the Netdisco PR that will also require an update to this PR, holding off merging until both addressed.

Please can you rebase this against 2a7a419ff3e3f964608d16f6bf77774f040f6578

Made the changes balloob suggested in the disco PR. Should I do the async changes in this PR or another? Should merge okay as is.

@dasos it is not okay because you expect discovery info that the current version of netdisco linked against Home Assistant is not returning.

Sorry, I must have misunderstood. 3f02133 uses the new dictionary returned by netdisco, which I thought is what you suggested?  If I revert 3f02133, this PR will then work with disco 0.8.1. I have tested this okay.

Ahh, just seen https://github.com/home-assistant/netdisco/pull/82. Should this PR use those new keys?

@dasos ok, let's revert the PR that uses the new discovery. That can be another PR.

OK. There is now no dependency on the update to disco in this PR.  I think this PR is full enough now, and I will submit two more in the coming days for full async and to improve the disco behaviour. :ok_hand:

Nice! Thanks 🐬


Add .idea/misc.xml to .gitignore

close #42
Changes

Add .idea/misc.xml to .gitignore

Codecov Report

Merging #43 (b3e7149) into main (9f62fb2) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main      #43   +/-   ##
=========================================
  Coverage     30.04%   30.04%
  Complexity       20       20
=========================================
  Files            40       40
  Lines           436      436
  Branches         48       48
=========================================
  Hits            131      131
  Misses          304      304
  Partials          1        1

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 9f62fb2...b3e7149. Read the comment docs.


Do not hash the second argument of Arg

The Eq instance for Arg ignores the second argument; therefore, the Hashable
instance must also ignore the second argument, lest two equal values have
different hashes.

This nasty... this has been inherited from semigroups and thus affects also the semigroups package in a non-trivial way if we're going to change this :-/
https://github.com/ekmett/semigroups/commit/94ea28d386f6d4259ad9f8607c4e60a0afc141b8
cc @RyanGlScott @ekmett

I'm happy to merge the same fix into semigroups.

@ekmett I'm not sure you realise the dilemma I'm facing:
the migration scheme underlying the hashable/semigroups/base trio was under the assumptiont hat the legacy GHC < 8 code wouldn't change, as otherwise we end up with difficult to understand API versioning:
How do you make sure that current consumers that for 3 years assumed the current Hashable Arg instance don't suddenly get a different one (across multiple base versions)?
How do you declare that you need the new Arg instance semantics across multiple base versions?
I'm not willing to change anything until we have figured this out is a satisfying way.

I'm really am not sure I see the issue.
Let's break down all of the users by case:
If an existing user has a bound that are correct today that say they work with semigroups < 0.19, hashable < 1.3, base < 4.13, with lower bounds that extend clear back into the stone-age far enough to when they needed to ask for semigroups support to cover 7.x then they'll definitely never encounter the new instance until they upgrade one of those bounds. And any attempt at using Arg's Hashable instance before that they might already be doing is already screwed up.
To demand the new behavior, and still work on really old GHCs, for the few folks still toodling around on 7.x they'd need something like (semigroups >= 0.19, base < 4.9) | (base >= 4.13 && < 5), probably jury-rigged with a flag. You can't get the fixed instance on the GHCs that were released between base 4.9 and 4.13 but we can offer it through semigroups on old-enough GHCs. In reality if you're demanding the new behavior you're probably only in one of those two disjoint cases, and so just requiring base >= 4.13 && < 5 if probably what most new code would demand.
If you really need a version of Arg with the new semantics that works back over the versions of base between 4.9 and 4.13, then you're probably better off defining your own Arg data type in your code base and implementing the 8 lines worth of instances yourself. Heck, if someone really wants to, they can spit out some arg-compat package with just such a fixed arg data type, but the key is that it is a user fixable concern for the few users who may even be affected that need backwards support over the intervening versions.
So with that I see a set of options that seem to encompass how everyone should react to the fixing this bug.

Any update on this, @hvr? The status of the next semigroups release (which incorporates this commit) is a bit uncertain since the corresponding change hasn't been released in hashable yet.

I think, we need a major hashable-<IP_ADDRESS>, and have semigroups-0.19 have hashable >= 1.3 lower bound.

On 28 Apr 2019, at 18.08, Ryan Scott<EMAIL_ADDRESS>wrote:
Any update on this, @hvr? The status of the next semigroups release (which incorporates this commit) is a bit uncertain since the corresponding change hasn't been released in hashable yet.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Sorry for a raster: But I think that don't suddenly get a different one won't be possible with major releases for both semigroups and hashable

Or dually, how do you declare in your build-depends, that you need the new Arg instance semantics across multiple base versions?

build-depends: hashable ^>=1.3
if !impl(ghc >=8.0)
  build-depends: semigroups ^>=0.19

Amendum to the previous
with GHC-7 the NO-IP boxes are clear. With GHC-8 it's a bit more complicated as  in semigroups-0.18 we have
  -- legacy configuration
  if impl(ghc < 7.11.20151002)
    if flag(hashable)
      build-depends: hashable >= 1.1  && < 1.3

(which btw should be `!impl(ghc >= 8.0) IMO)
So with GHC-8 it's possible to land on semigroups-0.18 + hashable-1.3 square; but with GHC-8 the Hashable Arg instance comes from hashable: semigroups is "empty" in that scenario: i.e. with GHC-8 it's irrelevant whether you have semigroups-0.18 or semigroups-0.19.
To put it other way. semigroups is no-op for new GHCs. For old GHCs it shims also hashable, but then semigroups build-depends: hashable will be in action, so:

semigroups-0.18 shims old hashable, thus hashable <1.3
semigroups-0.19 shims new hashable, thus hashable >=1.3 bound

for convenience:

GHC 7
hashable-1.2
hashable-1.3

semigroups-0.18
OLD from semigroup
NO-IP

semigroups-0.19
NO-IP
NEW from semigroup

GHC 8
hashable-1.2
hashable-1.3

semigroups-0.18
OLD from hashable
NEW from hashable

semigroups-0.19
OLD from hashable
NEW from hashable


changing payment details

Changing payment detail
The payment detail has been changed from DOT address to Fiat. Details for the payment can be found in the invoice submitted.

I have read and hereby sign the Contributor License Agreement.


[synapse-managed-private-endpoints] Migration to new recorder

Packages impacted by this PR
synapse-managed-private-endpoints
Issues associated with this PR
#17994
Describe the problem that is addressed by this PR
Migrate to the new recorder
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


fix argument order

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.07%) to 89.744%

Totals

Change from base Build<PHONE_NUMBER>:
-0.07%

Covered Lines:
908

Relevant Lines:
982

💛  - Coveralls


dev-c7 does not respect secondary groups

So shared folders wont work with group access for e.g.  dcs
Also dls-release won't work due to permissions on its queue folder.
I'm wondering if this might help https://github.com/containers/udica

@MichaelStubbings Please can you paste a summary of the solution here from your confluence page, and also in the README, and then close this issue.


Link underlying heating/boiler 'state' to the state of eTRV

This change would introduce the capability to link the underlying state of the heating system (e.g. 'heating', 'off') to the state of radiator valve.
It could work initially by getting the boiler status from a linked MiHome thermostat (using act_t) and using config.json.
But support for other smart system integration (e.g. Wiser, Tapo, Nest) system setting should be investigated and implemented if possible.

My Setup for Smart Heating
I'm happy to help with testing! Here's my current heating system setup:

Thermostat: Google Nest Learning Thermostat (3rd Gen)
Boiler: Gas combination system boiler with radiators
Communication Protocol: OpenTherm (bi-directional communication)

Nest Controls
The Nest thermostat communicates with the boiler using OpenTherm. This allows the Nest to:

Turn the boiler on and off
Set the radiator water flow temperature

The flow temperature is determined by several factors:

Temperature Difference (Delta): The difference between the Nest's measured room temperature and the desired temperature you set.
Weather Compensation: The Nest considers the outside temperature to adjust the flow temperature for optimal heating efficiency.

Nest
The Nest is located in the hallway, where the radiator is always off. This means the Nest might not accurately reflect the actual temperature in heated rooms.
However, I have integrated the Nest thermostat with Home Assistant as a climate entity, allowing for more granular control. I don't use the scheduling function on the Nest itself, relying entirely on Home Assistant for a more sophisticated "away" mode and other automations.
Room Control with eTRVs
Each room has an electronic thermostatic radiator valve (eTRV) that can be controlled through Google Assistant via Google Home speakers or displays. This allows for individual room temperature adjustments.  I also control the "Nest" (hallway thermostat) through this method, effectively turning the boiler on and off.
Current Manual Operation
Currently, all eTRVs are set to "auto" with a base temperature of 8°C. To heat a specific room, I manually adjust the eTRV temperature to the desired level (e.g., from 16°C to 18°C).
I also need to manually adjust the Nest thermostat to a slightly higher temperature (0.5°C to 1°C) than the current reading (e.g., Nest reading 17°C, adjust to 17.5°C-18°C) to trigger the boiler to turn on and heat the room.
Automation
My plan is to leverage advanced scheduling add-ins within Home Assistant. This will enable me to create individual room temperature schedules ranging from 8°C to 18°C, depending on the time of day.
I plan to create automations in Home Assistant that monitor the requested eTRV setpoints and actual room temperatures. These automations could potentially incorporate data from additional room temperature sensors. When the room temperature falls below the eTRV setpoint by a specific hysteresis value (between 0.5°C and 1°C, to be determined), the automation would trigger.
However, due to OpenTherm communication, simply "turning on" the boiler isn't possible. Instead, the automation would need to adjust the Nest setpoint to a specific value ("x") above the current room temperature.
Calculating "x" for Optimal Flow Temperature
I plan to calculate "x" as a weighted average based on the delta temperature values from all eTRVs in rooms requesting heat (i.e., rooms where the actual temperature is lower than the eTRV setpoint). Essentially, a larger delta (greater difference between room temperature and desired temperature) would result in a higher "x" value. This, in turn, would signal the Nest to set a higher water flow temperature, allowing for faster room heating. For example, a 1°C delta might trigger a 40°C flow temperature, while a 10°C delta could result in a 50°C or 60°C flow temperature.

Does the Nest report the boiler flow and return temperatures?  It does on the Wiser, and the individual Wiser TRVs 'call for heat' when needed.
What is tricky to do, and similar to your use case, is integrating with the energenie eTRVs; ideally I need them to 'call for heat' too; I guess I could do a similar thing with my Wiser hallway room stat; or use 'boost' mode to manually switch on the boiler (but it will boost all by the looks of things).
It's a shame we couldn't fudge an eTRV 'call for heat' to operate with our smart boiler systems...   Do you know what energenie does with it's Nest integration?

Hi @Achronite
I can see the flow and return temperatures on the boiler's built in display, but not on any Google API or Nest interface.
That's cool you can see those temperatures, do you mean your Wiser is also connected via OpenTherm? I have thought about buying/building my own OpenTherm controller.
The Energenie Nest integration, not sure what it used to do, but it does nothing anymore, possibly because Nest's servers shut down a while ago and moved to Google.

That's cool you can see those temperatures, do you mean your Wiser is also connected via OpenTherm? I have thought about buying/building my own OpenTherm controller.

Yes it is connected only via OpenTherm. I went for Wiser after researching on the HA forums.

The Energenie Nest integration, not sure what it used to do, but it does nothing anymore, possibly because Nest's servers shut down a while ago and moved to google

That's a shame; it would have been good to know how this worked.

@Achronite
I think I will get one of those ESP8266 to Opentherm converters, so I can "spy" on the Nest-to-boiler data.


automatically use the correct LSF units (resolves #1691)

@jessebrennan This is ready for review & merge

Let's ping @ejacox as well because he's the one with the power to merge. I'll gladly look it over though.

Merges are currently held up until release 3.9.0 is out. Hopefully today.

Looks good @mr-c. Thank you.


Install semantic ui

UI changes caused by semantic-ui-css installation is also solved

@OscarWang114 Please help check this PR, thanks!


[HUDI-7957] fix data skew when writing with bulk_insert + bucket_inde…

…x enabled
Change Logs

imporve BucketIndexUtil partitionIndex algorithm make the data be evenly distributed.
BucketPartitionUtils in spark use BucketIndexUtil method, same logic as flink.

Impact

flink partitionIndex will use new algorithm

Risk level (write none, low medium or high below)
low
Documentation Update
None
Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

@danny0405 @xicm From the discussion results and unit test situations, we can conclude that in the case of consecutive partitions, the new algorithm is more stable than the old algorithm. However, in the case of non-consecutive partitions, both algorithms exhibit some fluctuations. For example, with a parallelism of 10 and 5 buckets, the new algorithm can only achieve half of the parallelism for partitions 01 and 03, whereas the old algorithm can fully utilize the parallelism. With a parallelism of 20 and 5 buckets, and the same partitions, the new algorithm can achieve half of the parallelism, but the old algorithm can only achieve a quarter. The specific outcome depends on the initial position of the partitions.

Yes, the result of the two algorithms depends on the hash value of the partition, which is almost random. Is there a better way to get the partition number?

@danny0405 @xicm From the discussion results and unit test situations, we can conclude that in the case of consecutive partitions, the new algorithm is more stable than the old algorithm. However, in the case of non-consecutive partitions, both algorithms exhibit some fluctuations. For example, with a parallelism of 10 and 5 buckets, the new algorithm can only achieve half of the parallelism for partitions 01 and 03, whereas the old algorithm can fully utilize the parallelism. With a parallelism of 20 and 5 buckets, and the same partitions, the new algorithm can achieve half of the parallelism, but the old algorithm can only achieve a quarter. The specific outcome depends on the initial position of the partitions.

Yes, the result of the two algorithms depends on the hash value of the partition, which is almost random. Is there a better way to get the partition number?

@KnightChess
The old algorithm has overflow problems, if we fix the overflow problem, the old algorithm is better.
          int partitionIndex = (partition.hashCode() & Integer.MAX_VALUE) / (parallelism / bucketNum) * bucketNum;
          int globalIndex = Math.abs(partitionIndex) + curBucket;
          return BucketIdentifier.mod(globalIndex, parallelism);

if we fix the overflow problem, the old algorithm is better.

Let's fire a fix for it, and @KnightChess let's keep the Flink hashing algorithm the same as it is and we can improve it in a separate PR I think.

@xicm no, although fixing the overflow problem, the old will not be better, you can try the ut. I have tried before.

@danny0405 I have tried before, the result is the new algorithm better. I will fix it in a separate pr.

@xicm no, although fixing the overflow problem, the old will not be better, you can try the ut. I have tried before.

oh, there's something wrong with my test case , the old algorithm also has drawbacks.

@xicm @KnightChess So we reach concensus the algorithm raised by @KnightChess is better? If that's true, let's fire a fix in a separate PR.

@xicm @KnightChess So we reach concensus the algorithm raised by @KnightChess is better? If that's true, let's fire a fix in a separate PR.

Both algorithms have drawbacks.
For example,
parallelism = 10, bucketNumber = 5 and partition = ["2021-01-01", "2021-01-03"]
old: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
new: [2, 2, 2, 2, 2]
parallelism = 20, bucketNumber = 5 and partition = ["2021-01-01", "2021-01-03"]
old: [2, 2, 2, 2, 2]
new: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
The element in the array means how many data slice each TM processes.

don't know why this check will contain docker moudle, other success look like not contain, retrigger again

Both algorithms have drawbacks.

@xicm That's fine, the new algorithm looks simpler, there is no need to distinguish between different parallelisms.

@danny0405 @KnightChess Shall we use the new algorithm? new algorithm looks simpler. The previous implementation had an overflow problem，need a fix？

@xicm @danny0405 yes, I will submit a new pr to fix it recently


8.0.0 compiles all the Elm files on a single file change

Hello!
We just upgraded to 8.0.0 and it looks like saving a single file causes all files to recompile. Furthermore sometimes that happens twice for some reason. Wonder if anyone else ran into this?

I am seeing the same after upgrading. Did you find any solution @DawidJanczak ?

@FluidSense this turned out to be the same issue we had a while back: https://github.com/elm-community/elm-webpack-loader/issues/123 The fix for that also works here, but the line number changed: commenting out https://github.com/elm-community/elm-webpack-loader/blob/master/index.js#L110 fixes this for us.

Thanks for the update! Sadly, that did not resolve the issue for me, but thanks anyway!

That's interesting! I wonder what the difference is (and why more people don't run into this). Try commenting some more code around that if block, see if anything sticks and let us know when it does :)


⚠ Spryr has degraded performance

In d4c8348, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 7719 ms

Resolved: Spryr performance has improved in eaca55c after 35 minutes.


Can't rename Drive Files with NodeJS library

From @ghego1 on July 16, 2017 15:54
It seems it is impossible to rename files in Google Drive in a NodeJs app.
I'm using:

googleapi nodeJs library v. 20.1.0.
node v. 8.1.4

The app is handling requests for files fine, and it is able to duplicate files. However, when updating them, the new name is never applied.
I do get as a response the file resource, which would entail that the request was successful.
I'm doing this:
const google = require( 'googleapis' );
let googleService = google.drive( 'v3' );

let params = {
  auth: testedAndValidOAuth,
  fileId: validFileId,
  uploadType: 'multipart',
  name: "some name 2"
};

googleService.files.update( params, ( err, response ) => console.log(response));

For the property uploadType I've tried with and without it, with all the available options: resumable, multipart, and media. When trying media I got the following error:
Error: The API returned an error: Error: Uploads must be sent to the upload URL. Re-send this request to https://www.googleapis.com/upload/drive/v3/files/xxxfileIdxxx?uploadType=media&name=some+name+2

I've tried to edit manually the link in the library and the error went away, but unfortunately the name did not change.
Looking in the library I've noticed that the name param is not mentioned:
@param {object} params Parameters for request
@param {string=} params.addParents A comma-separated list of parent IDs to add.
@param {string} params.fileId The ID of the file.
@param {boolean=} params.keepRevisionForever Whether to set the 'keepForever' field in the new head revision. This is only applicable to files with binary content in Drive.
@param {string=} params.ocrLanguage A language hint for OCR processing during image import (ISO 639-1 code).
@param {string=} params.removeParents A comma-separated list of parent IDs to remove.
@param {boolean=} params.supportsTeamDrives Whether the requesting application supports Team Drives.
@param {boolean=} params.useContentAsIndexableText Whether to use the uploaded content as indexable text.
@param  {object} params.resource Media resource metadata
@param {object} params.media Media object
@param {string} params.media.mimeType Media mime-type
@param {string|object} params.media.body Media body contents
@param {object} [options] Optionally override request options, such as `url`, `method`, and `encoding`.
@param {callback} callback The callback that handles the response.

So I'm wondering, am I doing something wrong, is this intended, meaning that we can't edit file names, or is it a bug in the library?
I've also opened a StackOverflow question here.
Copied from original issue: googleapis/googleapis#404

From @ghego1 on July 17, 2017 12:51
Turns out it has to be set via
params.resource = { name: "newname"}

The docs are not perfectly clear on this, perhaps it would be worth mentioning it.


Question: desired velocity for UnitreeA1 as sine-cosine feature

I was just wondering if there is a rational behind using the target velocity for this environment as a sine-cosine feature as input in the policy instead of the standard way of using the vector?

Hi @OliEfr,
sorry for the delay in response...
There is no specific reason behind it, but you can do the same thing using a vector. In fact, in the next big release, this will change.
Since you are very active here, consider joining the discord channel I created for LocoMujoco. It is a better place to ask such questions.
Thanks for your contributions!
I just merged them.

Hi @robfiras
No problem, I was just curious if there is something I didn't know about and the sin-cos features improves learning. Ok, I'll join the discord then.


The sample code given isnt compiling, please check :)

The code is in TypeScript. Please ensure you have the typescript runtime for NodeJs installed.

Hmm, I thought the build process takes care of this. I'll investigate, thanks for reporting!

I've tested it with JavaScript and TypeScript and I cannot seem to reproduce this error. What environment are you using? And are you sure you have run npm install linkedin-profile-scraper ?


Implement CONST support

The description of this does not match the contents. We need to merge Rust first before we can patch it.

@maximg: Any comments from your side? Is this the merge request for Rust support just poorly named? Something is strange here.

Strange indeed, why would @przygienda try to push something from my repository. Please ignore this merge request for now.

@przygienda Rust for Thrift is developed in https://github.com/terminalcloud/thrift, if you want to get your changes upstream, could you open a merge request there? @Jens-G I believe this MR should be closed.

@jfarrell could you close this PR?

@jfarrell could you close this PR?

Rust is getting popular in service-side development world. Having Thrift-Rsut integration is mutually beneficial for both projects. So I would like to this this PR resolved.
Does anybody work on cleanup/upstreaming changes from above?

@anatol, please read the entire thread.
The bottom line is that we (Thrift) patiently wait for @maximg to make the PR for Rust support. It's their code, therefore it is their decision whether or not they think that the Rust code is ready. This PR is from someone else not involved in the Thrift Rust stuff.

Having Thrift-Rsut integration is mutually beneficial for both projects. So I would like to this this PR resolved.

I fully agree with you. If you want to speed up things by contributing, I could imagine that @maximg will be happy to get some feedback from third-party eyes. You should talk to him.

I googled the state of rust/thrift and found that the original repo from https://github.com/maximg/thrift has been abandoned, the development later moved to https://github.com/terminalcloud/thrift that also been abandoned and later picked up by https://github.com/jsgf/thrift/tree/rust that at this point contains the most complete set of rust changes.
There is also a ticked filed to track the Rust integration activity https://issues.apache.org/jira/browse/THRIFT-2945

have a first rudimentary implementation of that on my branch. On top added something that allows to plug custom traits into the generated code (I used that to implement over redis-rs a trait to have REDIS persistency support). Looks like Thrift is moving pretty slowly and Rust for Thrift diverged into couple of branches ...


start using boost:stacktrace

At the moment this is just using the library in the invariants, which is the no-brainer place to add it.
Tracebacks associated with an invariant look like this:
[11:31:35]

****
Range Error
idx
Violation occurred on line 180 in file /scratch/RDKit_git/Code/GraphMol/ROMol.cpp
Failed Expression: 450 < 6
----------
Stacktrace:
 0# Invar::Invariant::toString[abi:cxx11]() const in /scratch/RDKit_git/build/lib/libRDKitRDGeneral.so.1
 1# Invar::operator<<(std::ostream&, Invar::Invariant const&) in /scratch/RDKit_git/build/lib/libRDKitRDGeneral.so.1
 2# RDKit::ROMol::getAtomWithIdx(unsigned int) in /scratch/RDKit_git/build/lib/libRDKitGraphMol.so.1
 3# RDKit::SmilesToMol(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, RDKit::SmilesParserParams const&) in /scratch/RDKit_git/build/lib/libRDKitSmilesParse.so.1
 4# 0x00005585E70741D4 in ./Code/GraphMol/graphmolMolOpsTest
 5# 0x00005585E701AAF2 in ./Code/GraphMol/graphmolMolOpsTest
 6# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
 7# 0x00005585E701AD3E in ./Code/GraphMol/graphmolMolOpsTest
----------
****

These aren't particularly attractive, but they are a lot more informative than what we currently have.

Could we run the benchmarks with the patch?  I would expect Invariants to be in the hot path for a lot of operations and am curious what the overhead is.  I hope it's negligible.

Yeah, I'll run them a bit later.
You expect this to make a difference even if the invariants aren't actually triggered?

Looks like there are also fun CI problems for me to investigate. :-)

I don't think it should make a difference if the invariant is not triggered. Even if it is triggered, it should not have a big impact unless you use try..catch in a loop (which is a bad thing in itself). SireMol was doing that and caused the Windows version to crawl. After I added the WINDBG define also Windows started to behave.

yeah, and you really really shouldn't be doing try...catch with the invariants.

To address the performance question.
Here's the result of running new_timings.py (https://github.com/rdkit/rdkit/blob/master/Regress/Scripts/new_timings.py) on my linux box with master:
| 2020.09.1dev1 | 6.6 | 3.1 | 2.9 | 0.0 | 17.0 | 18.2 | 0.0 | 66.2 | 67.7 | 12.2 | 16.2 | 7.2 | 34.2 | 2.1 |

and with this branch:
| 2020.09.1dev1 | 6.8 | 3.2 | 2.9 | 0.0 | 16.8 | 18.0 | 0.0 | 64.7 | 64.6 | 12.2 | 16.0 | 7.2 | 34.4 | 2.2 |

So no impact on performance with code that's not triggering a bunch of invariant failures (and such code should absolutely not exist).

@greglandrum just a ping to see if we can get turn this off for OSX/Windows

Updated the PR to make it linux only. Let's see what happens in CI


Modified the serverType function to support Red hat kvm platform

I run into unbounded error when run sure.py on kvm platform.
Check the sys_vendor and get "Red hat", Add Red hat in server_type and return the correct check result.
Test the modified script in the production environment.

Confirmed with @jacontre-c that we are good to merge this. Thank you for your contribution!


componentWillReceiveProps is now deprecated (there are warnings when using this component)

https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#gradual-migration-path

It's used at the line 59 of packages/modal-react-native-web/src/index.js.

Why not just submit a PR ? Oh yeah, https://github.com/Dekoruma/react-native-web-modal/pull/25 is open since march and still not merged.

modal is now supported in react native web.
https://github.com/necolas/react-native-web/releases/tag/0.14.0
Thank you for using this library!


Hide documents for joining organisations

Organisations that are just joining GOV.UK (created as "Coming soon" in Whitehall ) currently display all associated documents on their organisation .
This change will prevent these documents from rendering on the organisation page until the organisation is live.
Trello

It would be good to say something in the commit message about why this is changing, even if it's a vague "don't confuse users by showing tagging to coming soon organisations".

It would be good to say something in the commit message about why this is changing, even if it's a vague "don't confuse users by showing tagging to coming soon organisations".

I've updated the commit message 👍


Let's make the colours more kid friendly

Too many different colours, but it's a start.

LGTM. The keyboard blue is maybe a bit too much. Probably want to tweak the icons to be darker too, but not a blocker.


chore: add sync-wave to the Subscription object

Now the subscription object will have precedence over all the apps in the Application creating the subscription first.
Also, the cluster object will skip validation since the CRDs may not exists

@sxd - closing this pr because it conflicts with #25 - the desired approach to deploying operators is through values-<clustergroup>.yaml and by nature of how subs are handled won't conflict with dependent resources.


Ainter 7589/add schedule fields to muting rule go client

https://newrelic.atlassian.net/browse/AINTER-7589
Added the following fields and types to Alerts Muting Rules:
schedule: {
    endRepeat:

    endTime:

    repeat:

    repeatCount:

    startTime:

    timeZone:

    weeklyRepeatDays:
}

Goals:

Fields and types available via Go Client should match what’s currently exposed via NerdGraph.
Add unit tests
Update integration tests

Opening new PR against original upstream master

Opening new PR against original upstream master


child.cpp: validate_cmd: Support symbolic links in environment variables

On some systems /bin is a symbolic link to /usr/bin (/bin -> /usr/bin), When using the '-c' parameter to specify the executable program in the environment variable, the problem of "multiple binary files matching" occurs, for example:
  $ sudo bpftrace -e 'kprobe:do_nanosleep { printf("%d sleeping\n", pid); }' -c 'sleep 5'
  ERROR: Failed to fork child: path 'sleep' must refer to a unique binary but matched 2 binaries

Debugging the bpftrace program through gdb can also be verified:
  (gdb) p valid_executable_paths
  $9 = std::vector of length 2, capacity 2 = {"/bin/ls", "/usr/bin/ls"}

This commit fixes the issue. The v1[0] will cause CICD busybox error.
[0] https://github.com/iovisor/bpftrace/pull/2689

@danobi Seems all is well. please review. thanks.

Can we create a test for this?

Is this necessary? This PR only solves the error when /usr/bin/sleep and /bin/sleep are the same executable file. How should this situation be deployed in the CICD environment?
$ ls -l /bin
lrwxrwxrwx. 1 root root 7 Aug 10  2021 /bin -> usr/bin
$ realpath /bin/sleep
/usr/bin/sleep

This problem may not exist in different environments (including CICD), so I suggest not to add a test case. What do you think?

I just force push a modification. There may be worse cases like
  $ realpath /usr/bin/ping /bin/ping /usr/sbin/ping /sbin/ping
  /usr/bin/ping
  /usr/bin/ping
  /usr/bin/ping
  /usr/bin/ping

  $ sudo bpftrace -e 'kprobe:do_nanosleep { printf("%d sleeping\n", pid); }' -c 'ping -c 4 0'
  ERROR: Failed to fork child: path 'ping' must refer to a unique binary but matched 4 binaries

So instead of using case 2 to solve it, it is better to use std::unordered_set<std::string>+abs_path() to solve this problem.

The fix looks good to me. But I agree with Viktor -- test here would be good. But rather than depend on CI environment (which is not reliable like you mention), we could create a tempdir and then populate it with a an executable shell script and some symlinks to it. I think that should be reliable.

The fix looks good to me. But I agree with Viktor -- test here would be good. But rather than depend on CI environment (which is not reliable like you mention), we could create a tempdir and then populate it with a an executable shell script and some symlinks to it. I think that should be reliable.

I have a question, shall we add a test example in C, such as the following code in tests/child.cpp:
TEST(childproc, match_multi_exe)
{
  char path[] = "rootfs/";
  // make temp rootfs directory
  // make /usr/bin/ under rootfs
  // create tmp shell script "sleep.sh" (with x permission)
  // create link: /bin -> /usr/bin
  // put the rootfs/usr/bin and rootfs/bin to env
  // THEN, test sleep.sh
}

right? I'm not sure if my idea is accurate, if not, please give me some advice. thanks.

Yeah that looks right to me

Yeah that looks right to me

OK, I'll try it.

@danobi @viktormalik I just add test childproc.multi_exec_match, please review.
        $ sudo ./tests/bpftrace_test --gtest_filter=childproc.multi_exec_match
        Note: Google Test filter = childproc.multi_exec_match
        [==========] Running 1 test from 1 test suite.
        [----------] Global test environment set-up.
        [----------] 1 test from childproc
        [ RUN      ] childproc.multi_exec_match
        [       OK ] childproc.multi_exec_match (10 ms)
        [----------] 1 test from childproc (10 ms total)

        [----------] Global test environment tear-down
        [==========] 1 test from 1 test suite ran. (10 ms total)
        [  PASSED  ] 1 test.


vSphere cluster Waiting for SSH to be available...

Creating a generic vSphere cluster through rancher v2.3.3, vsphere 6.7u3
I have a very bare cloudinit that should work from what I can read. I've got CentOS nodes running 7.7
cloud-config
rancher
Popping into the hosts, I see no sign the sshkeys are being copied over either unless I'm looking in the wrong spot...
Logs below

Useful
Info

Versions
Rancher v2.3.3 UI: v2.3.25

Route
authenticated.cluster.nodes.index

2020-01-13T23:32:38.165993215Z 2020/01/13 23:32:38 [INFO] [node-controller-docker-machine] Running pre-create checks...
2020-01-13T23:32:38.301991305Z 2020/01/13 23:32:38 [INFO] [node-controller-docker-machine] Creating machine...
2020-01-13T23:32:38.305291660Z 2020/01/13 23:32:38 [INFO] [node-controller-docker-machine] Running pre-create checks...
2020-01-13T23:32:38.312985464Z 2020/01/13 23:32:38 [INFO] [node-controller-docker-machine] (two1) Generating SSH Keypair...
2020-01-13T23:32:38.343219158Z 2020/01/13 23:32:38 [INFO] [node-controller-docker-machine] (ac2) Waiting for VMware Tools to come online...
2020-01-13T23:32:38.894996631Z 2020/01/13 23:32:38 [INFO] [node-controller-docker-machine] Creating machine...
2020-01-13T23:32:38.902920944Z 2020/01/13 23:32:38 [INFO] [node-controller-docker-machine] (one1) Generating SSH Keypair...
2020-01-13T23:32:39.074981120Z 2020/01/13 23:32:39 [INFO] [node-controller-docker-machine] Creating machine...
2020-01-13T23:32:39.089929559Z 2020/01/13 23:32:39 [INFO] [node-controller-docker-machine] (three1) Generating SSH Keypair...
2020-01-13T23:32:39.119949635Z 2020/01/13 23:32:39 [INFO] [node-controller-docker-machine] (two1) Cloning VM from VM or Template: /Dawgs-v2/vm/whatswrongwithcloudinit...
2020-01-13T23:32:39.126925987Z 2020/01/13 23:32:39 [INFO] [node-controller-docker-machine] (two1) Finding datastore /Dawgs-v2/datastore/primaryhosts64k
2020-01-13T23:32:39.597402138Z 2020/01/13 23:32:39 [INFO] [node-controller-docker-machine] (one1) Cloning VM from VM or Template: /Dawgs-v2/vm/whatswrongwithcloudinit...
2020-01-13T23:32:39.610932414Z 2020/01/13 23:32:39 [INFO] [node-controller-docker-machine] (one1) Finding datastore /Dawgs-v2/datastore/primaryhosts64k
2020-01-13T23:32:39.655450639Z 2020/01/13 23:32:39 [INFO] [node-controller-docker-machine] (three1) Cloning VM from VM or Template: /Dawgs-v2/vm/whatswrongwithcloudinit...
2020-01-13T23:32:39.659984405Z 2020/01/13 23:32:39 [INFO] [node-controller-docker-machine] (three1) Finding datastore /Dawgs-v2/datastore/primaryhosts64k
2020-01-13T23:33:05.953123769Z 2020/01/13 23:33:05 http: TLS handshake error from <IP_ADDRESS>:57462: EOF
2020-01-13T23:33:05.953184034Z 2020/01/13 23:33:05 http: TLS handshake error from <IP_ADDRESS>:57466: EOF
2020-01-13T23:33:50.203291749Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (two1) Adding network: /Dawgs-v2/network/VM Network
2020-01-13T23:33:50.549309964Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (two1) Setting disk.enableUUID to TRUE
2020-01-13T23:33:50.558529896Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (two1) Setting guestinfo.cloud-init.config.data to #cloud-config
2020-01-13T23:33:50.568024973Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (two1) rancher
2020-01-13T23:33:50.606600685Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (three1) Adding network: /Dawgs-v2/network/VM Network
2020-01-13T23:33:50.614022717Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (one1) Adding network: /Dawgs-v2/network/VM Network
2020-01-13T23:33:50.790272651Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (two1) Creating cloud-init.iso
2020-01-13T23:33:50.832758604Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (two1) Uploading cloud-init.iso
2020-01-13T23:33:50.921665207Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (three1) Setting disk.enableUUID to TRUE
2020-01-13T23:33:50.924851001Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (one1) Setting disk.enableUUID to TRUE
2020-01-13T23:33:50.929943344Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (three1) Setting guestinfo.cloud-init.config.data to #cloud-config
2020-01-13T23:33:50.937024611Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (one1) Setting guestinfo.cloud-init.config.data to #cloud-config
2020-01-13T23:33:50.950050474Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (one1) rancher
2020-01-13T23:33:50.951825006Z 2020/01/13 23:33:50 [INFO] [node-controller-docker-machine] (three1) rancher
2020-01-13T23:33:51.202815176Z 2020/01/13 23:33:51 [INFO] [node-controller-docker-machine] (three1) Creating cloud-init.iso
2020-01-13T23:33:51.204823913Z 2020/01/13 23:33:51 [INFO] [node-controller-docker-machine] (one1) Creating cloud-init.iso
2020-01-13T23:33:51.263056685Z 2020/01/13 23:33:51 [INFO] [node-controller-docker-machine] (one1) Uploading cloud-init.iso
2020-01-13T23:33:51.268061910Z 2020/01/13 23:33:51 [INFO] [node-controller-docker-machine] (three1) Uploading cloud-init.iso
2020-01-13T23:33:51.555600481Z 2020/01/13 23:33:51 [INFO] [node-controller-docker-machine] Waiting for machine to be running, this may take a few minutes...
2020-01-13T23:33:51.581471148Z 2020/01/13 23:33:51 [INFO] [node-controller-docker-machine] Detecting operating system of created instance...
2020-01-13T23:33:51.581513782Z 2020/01/13 23:33:51 [INFO] [node-controller-docker-machine] Waiting for SSH to be available...
2020-01-13T23:33:52.296118893Z 2020/01/13 23:33:52 [INFO] [node-controller-docker-machine] (two1) Waiting for VMware Tools to come online...
2020-01-13T23:33:52.840945270Z 2020/01/13 23:33:52 [INFO] [node-controller-docker-machine] (one1) Waiting for VMware Tools to come online...
2020-01-13T23:33:52.871938142Z 2020/01/13 23:33:52 [INFO] [node-controller-docker-machine] (three1) Waiting for VMware Tools to come online...
2020-01-13T23:33:56.817189297Z 2020/01/13 23:33:56 http: TLS handshake error from <IP_ADDRESS>:57604: EOF
2020-01-13T23:33:59.632268727Z 2020/01/13 23:33:59 [INFO] [node-controller-docker-machine] Waiting for machine to be running, this may take a few minutes...
2020-01-13T23:33:59.659623781Z 2020/01/13 23:33:59 [INFO] [node-controller-docker-machine] Detecting operating system of created instance...
2020-01-13T23:33:59.659673328Z 2020/01/13 23:33:59 [INFO] [node-controller-docker-machine] Waiting for SSH to be available...
2020-01-13T23:34:07.120329341Z 2020-01-13 23:34:07.120007 I | mvcc: store.index: compact 181335
2020-01-13T23:34:07.124771790Z 2020-01-13 23:34:07.124567 I | mvcc: finished scheduled compaction at 181335 (took 3.310353ms)
2020-01-13T23:34:37.544589292Z 2020-01-13 23:34:37.544263 I | etcdserver: start to snapshot (applied: 200002, lastsnap: 100001)
2020-01-13T23:34:37.551750814Z 2020-01-13 23:34:37.551559 I | etcdserver: saved snapshot at index 200002
2020-01-13T23:34:37.552163817Z 2020-01-13 23:34:37.551993 I | etcdserver: compacted raft log at 195002
2020-01-13T23:34:39.660858519Z 2020/01/13 23:34:39 [INFO] [node-controller-docker-machine] Waiting for machine to be running, this may take a few minutes...
2020-01-13T23:34:39.679073823Z 2020/01/13 23:34:39 [INFO] [node-controller-docker-machine] Waiting for machine to be running, this may take a few minutes...
2020-01-13T23:34:39.709094509Z 2020/01/13 23:34:39 [INFO] [node-controller-docker-machine] Waiting for machine to be running, this may take a few minutes...
2020-01-13T23:34:39.719009862Z 2020/01/13 23:34:39 [INFO] [node-controller-docker-machine] Detecting operating system of created instance...
2020-01-13T23:34:39.731020206Z 2020/01/13 23:34:39 [INFO] [node-controller-docker-machine] Waiting for SSH to be available...
2020-01-13T23:34:39.743006322Z 2020/01/13 23:34:39 [INFO] [node-controller-docker-machine] Detecting operating system of created instance...
2020-01-13T23:34:39.761026572Z 2020/01/13 23:34:39 [INFO] [node-controller-docker-machine] Waiting for SSH to be available...
2020-01-13T23:34:39.777023237Z 2020/01/13 23:34:39 [INFO] [node-controller-docker-machine] Detecting operating system of created instance...
2020-01-13T23:34:39.795004423Z 2020/01/13 23:34:39 [INFO] [node-controller-docker-machine] Waiting for SSH to be available...
2020-01-13T23:35:26.864012832Z 2020/01/13 23:35:26 http: TLS handshake error from <IP_ADDRESS>:57956: EOF
2020-01-13T23:35:42.113973653Z 2020/01/13 23:35:42 http: TLS handshake error from <IP_ADDRESS>:58018: EOF
2020-01-13T23:37:59.308265110Z 2020/01/13 23:37:59 http: TLS handshake error from <IP_ADDRESS>:58608: EOF
2020-01-13T23:39:00.135845350Z 2020/01/13 23:39:00 [INFO] [node-controller-docker-machine] The default lines below are for a sh/bash shell, you can specify the shell you're using, with the --shell flag.
2020-01-13T23:39:00.135896858Z 2020/01/13 23:39:00 [INFO] [node-controller-docker-machine]
2020-01-13T23:39:00.393098895Z 2020/01/13 23:39:00 [INFO] Generating and uploading node config
2020-01-13T23:39:07.132115798Z 2020-01-13 23:39:07.127105 I | mvcc: store.index: compact 182517
2020-01-13T23:39:07.134388351Z 2020-01-13 23:39:07.134171 I | mvcc: finished scheduled compaction at 182517 (took 5.813659ms)
2020-01-13T23:39:08.084975132Z 2020/01/13 23:39:08 http: TLS handshake error from <IP_ADDRESS>:58900: EOF
2020-01-13T23:39:09.983680794Z 2020/01/13 23:39:09 [INFO] [node-controller-docker-machine] The default lines below are for a sh/bash shell, you can specify the shell you're using, with the --shell flag.
2020-01-13T23:39:09.983738006Z 2020/01/13 23:39:09 [INFO] [node-controller-docker-machine]
2020-01-13T23:39:10.325529563Z 2020/01/13 23:39:10 [INFO] Generating and uploading node config
2020-01-13T23:39:15.412126060Z 2020/01/13 23:39:15 [ERROR] NodeController c-vrwlg/m-gcqjs [node-controller] failed with : Error creating machine: Error detecting OS: Too many retries waiting for SSH to be available.  Last error: Maximum number of retries (60) exceeded
2020-01-13T23:39:15.495368780Z 2020/01/13 23:39:15 [INFO] Removing node ab2
2020-01-13T23:39:15.528397000Z 2020/01/13 23:39:15 [INFO] [node-controller-docker-machine] About to remove ab2
2020-01-13T23:39:15.528440977Z 2020/01/13 23:39:15 [INFO] [node-controller-docker-machine] WARNING: This action will delete both local reference and remote instance.
2020-01-13T23:39:17.267266702Z 2020/01/13 23:39:17 [INFO] [node-controller-docker-machine] Successfully removed ab2
2020-01-13T23:39:17.275931867Z 2020/01/13 23:39:17 [INFO] Removing node ab2 done
2020-01-13T23:39:17.320928970Z 2020/01/13 23:39:17 [ERROR] NodeController c-vrwlg/m-gcqjs [node-controller] failed with : nodes.management.cattle.io "m-gcqjs" not found

Looks like this works great in 2.3-head
I am closing this and just gonna suck it up and wait til 2.3.4

That is seemingly lacking in the documentation. The best "example" I can find is https://rancher.com/docs/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/ which seems to lack any real direction on what I actually need to do when making a template.
As while looking at this from the outside it makes sense, but when following the docs... there is something missing to guide you into "Hey you! You NEED cloud-init installed on your base template or this will fail utterly without any clear reason!"

So true! There's a clear lack of documentation regarding the fact that:

Cloud-init is mandatory
Cloud init is used by Rancher even when nothing has been set in the #cloud-config section of the Node Template / Machine Pool
the operating system inside the VMware VM needs the cloud-init package installed

This documentation needs to be updated: https://rancher.com/docs/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/


README: Update copyrights to end with current year

BTW, I have green light to generalize the copyright statements from our side. So, can we get that going?

BTW, I have green light to generalize the copyright statements from our side. So, can we get that going?


[LOG4J2-3040][3.x] Avoid ClassCastException in JeroMqManager with custom LoggerContextFactory

Signed-off-by: Grzegorz Grzybek<EMAIL_ADDRESS>I tried using org.apache.logging.log4j.test.junit.LoggerContextFactoryExtension, but somehow I couldn't make it work (maybe incompatible with org.apache.logging.log4j.core.test.junit.LoggerContextRule?

The extensions are for JUnit 5 as their extensions framework is fairly different from the old rules API. They don't interact.

This was closed automatically by Github because we renamed the branch called master (which some people find offensive) to main. Feel free to resubmit to the main branch.

New PR: #1313.


Don't store upcoming invoice in memory

The invoice does not actually exist, but is just a preview. It's not an invoice that should be retrieved along with all other invoices for a given customer.
Previously, if you tried to list all invoices for a customer after fetching the upcoming invoice, the upcoming invoice would be included in the list of all invoices for that customer.
For now I left the invoice ID in place, however in my testing, Stripe does not return an ID for an upcoming invoice (likely because it can't be retrieved by ID), however their API documentation suggests the return JSON of fetching the upcoming invoice would have an ID: https://stripe.com/docs/api#upcoming_invoice
I had to change fetching line items for an upcoming invoice so that it'd use the line items in the response, not query the API to get the line items, since that'd fail the test as you can't fetch line items for an invoice that is not stored in memory.

Thanks for the quick merge!


Post release tasks for 4.8.1

Description
This issue attempts to track the steps necessary to complete post-release maintenance tasks for 4.8.1.
The goal is to complete the following tasks, each task must have a PR associated with this issue.
The branches must follow the naming: merge-<ORIGIN_BRANCH>-into-<DESTINATION_BRANCH>. For example, merge-4.8.1-into-4.9.0.
Tasks

[ ] Merge branch 4.8.1 into branch 4.9.0.
[ ] Merge branch 4.9.0 into branch 4.10.0.
[ ] Merge branch 4.10.0 into branch master.
[ ] Publish GitHub release as latest.
[ ] Delete all stage pre-releases for 4.8.1 (https://github.com/wazuh/wazuh-security-dashboards-plugin/releases).
[ ] Delete all stage tags for v4.8.1. BE CAREFUL NOT TO DELETE DEFINITIVE TAG. Example: v4.8.1-rc1, 4.8.1-alpha1, etc.

I'm closing this issue as this repository will not be used until Wazuh v4.9.0


Fix code scanning alert - DOM text reinterpreted as HTML

Tracking issue for:

[ ] https://github.com/mertturkmenoglu/horizon/security/code-scanning/1

fixed with the latest commit


crappy streaming impl

https://github.com/hwchase17/langchain/issues/363
@hwchase17 how much does this make you want to cry?

haha only a little a bit
are you using this already locally? my preference would be to start by adding a separate stream method to the class rather than create a subclass (until we figure out common abstractions)

Yeah this works locally. I get the generator out and can stream the tokens individually

@hwchase17 any chance this can go in the release? If not I can just work off a fork until we iron it out.


Fix the tool metadata

Closes: https://github.com/CycloneDX/cyclonedx-cli/issues/351

@jkowalleck the current version 0.25.0 has still the bug solved by this commit, which causes all generated sbom to be invalid. Do you plan to make a new release containing this fix?

@DudusB maybe.
see https://github.com/CycloneDX/cyclonedx-cli/issues/362


Importing files from lit require the .js extension in TypeScript

Description
Importing files such as lit/decorators.js in typescript requires .js extension to be in the import name. This is very weird as in TS it is common to exclude the extension and intellisense defaults to autocompleting without the .js due to the presence of .d.ts files
Repro:

import {customElement} from 'lit/decorators'
see errors

Expected Results
Importing from lit/decorators should work
Actual Results
It does not work unless you import from lit/decorators.js

This is very much intentional. We want to enable usage of import maps that don't list every file used in the lit packages. This means that import maps need to be able to use prefix mappings: https://github.com/WICG/import-maps#packages-via-trailing-slashes That requires that imports use the full file path including extension, which is why we require that via our package exports.

Can we write our own imports like that but allow the user to consume our library with or without them?

No, because that would require even more import map lines. With the restrictions we have now, each package only needs two lines.
What's the problem with the extension?

I might have a naïve VsCode setup, but whenever the IDE tries to auto-magically fill in the import, it's always without the .js extension. Then I have to manually add the extension to make the build succeed.
You can learn to work around it quite quickly, but it creates a more painful onboarding.
Is there an setting from the IDE side of things that corrects the incorrect automatic imports?

VS Code by default adds the extension based on whether or not other imports in the file use extensions. There's a setting typescript.preferences.importModuleSpecifierEnding to control this.
Build systems that resolve and rewrite import specifiers have blurred things here, but in a browser an import must either end in an extension or have a specific import map entry. We don't want to require large import maps to use Lit, and we cannot have the same file loadable from two URLs or we get module duplication, so we can't even give extensionless imports as an option. It has to be one way or the other.

As you know, it's not common in TS to include the extension and seems like a code smell to deviate from the norms. I'm mostly just echoing what I've seen from the slack. Though I agree quite a bit on the benefits of import maps

@rollup/plugin-resolve doesn't support extensionless imports anymore, so there's another reason to avoid them.
https://github.com/rollup/plugins/issues/684#issuecomment-770517359

Brought up by Liz in the office: this is going to cause issues with internal style guide where users importing decorators or directives will have to insert the extension. This will cause lint errors and might slow down engineers seeking readability.
Might be able to sidestep it with an index.ts file that reexports everything or just slash the extensions and serve js bundles that don't require import maps

Google's internal TypeScript guide continues to have issues with reality. I suggest we file issues there.

While I generally agree with it being backwards in some spots it tends to follow de facto convention here. Though an index file might sidestep it with import {...} from 'lit/index'

Just ran into this issue as well, The thing that throws me is that it's not consistent - e.g. this works
import {customElement, property, state} from 'lit/decorators.js'; // js required
import {asyncReplace} from 'lit/directives/async-replace'; // js optional

But this doesn't work
-import {customElement, property, state} from 'lit/decorators.js';
+import {customElement, property, state} from 'lit/decorators';
import {asyncReplace} from 'lit/directives/async-replace';

Of course this also works
import {customElement, property, state} from 'lit/decorators.js';
-import {asyncReplace} from 'lit/directives/async-replace';
+import {asyncReplace} from 'lit/directives/async-replace.js';

but it feels strange needing to remember to add the extension on for just this one package.
Ended up spending about 20 minutes trying to find out what's going on since the error message is a somewhat cryptic

Module not found: Error: Package path ./decorators is not exported from package

made worse by the fact the IDEs appear to believe it's valid with or without, so if nothing is going to change then a highly visible note in the docs would be good.

Though an index file might sidestep it with import {...} from 'lit/index'

A re-exporting index file obscures the module graph and over fetches modules. It's much better for modules to directly import exactly what they use.

@hailwood

import {customElement, property, state} from 'lit/decorators.js'; // js required
import {asyncReplace} from 'lit/directives/async-replace'; // js optional

I'm not sure what environment would require the extension on decorators.js but not async-replace.js. Sounds like a bog somewhere.

Ended up spending about 20 minutes trying to find out what's going on since the error message is a somewhat cryptic

Module not found: Error: Package path ./decorators is not exported from package

This error is technically correct - we don't export that module from lit. It would be nice if the tool found what file you probably were referring to and added a "Did you mean ... ?". What tools are you using so we can file a bug?

@justinfagnani
IDE: PHPStorm 2021.2 (though VScode has the same result)
Build Tool<EMAIL_ADDRESS>(via<EMAIL_ADDRESS>with<EMAIL_ADDRESS>OS: Ubuntu 21.04
Babel Plugins:

@babel/plugin-proposal-export-default-from
@babel/plugin-proposal-optional-chaining
@babel/plugin-proposal-nullish-coalescing-operator

For the record, we're going to keep the package exports that require extensions on imports.
@hailwood's issue with inconsistency seems to be because we have a specific mapping for lit/decorators.js  and a subpath folder mapping for ./directives/. We can fix this inconsistency by making a mapping for each file.


JSON output flag for using programatically

Having used dnspyre for a while it's been great, but I kept ended up either grepping the stdout output or using --csv flag going to a third or fourth pipe to pass it downstream to do something with it. However the csv flag doesn't give me the rest of the output summary, like successful vs failed request counts and the p99 etc overviews.
Would it be possible to make a mode where the stdout output is json only, and non json output goes into stderr?
I was considering running dnspyre in a loosely isolated distributive mode on kubernetes but need some way to take the response from a worker pod back to a controlling operator, and json probably makes the most sense - can capture the stdout and curl it back to the operator http server to collect results per worker.

Hello, thanks for opening the issue!
So If I understand it correctly, you would appreciate a new option - -json, which when specified will change the report output to be printed as json, something like
 {
    “totalRequests”:20,
    “totalErrors” : 1,
     “responses” :  {
        “NOERROR” : 17,
         “SERVFAIL” : 1
     },
     “qps”: 5,
     “benchmarkDurationInSeconds” : 30
 }

I will think about the JSON structure, but it makes sense 👍

Yeah looks good, the granularity of the csv ranges would be good in an array of objects or similar. That way I can count how many are over an arbitrary maximum response time limit too.

Hello @danielloader , I have released a new version 2.8.0, which adds support for a new --json flag, which will output results in a JSON format. Please check whether it fits your use case, adjustments to format can be made :)


@sentry/vite-plugin with axios breaks build "'default' is not exported..."

Environment
What version are you running? Etc.

MacOS 13.0.1, Apple M1 Max
Node 18.12.1
npm 8.19.2
vite 3.2.41

Steps to Reproduce

Clone Repo
Run yarn install
Run yarn build

Expected Result
The build succeeds.
Actual Result
With the @sentry/vite-plugin in place in the vite.config.ts the build script breaks with the message
Error: 'default' is not exported by node_modules/form-data/lib/browser.js, imported by node_modules/axios/lib/env/classes/FormData.js

Removing the plugin from the config, the build works.

Hi, we just fixed this issue. Please upgrade to version 0.2.2 and let us know if it resolves the problem for you.

Unfortunately not. I pushed an update to the Repo

+1 I am experiencing a similar issue.

Hi again. We just released version 0.2.3 of the plugin. Can you try it out and confirm (or deny) that the new version works? Thank you!

Very sorry for the late response, I got sick this week. Build seems to work now (kinda), but now this error appears:
$ vue-tsc && vite build
vite v3.2.4 building for production...
[sentry-vite-plugin] Info: Sending error and performance telemetry data to Sentry.
[sentry-vite-plugin] Info: To disable telemetry, set `options.telemetry` to `false`.
✓ 147 modules transformed.
dist/assets/vue.5532db34.svg     0.48 KiB
dist/index.html                  0.44 KiB
dist/assets/index.af2b4dae.css   1.26 KiB / gzip: 0.65 KiB
dist/assets/index.889cd5c6.js    144.21 KiB / gzip: 52.42 KiB
dist/assets/index.889cd5c6.js.map 1055.49 KiB
[sentry-vite-plugin] Error: Command failed: /***/sentry-vite-axios-issue/node_modules/@sentry/cli/sentry-cli releases new b4590792cbcd6671746353ae07d5056e400bffbc
error: An organization slug is required (provide with --org)

Add --log-level=[info|debug] or export SENTRY_LOG_LEVEL=[info|debug] to see more output.
Please attach the full debug log to all bug reports.

[sentry-plugin] Command failed: /***/sentry-vite-axios-issue/node_modules/@sentry/cli/sentry-cli releases new b4590792cbcd6671746353ae07d5056e400bffbc
error: An organization slug is required (provide with --org)

Add --log-level=[info|debug] or export SENTRY_LOG_LEVEL=[info|debug] to see more output.
Please attach the full debug log to all bug reports.

error during build:
Error: Command failed: /***/sentry-vite-axios-issue/node_modules/@sentry/cli/sentry-cli releases new b4590792cbcd6671746353ae07d5056e400bffbc
error: An organization slug is required (provide with --org)

Add --log-level=[info|debug] or export SENTRY_LOG_LEVEL=[info|debug] to see more output.
Please attach the full debug log to all bug reports.

    at ChildProcess.exithandler (node:child_process:412:12)
    at ChildProcess.emit (node:events:513:28)
    at ChildProcess.emit (node:domain:489:12)
    at maybeClose (node:internal/child_process:1091:16)
    at Socket.<anonymous> (node:internal/child_process:449:11)
    at Socket.emit (node:events:513:28)
    at Socket.emit (node:domain:489:12)
    at Pipe.<anonymous> (node:net:313:12)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
4.80s user 0.36s system 169% cpu 3.049s total

Thanks for the update. That error is probably intended. Can you double-check that you're providing an org value? Maybe the env var isn't set.

Ah true, sorry, my bad! Then it works 👍

@DotCoyote great!


Suggestion: Rename emailproxy.config in repository

When updating via git pull, it errors out with "Your local changes to the following files would be overwritten by merge: emailproxy.config". Of course I can stash or simply copy my config file to a backup, but:
Would it be a viable option to rename emailproxy.config in the repository to emailproxy.config.example and have users rename / copy the file on first use? Or are there other suggestions?
Thanks

Thanks for the suggestion. It's an option, but it would make setup harder, so instead, if you're actively tracking the gut repository I'd recommend using the --config-file option and keeping your personal config file elsewhere.

I overlooked this option, thanks for the suggestion!


[now-dev] Fix usage of .nowignore to match production

WIP - this needs a lot of work
Consolidate logic for .nowignore so it works properly with now dev.
Fixes #2224

Codecov Report

Merging #2233 into canary will increase coverage by 0.03%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           canary   #2233      +/-   ##
=========================================
+ Coverage     4.5%   4.54%   +0.03%
=========================================
  Files         246     245       -1
  Lines        8985    8909      -76
  Branches      978     965      -13
=========================================
  Hits          405     405
+ Misses       8557    8481      -76
  Partials       23      23

Impacted Files
Coverage Δ

src/commands/dev/lib/dev-builder.ts
0% <0%> (ø)
:arrow_up:

src/commands/dev/lib/dev-server.ts
0% <0%> (ø)
: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 9d73f77...7918ece. Read the comment docs.