menu bar icon [feature request]

Just enjoying some tunes and remain baffled by the Hermes icon (I work in healthcare, so the current icon always has a different context for me).
I was thinking rather than focusing on the "branding" of Hermes... what about showing the current album art? I know it'd be tiny, but it would be neat to show the cover art (w/ the play/pause status overlaid) in the menu bar.
There'd have to be some work done to deal with different color menu bars, etc. Probably not a small amount of work, but figured I'd float the idea...  Love the app, BTW!

What's funny is that in the context of healthcare, particularly in North America, the caduceus is used incorrectly.  The caduceus is the staff that was wielded by the Greek god Hermes, but has no relation to medicine whatsoever.
The confusion comes from the fact that the caduceus closely resembles the Rod of Asclepius, which does symbolize medicine, as it was wielded by the Greek god Asclepius, a deity associated with medicine.
Greek mythology aside, I personally think the dock app needs to be updated, at least to one that blends in well with Yosemite and El Capitan.

Indeed, you're right. Great distinction. I never looked closely enough to notice this staff was missing the snakes!  (-:

Please note that Hermes is essentially an abandoned project — if anyone wants to work on fixing this, great, but neither Alex, Winston nor I are actively working on it nor do any of us have any plans to do so in the near future.
This sounds like a great feature idea, FWIW.

Understood @nriley. Thanks for contributing such a great piece of software to the community!

Thanks to @paullj1, we've got a beta version which lets you see album art in your menu bar:
https://github.com/HermesApp/Hermes/releases/tag/v1.2.9b1

1.3.0 is now out with this feature. Thanks again to @paullj1!

This is so awesome -- great enhancement. Thanks to @paullj1 and @nriley!!

I'm sorry if this is a dumb question, but is Hermes supposed to be visible in the menu bar?  If so, I don't see it.  I'm on Sierra.  Thanks.


Fixed comments notice background overlay #9446

I fixed the comments notice background overlay in #9446  by adding border-bottom-radius-left & right of 5px to line 57 and it worked.

7c4aec23.png">
<img width="770" alt="Screenshot 2022-10-23 at 12 41 26" src="https://user-images.githubusercontent.com/105293813/197406154-f147bd0e-b4f0-4638-9d36-03b0

Please try to keep the amount of pull requests opened and then closed to a minimum in the future. It creates a lot of busywork for us to have pull requests come and go like this.

I’m sorry about that. I’ll keep that in check in the future @thibaudcolas


Implements greyscale (white) chairs

About the PR
Adds white chairs into the game.
The sprite for these has been rotting in the codebase for god knows how long.
Why / Balance
The sprite for this has probably existed since the RSI was imported.
Probably good for mappers? If it looks any good is up for debate, but considering this was literally only an 8 line change I figured I might as well go ahead and do it.
Me

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

Changelog
no cl no fun

me


Remove type coupling between core and display

Bug
When attempting to install @pixi/core without @pixi/display, you get this error. There was previous work to decouple runtime the core and display (#6450), but the types were still creating this unnecessary coupling.
node_modules/@pixi/core/index.d.ts:10:31 - error TS7016: Could not find a declaration file for module '@pixi/display'. <EMAIL_ADDRESS>implicitly has an 'any' type.
  Try `npm install @types/pixi__display` if it exists or add a new declaration (.d.ts) file containing `declare module '@pixi/display';`

10 import { DisplayObject } from '@pixi/display';

Description
Created two interfaces that define the surface area between the Renderer and the DisplayObject/Container. These are called IRenderableObject and IRenderableContainer. Potentially this could be a single interface since we only render Containers, in practice.

Codecov Report

Merging #7121 (7d1de57) into main (13b7c21) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main     #7121   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           17        17
  Lines          699       699
=========================================
  Hits           699       699

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 13b7c21...7d1de57. Read the comment docs.

Codecov Report

Merging #7121 (7d1de57) into main (13b7c21) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main     #7121   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           17        17
  Lines          699       699
=========================================
  Hits           699       699

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 13b7c21...7d1de57. Read the comment docs.

Hi, FYI this merge broke typing with @pixi/events since the latter one is using a DisplayObject in it's own Renderer interface: https://github.com/pixijs/pixijs/blob/95d15c11f8025eec9c00c6685bf8a1b200778218/packages/events/src/EventSystem.ts#L20
It would probably make more sense for @pixi/events use AbstractRenderer from Core or at least change the interface to use the new IRenderableObject but might break again in the future.

@graphnode could you please file a new issue?


My work on the frontend

Lots of files were changed and potential conflicts may arise from the changes.

looking at the PR, i accepted the current changes and ran the code. Probably just an issue on my end, but can't seem to search anything.

It looks like there are some syntax errors in App,js that may have been caused by a manual merge

Still in progress! DO NOT APPROVE

Good for merge


Retrying requests when hitting the API's limits

This is a WIP. I want to rework the logic for making a request a bit, so it's easier to add tests for the retry logic. Currently, that's rather hard to do as we need to stub the HTTP requests, etc.
I'll work on that before submitting a final solution for this. I've also added a configuration object for the gem as that might be a neater way to configure it.

With this PR, we're adding very simplistic support for automatic retries. We don't have support yet for a maximum amount of attempts nor for some jitter. I'll create tickets for that.
For now, I think this is sufficient.

@cdmwebs @swanny85 I've updated this PR so we can use it for LCF too. I don't want to depend on the work in a branch too much.
NOTE TO SELF: Update the codebase for Endy too as we're using the branch there.

@cdmwebs would you mind removing CircleCI? I don't have access to it.


Support the concurrent request.

Add the concurrency examples for pure Grpc client and Qdrant client.
Remove the Rwlock of Channel as the concurrency request could use the same channel.
Remove the allow_retry param for with_channel as the tonic will retry automatically.

Thanks for your contribution!
Could you please elaborate regarding the motivation for this change?
Also it would be easier to review if the clippy fixes were handled in a different PR.

Hello, I want to join the company of Qdrant. I have sent the cv. And Andre said that I have to make a contribution to the https://github.com/qdrant/rust-client. And I get this issue(https://github.com/qdrant/rust-client/issues/30) in the github issues.
For the concurrent use of the client, I get https://github.com/hyperium/tonic/issues/285.So maybe we do not need the pool to do the concurrent request. We could just clone the client to do the concurrent request.


D11 several issues

Transport:

[x] Bluetooth (on android phone)
[ ] Serial (USB)

Browser console logs (press F12 and copy "Console" tab contents):

Using brave adroid

Label JSON: export your label to JSON and attach it here

[{"width":40,"height":12,"unit":"mm","dpmm":8,"printDirection":"left","title":"D11"}]

describe your issue here
Default suggested print task (D11_v1) was offsetting my labels, after reading https://github.com/MultiMote/niimblue/issues/25 and switching to D110 offsetting issue was solved
"Snow" always appears no matter the threshold
Top 2 were both printed using D110 print task first using min threshold and second using max. The rest of the labels were printed with suggested D11_v1:

It's so strange. Can you attach full exported label JSON (you exported just dimensions)?
Also paste your printer's parameters please (it's unter the "gear" button near the printer's name).

label_1730705859.json
Printer info:
connectResult: 2
protocolVersion: 1
modelId: 512
serial: [REDACTED]
mac: [REDACTED]
charge: 2
autoShutdownTime: 4
labelType: 1
hardwareVersion: 0x0906
softwareVersion: 0x0903
Model metadata:
model: D11
id: 512
dpi: 203
printDirection: left
printheadPixels: 96
paperTypes: 1,5
densityMin: 1
densityMax: 3
densityDefault: 2
Rfid info:
tagPresent: true
uuid: [REDACTED]
barCode: 01222281
serialNumber: [REDACTED]
allPaper: 192
usedPaper: 49
consumablesType: 1
Heartbeat data:
paperState: -1
rfidReadState: -1
lidClosed: true
powerLevel: 2

Also what does barCode field represents?

Also what does barCode field represents?

That's some label identifier. It sent to the cloud server from official apps to get label size and some other label parameters.
Example:
POST https://print.niimbot.com/api/template/getCloudTemplateByOneCode HTTP/1.1
Content-Type: application/json
niimbot-user-agent: AppVersionName/999.0.0

{ "oneCode" : "LABEL_BARCODE" }

I have no Idea what can cause such behavior.

That "Snow" not appeared in the print preview dialog? Printer should print exact same image as in preview.
Try to lower your label dimensions (30x11 for example). Something changed?
Try to make Bluetooth HCI dump of the print with official NIIMBOT app. That would help a lot.

"Snow" in preview doesn't match "snow" in actual print. Even when threshold set to 1 there is still "snow"
Same thing
Can't find it in the app

After resolving #43 I printed label in desktop with default settings and only change Print task to D110 — no more snow :D
I wonder why it only happens on phone

Okay, tried on different phone with Chrome and it printed fine as well :/
So it's only my phone, didn't have this issue with niimbot app before it was locked behind account creating.
Maybe an issue with brave mobile? I only installed it because I didn't had chromium browser on phone.

Maybe an issue with brave mobile

Installed latest Brave and still no artifacts.
Personally I am using Kiwi Browser because it have DevTools and has support of Chrome extensions.

I am closing it for now as I didn't found a way to replicate this issue.
Let me know if you can reproduce this on another device.

@MultiMote what about Print Task? It was very unintuitively to use. Only realized I had to use one with different printer name after reading https://github.com/MultiMote/niimblue/issues/25

@danielwerg D11 (modelId 512) has different revisions. Each revision uses different print task. Unfortunately I not fully understand what print task to choose.
Maybe I will figure it out later.

Fixed in https://github.com/MultiMote/niimbluelib/commit/c543bf3ceb1ba24a58d4693aebe15367f801c96d hopefully.


abel.transform() transform arguments as dict or **kwargs

Currently, the abel.transform() function is defined like this:
def transform(
    IM, direction='inverse', method='three_point', center='none',
        verbose=True, symmetry_axis=None,
        use_quadrants=(True, True, True, True),
        transform_options={}, center_options={}):

which means that it accepts dict arguments for the keyword arguments that will be passed to the transform functions and to the centering functions. Like this for example:
AQ1 = abel_transform[method](Q1, direction=direction, **transform_options)

This leads to a somewhat clunky syntax if the user wants to specify arguments to these sub-functions:
abel.transform(data, method='basex',
             transform_options={ 'basis_dir' : '/Users/mydir', 'dr ': 0.1 }
             center_options={ 'center' : (250, 264) } )

In https://github.com/PyAbel/PyAbel/pull/108#issuecomment-188706374, @stggh suggests that we switch to **kwargs instead. I think that this would look like:
def transform(
    IM, direction='inverse', method='three_point', center='none',
        verbose=True, symmetry_axis=None,
        use_quadrants=(True, True, True, True),
        **kwargs):

where the transform functions are called with:
AQ1 = abel_transform[method](Q1, direction=direction, **kwargs)

The problem is that the kwargs for the centering function and the transform functions are lumped together into a big mass of kwargs and when we pass **kwargs to a transform function, we are also passing additional argument. Thus, each transform function would need to be able to accept any number of keyword arguments. So, we would need to define
def basex_transform(data, nbf='auto', basis_dir='./', dr=1.0, verbose=True,
                    direction='inverse', **kwargs):

where I have added **kwargs, which serves no purpose except to collect excessive keyword arguments that get passed.
The **kwargs method has the following advantages:

Allows users to specify the arguments in a simple <parameter> = <value> syntax.

But, it has the following disadvantages compared to the dict method:

If a user supplies a keyword that is not relevant to a transform method, they should get an error. This occurs with the dict method, but does not occur with the **kwargs method.

**kwargs method requires that we include **kwargs in all functions called by the abel.transform() method. This is not really a problem, but annoying and could mask errors.

The dict method makes it explicit which arguments are being passed to which function, reducing confusion and bugs.

One compromise would be to keep the dictionaries for passing arguments to the centering and transform functions, but also to make the most useful kwargs actual keyword arguments of the abel.transform() function. For example, we are already doing this with the center='com' keyword. This is then passes to the centering function. We could do the same thing with additional keyword arguments of the transform functions that we thought were especially useful. For example, I think that all of the transform methods accept the dr=1 parameter, so perhaps we should also make this a keyword argument for the abel.transform() function.
TLDR: I think that the code will be significantly cleaner if we stick with passing dicts. The only disadvantage is that the learning curve is a little bit steeper for users. If there is a commonly used keyword argument for the transform or centering functions, it's no problem to just add it as a keyword argument for the abel.transform() function.

I like the **kwargs syntax.
Perhaps we can check it with something like:
for vk in validkwargs:
    if vk not in kwargs:
        raise ValueError()

Yes, there are ways to filter through the **kwargs. They get a little confusing. Note that the first comment on this SO post is that a dictionary should probably be used instead: http://stackoverflow.com/questions/23430248/separating-kwargs-for-different-functions

TLDR: I think that the code will be significantly cleaner if we stick with passing dicts.

This makes me lean towards the dict approach. I think we can make it work with good examples/sensible defaults.

Actually, the same technique is used to set the arrowprops in matplotlib's annotate function:
http://matplotlib.org/users/annotations_intro.html
From this, I learned that we can actually make the dict syntax prettier:
abel.transform(data, method='basex',
             transform_options=dict(basis_dir= '/Users/mydir', dr=0.1),
             center_options=dict(center =(250, 264)) )

```python`
abel.transform(data, method='basex',
transform_options = dict(basis_dir= '/Users/mydir', dr=0.1),
center_options    = dict(center=(250, 264)) )

looks nice, too

...and I guess that we could just add crop as a keyword of abel.transform, and then nobody would really need to use the `center_options

I guess that we could just add crop as a keyword of abel.transform

I realized that center was already a keyword argument of abel.transform, so the above example that I was using was a bit silly. If we have both center (which accepts a tuple for a "bespoke" center as well as str arguments to use automatic centering) and crop as keywords for abel.transform(), then there are not many other options that could potentially be passes to the center_image function. Potentially there are, and we can keep the center_options={} keyword, but if we have center and crop, then that should take care of 99% of all scenarios.

Ah, that makes a lot of sense. Yes, with center and crop as keywords, most cases are indeed covered.

I am extremely impressed with this syntax

abel.transform(data, method='basex',
transform_options = dict(basis_dir= '/Users/mydir', dr=0.1),
center_options    = dict(center=(250, 264)) )

and it appears to work. I am able to pass dict(dr=0.5) to abel.transform().
Re the centering functions in abel.tools.center.py and #103 point 4.

Yes, my thought was to have several find_center... functions that only find the center (and don't return the centered image). Actually setting the center of the image brings up the issue of cropping the image, and this should be treated consistently but the new set_center function that @ldes89150 has expanded in his PR. In summary:
tools.center.find_center() function that takes an image and calls any one of the
find_center_... functions. The center of the image can then be set with the
set_center() function.
center_image() combines the find_center and set_center functions, and is probably what most users will use.

Q: @ldes89150 (your baby), @DanHickstein, @DhrubajyotiDas (for ideas) at the moment is there a function that will return an odd size image from an even image input, recentered, without using the centering (optimization) functions?
This question comes about because I am attempting to ensure that symmetry.find_image_center_by_slice() returns only the image center coordinates/origin. However, I am not sure what function to call next to return an odd-centered image.

I think the idea was that you could call set_center(IM, center=(100,100)) and it would return an odd image. Is that not the case?

Not from what I (learner driver) can tell:
In [13]: y = np.ones((4,4))

In [14]: y
Out[14]:
array([[ 1.,  1.,  1.,  1.],
       [ 1.,  1.,  1.,  1.],
       [ 1.,  1.,  1.,  1.],
       [ 1.,  1.,  1.,  1.]])

In [22]: abel.tools.center.set_center(y, center=(1.5, 1.5))
delta = (0.5, 0.5)
Out[22]:
array([[ 0.,  0.,  0.,  0.],
       [ 0.,  1.,  1.,  1.],
       [ 0.,  1.,  1.,  1.],
       [ 0.,  1.,  1.,  1.]])

In [23]: abel.tools.center.set_center(y, center=(1.5, 1.5), crop='valid_region')
delta = (0.5, 0.5)
Out[23]:
array([[ 1.,  1.],
       [ 1.,  1.]])

I thought it is implemented in get_image_quadrants and put_image_quadrants because the iabel_ function requires the symmetry axis at first column. The get_image_quadrants can generate suitable quadrant for the transform function

If set_center is required to return an odd image, the crop = "maintain_size" would be nonsense.

No worries. PyAbel requires an easy method for the user to convert their even size (width) image to an odd size. The current Abel transforms (except onion_peeling) require the left-most pixel to be the image center-line. What is the simplest method to achieve this?
I have been using:   IMx = scipy.nidimage.interpolation.shift(IM, (-0.5, -0.5))[:-1, :-1]
Are we able to implement the same or a better function in center.py?
In principle, the image need only be centered in width.
get_image_quadrants only splits the image. Re-centering requires user choice of method, so this functionality may be better handled in center.py.

The maintain-size keyword would still make some sense, even if odd images
are returned. The function could still approximately maintain the size and
just return the closest odd sized image. I suggest that we add an
odd_size=True keyword to set_center.
On Thursday, February 25, 2016, Steve Gibson<EMAIL_ADDRESS>wrote:

No worries. PyAbel requires an easy method for the user to convert their
even size (width) image to an odd size. The current Abel transforms (except
onion_peeling) require the left-most pixel to be the image center-line.
What is the simplest method to achieve this?
I have been using: IMx = scipy.nidimage.interpolation.shift(IM, (-0.5,
-0.5))[:-1, :-1]
Are we able to implement the same or a better function in center.py?
In principle, the image need only be centered in width.
get_image_quadrants only splits the image. Re-centering requires user
choice of method, so this functionality may be better handled in center.py
.
—
Reply to this email directly or view it on GitHub
https://github.com/PyAbel/PyAbel/issues/109#issuecomment-189034505.

--
Daniel D. Hickstein
<EMAIL_ADDRESS>Phone:<PHONE_NUMBER>

It looks like this has been resolved. Closing this issue.


Forge test not handling revert with custom error

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (96ab913 2023-09-28T00:20:52.121517000Z)
What command(s) is the bug in?
forge test
Operating System
macOS (Apple Silicon)
Describe the bug
The below test fails with message: [FAIL. Reason: Call did not revert as expected].
however when the vvm.expectRevert(InvalidMember.selector); is removed the test again fails with message: [FAIL. Reason: InvalidMember()].
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import { Test } from "forge-std/Test.sol";
import { GasSnapshot } from "forge-gas-snapshot/GasSnapshot.sol";
import { Merkle } from<EMAIL_ADDRESS>import { MerkleProof } from<EMAIL_ADDRESS>import { IVotingStrategy } from "../src/interfaces/IVotingStrategy.sol";

contract MerkleWhitelistVotingStrategy is IVotingStrategy {
    error InvalidProof();
    error InvalidMember();

    struct Member {
        address addr;
        uint96 vp;
    }

    function getVotingPower(
        uint32 /* blockNumber */,
        address voter,
        bytes calldata params,
        bytes calldata userParams
    ) external pure override returns (uint256 votingPower) {
        bytes32 root = abi.decode(params, (bytes32));
        (bytes32[] memory proof, Member memory member) = abi.decode(userParams, (bytes32[], Member));

        if (member.addr != voter) revert InvalidMember();
        if (MerkleProof.verify(proof, root, keccak256(abi.encode(member))) != true) revert InvalidProof();

        return member.vp;
    }
}

contract DemoTest is Test, GasSnapshot {
    error InvalidProof();
    error InvalidMember();

    MerkleWhitelistVotingStrategy public merkleWhitelistVotingStrategy;
    Merkle public merkleLib;

    function setUp() public {
        merkleWhitelistVotingStrategy = new MerkleWhitelistVotingStrategy();
        merkleLib = new Merkle();
    }

    function testDemo() public {
        MerkleWhitelistVotingStrategy.Member[] memory members = new MerkleWhitelistVotingStrategy.Member[](4);
        members[0] = MerkleWhitelistVotingStrategy.Member(address(3), 33);
        members[1] = MerkleWhitelistVotingStrategy.Member(address(1), 11);
        members[2] = MerkleWhitelistVotingStrategy.Member(address(5), 55);
        members[3] = MerkleWhitelistVotingStrategy.Member(address(5), 77);

        bytes32[] memory leaves = new bytes32[](4);
        leaves[0] = keccak256(abi.encode(members[0]));
        leaves[1] = keccak256(abi.encode(members[1]));
        leaves[2] = keccak256(abi.encode(members[2]));
        leaves[3] = keccak256(abi.encode(members[3]));

        bytes32 root = merkleLib.getRoot(leaves);

        // Proof is for a different member than the voter address
        vm.expectRevert(InvalidMember.selector);
        merkleWhitelistVotingStrategy.getVotingPower(
            0,
            members[1].addr,
            abi.encode(root),
            abi.encode(merkleLib.getProof(leaves, 2), members[2])
        );
    }
}

thanks for flagging.
could you please prepare a repro for this so we can debug what's going on here?

Okay did some digging myself and found it works as expected if the library call is made prior to the expect revert statement. like so
        bytes32[] memory proof = merkleLib.getProof(leaves, 2);

        // Proof is for a different member than the voter address
        vm.expectRevert(InvalidMember.selector);
        merkleWhitelistVotingStrategy.getVotingPower(
            0,
            members[1].addr,
            abi.encode(root),
            abi.encode(proof, members[2])
        );

I assume what is happening is forge is expecting the first call to fail (which is the library call), then getting confused when it doesnt.

repro here: https://github.com/Orland0x/foundry-revert-issue-demo/blob/main/test/Demo.t.sol

We've added several fixes to custom error revert handling and decoding/encoding—plus, this is a common pitfall with expectRevert—when you use libraries, you have to make sure they don't get "inlined", which means wrapping them in a public function that forces solidity to make a CALL.


Once solidity-docgen links are fixed, re-publish the docs

Issue described here https://github.com/zeppelinos/zos/issues/628
This is being resolved in the solidity-docgen repo by either
https://github.com/OpenZeppelin/solidity-docgen/pull/19
or
https://github.com/OpenZeppelin/solidity-docgen/pull/20
Once that is resolved, zos/docs's solidity-docgen dependency needs to be updated, and the documentation needs to be re-published so that the links are fixed.

I've published a new version of solidity-docgen with a fix for this. Let me know how it goes!


Adds Dockerfile. Closes #1786

Closes #1786

Hey @garrytrinder, before we consider the issue closed, shall we try to integrate building and publishing the Docker image in our CI/CD so that it's done automatically on each release?

Thanks for the feedback @waldekmastykarz I did mean to mark this as draft and start these discussions, you beat me to it 😊

A couple of things that we should also consider in this image.

Run as non-root user
Remove apt lists after update
Add LABEL metadata to image

Update

Uses microsoft/powershell:latest alpine image
Adds LABEL metadata
Installs nodejs
apt lists removed to save space
Container runs as non-root user, cli-microsoft365
CLI for Microsoft 365 installed using --production to save space
Command completion for bash & PowerShell configured
Bash set as default shell, can be overridden to use PowerShell

Build
docker build --pull --rm -f "Dockerfile" -t m365pnp/cli-microsoft365:latest "." --build-arg CLI_VERSION=latest

Usage
docker run --rm -it m365pnp/cli-microsoft365:<tag>
docker run --rm -it m365pnp/cli-microsoft365:<tag> pwsh

Tags (Docker Hub)

latest
next
3.2.0
3.1.0
3.0.0

We should also include an update to the telemetry so we can track the requests made from Docker.

@waldekmastykarz added update to CI/CD, it does require environment variables for Docker username and password however.
Will look at adding the telemetry tomorrow, any preference on the environment variable name that we use? CLIMICROSOFT365_ENV=docker ?

CLIMICROSOFT365_ENV=docker is good

Apologies @waldekmastykarz really sloppy PR this one, hopefully all should be good now. I'll leave this in draft to work on a doc page as discussed.

Nah, don't worry about it. No harm done. That's why we do reviews 🙂

Added first draft of docs, I think I just need an example to cover passing ENV variables into the container for custom authentication scenarios and have a review.
@waldekmastykarz on the subject of tags published to Docker Hub, do you think generating an tag for each beta release is needed or should we just stick to next? I guess it could be useful to quickly jump to a specific beta release, but not sure if its worth flooding the tags list with. Thoughts?
I've recently updated the base image to use a python base rather than PowerShell as the image size is much smaller, so I need to build and publish the images to Docker Hub once the docs are done.

Personally, I'd say we should align with npm so that whatever you can pull from npm, you can pull from Docker Hub as well.

All tags created and pushed to Docker Hub for 3.x.x releases and beta releases.

https://hub.docker.com/repository/docker/m365pnp/cli-microsoft365/general

Thanks to @YannickRe for helping out with the testing in Azure DevOps ❤

Much appreciated as always @waldekmastykarz ❤

Looking at https://circleci.com/docs/2.0/building-docker-images/ it seems like we need to add machine: true in the job responsible for building the Docker image. Right now we build the image in the same job as publishing the package to npm. Let's break them up in two separate jobs

I had issues with machine:true, but found that we can add the docker auth info to the docker executor which is reused across all of the jobs.
Btw, I pushed the latest beta to docker hub as well, keeping everything up to date.

Just jumping in, I keep a close eye on this for my DevOps pipeline.
I noticed that my pipeline fails when using the container tagged "next" but works with the container "3.4.0-beta.4b3fe38". My only conclusion is that "next" doesn't have the same version of CLI installed as "3.4.0-beta.4b3fe38".

I had issues with machine:true, but found that we can add the docker auth info to the docker executor which is reused across all of the jobs.

@garrytrinder this is not as much about auth as about enabling the docker tools in the CI container. Were you able to verify that our updated CI pipe can produce a Docker image?

Thanks @YannickRe I re-ran the next tag build manually last night, so it may be that it was just out of date when you tested?
If you have already downloaded the image, then you either need to remove the image from your local machine using docker rmi, or update it using docker pull.

I had issues with machine:true, but found that we can add the docker auth info to the docker executor which is reused across all of the jobs.

@garrytrinder this is not as much about auth as about enabling the docker tools in the CI container. Were you able to verify that our updated CI pipe can produce a Docker image?

As we are using circleci/node base image for our pipelines, the Docker tools are already installed, so machine: true is not required. Below is a line from the docs.

Note: The CircleCI convenience images for the Docker executor come with the Docker CLI pre-installed.

Adding the setup_remote_docker step added to the docker jobs pushes the docker steps to a remote environment for the building and pushing of images. Below is a line from the docs.

Once setup_remote_docker is called, a new remote environment is created, and your primary container is configured to use it. All docker-related commands are also executed in your primary container, but building/pushing images and running containers happens in the remote Docker Engine. (line 10)

@waldekmastykarz at the moment this does need testing fully, how would I test this? Circle CI is very new to me.

@YannickRe apologies, looks like the image does not update when I re-push the :next tag after rebuilding, I expect this will be the same for :latest as well. Thanks for bringing this to my attention. I'll take a look 👍

@garrytrinder no worries! In my DevOps pipeline it redownloads the image every run (cloud hosted agent for testing), and I tested just this morning with both. Good you are seeing the version differences! Just wanted to inform you, in case the automatic process needed some tweaking :)

As we are using circleci/node base image for our pipelines, the Docker tools are already installed, so machine: true is not required. Below is a line from the docs.

This is odd, given that the last time we tried to run CI with these changes merged, it failed because it couldn't find docker 😕

@waldekmastykarz at the moment this does need testing fully, how would I test this? Circle CI is very new to me.

In the past I've tested the setup with my own repo. Not quite trivial if you ask me. If you're convinced that we have everything we need, we can also test here. You could also have a look at https://circleci.com/docs/2.0/local-cli/.

This is odd, given that the last time we tried to run CI with these changes merged, it failed because it couldn't find docker 😕

Not deny that 😁 I think it's the Docker setup step that performs the magic echo we were missing.

In the past I've tested the setup with my own repo. Not quite trivial if you ask me. If you're convinced that we have everything we need, we can also test here. You could also have a look at https://circleci.com/docs/2.0/local-cli/.

Exactly the reason I've not got round to testing it fully yet 😁 I'll take a look at the local CLI & spend some time on this later in the week.
No rush, it goes when it's ready.
Thanks for your input on this @waldekmastykarz bit of a learning curve but I'm getting there 😁

@YannickRe :next and :latest tags should now be working, turns out that when I was building locally it was still using a cached layer hence why it was not updating correctly.
Added --no-cache to the docker build command to force the rebuild.

@garrytrinder tested :next and it it works. Are :next and :latest supposed to be the same? I don't know much about Docker tagging but I expect next to be the version 'in the works' and :latest to be the latest released version of CLI (so at the time of writing, I expect to get a container with CLI 3.3.0).

@YannickRe yes that's correct :next is using @pnp/cli-microsoft365@next and :latest is using @pnp/cli-microsoft365@latest, so they are different versions.
:next -> @pnp/cli-microsoft365@next -> 3.4.0-beta.f253fd3
:latest -> @pnp/cli-microsoft365@latest -> 3.3.0
Do you see something different with :latest?

No, I haven't checked. Wrongly assumed from your previous message that you put the same version in :next and :latest. Ignore me :)

Lost in translation, sorry, I should have been clearer.
I meant that the latest tag would have the same issue as the beta tag and not updating correctly, as we don't target a specific version of the CLI in the build for those tags but rather an alias, so Docker doesn't see it as a change & so pulled from cache.


Clean up archive tags

We have some tags like machine learning and ml that are redundant. We should also just go through and figure out some proper tags because there are tags like todo list which aren't that great :')

My nominees:

async storage
await
classes (could mean many things)
components
computer science
explore
express vs. expressjs (I vote for express)
final project
functional components
functions (could mean many things)
local storage
machine learning vs. ml (I vote for machine learning)
navigation (web? android? iOS?)
props
scripting
state
stylesheet vs. stylesheets (i vote for stylesheets)
tech
todo list
ui (dup of design?)
ux (dup of design?)
views

On the other hand, I think there are also some tags we could add:

react hooks

I also recommend that we add programmatic safeguards to make sure never to re-introduce the tags we deleted: i.e., a blocklist of tags.


Improve find_anomalies primitive

Description
Update the find_anomalies primitive according to the issues mentioned in Orion:

Add overlapping threshold
Add anomalous area around an anomaly
Threshold for unusually low errors
Calculate anomaly score for overlapping or consecutive anomalies

Suggestion
Introduce new hyperparameters for the find_anomalies primitive like the following:
"hyperparameters": {
    "fixed": {
        "z_range": {
            "type": "tuple",
            "default": [
                0,
                12
            ]
        },
        "window_size": {
            "type": "int",
            "default": 2000
        },
        "window_step_size": {
            "type": "int",
            "default": 200
        },
        "lower_threshold": {
            "type": "bool",
            "default": false
        }
    },
    "tunable": {
        "min_percent": {
            "type": "float",
            "default": 0.13,
            "range": [
                0.01,
                0.9
            ]
        },
        "anomaly_interval": {
            "type": "int",
            "default": 50,
            "range": [
                0,
                400
            ]
        }
    }
}

Change the find_anomalies function, such that it supports the lower threshold and a flexible step_size for overlapping thresholds.
def find_anomalies(errors, index, z_range=(0, 10), window_size=None, window_step_size=None, min_percent=0.1,
                   anomaly_interval=50, lower_threshold=False):
    """Find sequences of values that are anomalous.
    We first find the ideal threshold for the set of errors that we have,
    and then find the sequences of values that are above this threshold.
    Lastly, we compute a score proportional to the maximum error in the
    sequence, and finally return the index pairs that correspond to
    each sequence, along with its score.
    """

    window_size = window_size or len(errors)
    window_step_size = window_step_size or len(errors)
    window_start = 0
    window_end = 0
    sequences = list()

    while window_end < len(errors):
        window_end = window_start + window_size
        window = errors[window_start:window_end]

        threshold = _find_threshold(window, z_range)
        window_sequences, max_below = _find_sequences(window, threshold, anomaly_interval)
        max_errors = _get_max_errors(window, window_sequences, max_below)
        pruned_anomalies = _prune_anomalies(max_errors, min_percent)
        window_sequences = _compute_scores(pruned_anomalies, errors, threshold, window_start)
        sequences.extend(window_sequences)

        if lower_threshold:
            # Flip errors sequence around mean
            mean = window.mean()
            inverted_window = mean - (window - mean)

            # Perform same procedure as above
            threshold = _find_threshold(inverted_window, z_range)
            window_sequences, max_below = _find_sequences(inverted_window, threshold, anomaly_interval)
            max_errors = _get_max_errors(inverted_window, window_sequences, max_below)
            pruned_anomalies = _prune_anomalies(max_errors, min_percent)
            window_sequences = _compute_scores(pruned_anomalies, errors, threshold, window_start)
            sequences.extend(window_sequences)

        window_start = window_start + window_step_size

    sequences = _merge_sequences(sequences)

    anomalies = list()
    for start, stop, score in sequences:
        anomalies.append([index[int(start)], index[int(stop)], score])

    return np.asarray(anomalies)

The _find_sequences function can be extended to add the area around anomalies to the sequences as well:
def _find_sequences(errors, epsilon, anomaly_interval):
    """Find sequences of values that are above epsilon.

    This is done following this steps:

        * create a boolean mask that indicates which values are above epsilon.
        * shift this mask by one place, filing the empty gap with a False
        * compare the shifted mask with the original one to see if there are changes.
        * Consider a sequence start any point which was true and has changed
        * Consider a sequence end any point which was false and has changed
    """
    above = pd.Series(errors > epsilon)

    # mark area around anomalies also as True
    index_above = np.argwhere(above)
    for i in index_above.flatten():
        above[max(0, i-anomaly_interval):min(i+anomaly_interval+1, len(above))] = True
    shift = above.shift(1).fillna(False)
    change = above != shift

    if above.all():
        max_below = 0
    else:
        max_below = max(errors[~above])

    index = above.index
    starts = index[above & change].tolist()
    ends = (index[~above & change] - 1).tolist()
    if len(ends) == len(starts) - 1:
        ends.append(len(above) - 1)

    return np.array([starts, ends]).T, max_below

Then we can calculate the score of a sequence with this function:
def _compute_scores(pruned_anomalies, errors, threshold, window_start):
    """Compute the score of the anomalies and add window_start timestamp to make the index absolute.
    """
    anomalies = list()
    denominator = errors.mean() + errors.std()

    for row in pruned_anomalies:
        max_error = row[2]
        score = (max_error - threshold) / denominator
        anomalies.append([row[0]+window_start, row[1]+window_start, score])

    return anomalies

The _merge_consecutive function can be changed like this to merge overlapping or consecutive sequences and calculate the anomaly score:
def _merge_sequences(sequences):
    """Merge consecutive and overlapping sequences.
    We iterate over a list of start, end, score triples and merge together
    overlapping or consecutive sequences.
    The score of a merged sequence is the average of the single scores,
    weighted by the length of the corresponding sequences.
    """

    sorted_sequences = sorted(sequences, key=lambda entry: entry[0])
    new_sequences = []
    score = list()
    weights = list()

    for i in sorted_sequences:
        if not new_sequences:
            score.append(i[2])
            weights.append(i[1] - i[0])
            new_sequences.append(i)
        else:
            j = new_sequences[-1]
            if i[0] <= j[1]+1:
                score.append(i[2])
                weights.append(i[1]-i[0])
                weighted_average = np.average(score, weights=weights)
                new_sequences[-1] = (j[0], max(j[1], i[1]), weighted_average)
            else:
                score = [i[2]]
                weights = [i[1]-i[0]]
                new_sequences.append(i)

    return np.array(new_sequences)

Closed via #181


[Q] Raspberry Pi TV HAT for DVB-C

Did anyone tried the Raspberry Pi TV HAT for DVB-C QAM256, if yes let me know so i can order and try one in India with TSDuck.

One user reported a successful use of the TV HAT here but it was with DVB-T and T2. The TV HAT product description only mentions "Supported TV standards: DVB-T2, DVB-T".


samba installed and zed running by default (even without using zfs)

Describe the bug
The other day as I was building one of my aarch64 hosts I noticed that the build was taking a long time because of samba. I was a bit confused by that because I wasn’t using samba on that host at all. Looking up the dependency tree, it looks like samba is being pulled because of zfs-user.
Looking a bit further, I also noticed that zed is running even though I’m not using zfs on this host (which we may or may not be okay with?).
Steps To Reproduce
Steps to reproduce the behavior:

Build a minimal NixOS install.

Expected behavior
I didn’t expect samba to be installed by default in a minimal NixOS install.
Additional context
I see we decided to include zfs support by default here: 6db866cbd2e90525163074788dabbb3d7374e0ba
I believe zfs might be pulling in samba because of this patch:
https://github.com/NixOS/nixpkgs/blob/64aaa351a5ec51a361a6b78f31f2ebb8778f0e7f/pkgs/os-specific/linux/zfs/default.nix#L71
If we agree that this isn’t ideal behavior, we might want to:

Make zfs not depend on samba.
Only enable zfs if any of the declared filesystems actually uses it.

Notify maintainers
@grahamc since you may have thoughts on this.

Yikes, zed should definitely not be running on machines without zfs. This seems really surprising. I don't know how to avoid pulling in samba... maybe a "light" zfs build by default.

I noticed this because zed crashes when cross-compiled to armv6l and while I do like ZFS, I haven't actually been bold enough to try zfs on a rpizero...


Pretty print ipamd JSON log for log collector

Issue #, if available:
Description of changes:
/v1/enis output with compact JSON output is hard to read when we are doing troubleshooting.
With pretty print ipamd log output with simple python3 -m json.tool
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Testing Done
Output for /v1/enis maybe too large for demo, so let's take /v1/networkutils-env-settings as sample output.
Before change
$ curl --max-time 3 --silent http://localhost:61679/v1/networkutils-env-settings
{"AWS_VPC_CNI_NODE_PORT_SUPPORT":true,"AWS_VPC_ENI_MTU":9001,"AWS_VPC_K8S_CNI_CONFIGURE_RPFILTER":false,"AWS_VPC_K8S_CNI_CONNMARK":128,"AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS":null,"AWS_VPC_K8S_CNI_EXTERNALSNAT":false,"AWS_VPC_K8S_CNI_RANDOMIZESNAT":2,"AWS_VPC_K8S_CNI_VETHPREFIX":"eni"}

After change
$ curl --max-time 3 --silent http://localhost:61679/v1/networkutils-env-settings | $(which python3) -m json.tool
{
    "AWS_VPC_CNI_NODE_PORT_SUPPORT": true,
    "AWS_VPC_ENI_MTU": 9001,
    "AWS_VPC_K8S_CNI_CONFIGURE_RPFILTER": false,
    "AWS_VPC_K8S_CNI_CONNMARK": 128,
    "AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS": null,
    "AWS_VPC_K8S_CNI_EXTERNALSNAT": false,
    "AWS_VPC_K8S_CNI_RANDOMIZESNAT": 2,
    "AWS_VPC_K8S_CNI_VETHPREFIX": "eni"
}

See this guide for recommended testing for PRs. Some tests may not apply. Completing tests and providing additional validation steps are not required, but it is recommended and may reduce review time and time to merge.

@cartermckinnon If you have time, I'd like to hear your opinion for the change here.
What you would prefer to prettify JSON? python -m json.tool? or jq ?


Font use count is 2 on exit throwing exception

Dear god....WHY WHY do you mixed shared pointers with regular pointers. You explicitly check a shared ptr use count on exit and throw an exception but WHY? The shared ptr will clean that up anyways. If its a C  pointer then there is NO reason to use a shared ptr...either way its an error. It's causing an exception on exit for me. It's the platform font shared ptr...In particular, its this that is throwing exception

Please do not do that...Just clean up in destructor which will happen with the reset call after the if
Just use a shared pointer with a custom allocator that cleans it up correctly
EDIT: I think you have a copy constructor for label class that is no good. It works fine as long as I don't pass s label to another class

It is necessary to check the use count. In X Window, all font objects should be deleted before deleting storage, otherwise it crashes.
All widgets are not copyable and moveable.

Hey Jinhao,
Its possible that there may be a copy happening somewhere that I am not
aware of.  I would recommend that you use '= delete' for copy and move
constructors/assignment operators.  That way this would be a compile error
instead of a runtime error and it may show me where the copy is happening
so that I can fix it in my code.
-Thanks,
Thomas


Add requirement for Python > 3.10

The latest version of seqrepo (>0.65) requires python >3.10, so to allow for recent changes making seqrepo thread-safe, we need to change the venv to reflect this

@quinnwai  See https://github.com/ohsu-comp-bio/vrs-python-testing/blob/2d4da85eac9eb21ac7956ba9fb6a77a13917186b/setup.py#L100
If satisfactory, please close this issue

noted, thanks! Closing issue


[SPARK-28956]Make it tighter

What changes were proposed in this pull request?
Make it tighter

Why are the changes needed?

Does this PR introduce any user-facing change?
no

How was this patch tested?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

That's not what the TODO is getting at; I think it's contemplating tighter bounds. This change is too trivial to be worthwhile.


[webapi][xwalk-3199] Update test steps for Speech API manual testing

Impacted tests(approved): new 0, update 1, delete 0
Unit test platform: [IVI]
Unit test result summary: pass 1, fail 0, block 0

@zqzhang
I have updated it following your comments


Add areas of focus to editors.md

This pull request is meant to address the subject of some debate in solid/culture#36. Since we are still crystalizing how we identify and handle substantive/non-substantive changes per solid/culture#57, I'm following the process being proposed for non-substantive changes, and issuing this pull for light editorial review. There has been general agreement that its contents are not considered substantive changes.
Note that if this is merged, any existing editor applications will also need to be updated to include proposed Areas of Focus.

Thanks, @justinwb.
No objection to the PR as such, but I think the entire notion of Editors has gone off track (https://github.com/solid/culture/pull/78#discussion_r308793192). It seems to have become a Title with a Privilege, whereas it should simply answer the question who is responsible for ensuring that a specific document is up to the right level. I might have created that confusion myself through the open wording of https://github.com/solid/specification/issues/2, but what I really mean is https://github.com/solid/specification/issues/2#issuecomment-493386464 and https://github.com/solid/specification/issues/2#issuecomment-508527862. So editor with a lowercase "e", really.
As far as I'm concerned, people are just editors of a specific document, so people's editorial duties should be scoped to the documents they are the editor of. For instance, we could just add them as editors to individual documents of https://github.com/solid/specification/ (like here https://github.com/solid/specification/blob/0036fc08145add6007f7767722193c5b34b3e1cc/main/index.bs#L10).
As it currently stands, I don't see a strong reason/motivation for myself to be on editors.md; I don't think it serves a purpose. My editorship should come from concrete actions such as https://github.com/solid/specification/pull/13, and could eventually be reflected on top of that document. I'm not in need of other privileges or duties beyond being able to contribute to that one document (or perhaps other relevant ones in the future, which I can decide on a per-document basis).
Of course, that's just my opinion, so take it with a grain of salt, but at the same time please consider it as a signal coming from the bottom up on how we'd want to work (since the process should serve us, not the other way round).

I'm :-1: on this, for reasons explained in #36. I do think that editors.md has a clear purpose, explained there, but that areas of focus is given by the panels, not the editorial board.

This pull request has been succeeded by #95. The changes included in this pull are no longer relevant, so there was no need to merge. Closing this pull request and deleting the branch.


Fixing a broken stroke width for ZoomedScene

When using ZoomedScene, incorrect stroke width behavior is observed.
I found that a special multiplier self.get_frame_width() / FRAME_WIDTH was added, which is supposed to keep the right stroke width. In fact, it introduces an incorrect behavior. See the example below:

Reproducible example:
class Test(ZoomedScene):
    CONFIG = {
        "zoom_factor": 0.4,
        "zoomed_display_height": 5,
        "zoomed_display_width": 5
    }

    def construct(self):
        zoomed_camera = self.zoomed_camera
        zoomed_display = self.zoomed_display

        title = TextMobject("Before").scale(2.5).to_corner(LEFT + UP)

        zoomed_display.display_frame.set_color(BLUE)
        zoomed_display.to_corner(RIGHT + UP, buff=0)

        circle1 = Circle(stroke_width=6).scale(0.5)
        circle2 = Circle(stroke_width=3, color=BLUE).scale(0.25)
        rect = Rectangle(height=1.25, width=2.0, color=YELLOW, stroke_width=2).next_to(circle2, LEFT, buff=0)
        dot = Dot(fill_color=BLUE, color=WHITE, stroke_width=4).scale(2).next_to(circle1, LEFT, buff=0)
        zoomed_camera.frame.next_to(rect, LEFT)

        self.add(circle1, circle2, rect, dot, title)
        self.activate_zooming()
        self.play(self.get_zoomed_display_pop_out_animation())

        zoomed_camera.frame.generate_target().move_to(circle1)
        self.play(
            MoveToTarget(zoomed_camera.frame),
            run_time=6
        )
        self.wait(2)

I understand that the author of this code fragment originally wanted to keep the thickness of the lines in ZoomedScene the same as in the original scene. First of all, I think that this is an unexpected behavior as it is normal to expect a thickening of lines when zooming objects. Secondly, the originally proposed hack does not work, because the width and height of the scenes in pixels are different, so simple multiplication by self.get_frame_width() / FRAME_WIDTH does not restore the original stroke width. If someone wants to keep this behavior, it should be made optional.

It fixes this issue #675

Additional clarifications: the old multiplier self.get_frame_width() / FRAME_WIDTH is superfluous because the zoom scale is already reflected in the get_cairo_context method by setting a new transformation matrix in L297.
P.S. I would also like to point out that line 296 with ctx.scale(pw, ph) is redundant, as the line following it sets a new transformation matrix, resetting the scale.

Make it optional something like if constant_line_width == True then ensures lines have constant width otherwise make lines looks normal.

May be add constant_line_width  in CONFIG

This would be good, however, the current design does not allow this behavior to be easily implemented (with constant line width).
Let's take a look at the reproducible example (rendered with a low quality config):

Main camera has pixel_height = 480 and frame_height = 7.994.
Zoomed display camera has pixel_height =  300 and frame_height = 2.
Width multiplier for the main camera is 480 / 7.994 = 60.04.
Width multiplier for the zoomed camera is 300 / 2 = 150.
If we multiply zoomed camera by self.get_frame_height() / FRAME_HEIGHT = 2 /  7.994 = 0.063, we'll get a new width multiplier 150 * 0.063 = 9.49, which is completely wrong.

The main problem is that the zoomed display camera does not know the width and height of the main camera in pixels. So the ratio of pixel_height/frame_height is completely different for the main camera and the zoomed camera.

The current solution, in which the stroke width is multiplied by self.get_frame_height() / FRAME_HEIGHT, is wrong and does not provide width consistency due to the reasons described above.
Width constancy can be implemented. The correct solution is to multiply stroke width in zoomed camera by zoom_factor, but to do so we have to throw zoom_factor into the zoomed camera class, which will require a change in the interface of the camera class.

Sorry, but this seems outdated, so closed this.


Enhanced gardenlet RBAC for seed bootstrapping.

How to categorize this PR?

/area security
/kind impediment
What this PR does / why we need it:
I found some RBAC issues while bootstrapping a seed from scratch (with gardenlet installed on it) in the gardener release v1.28.1. I think the same issues exist in the master branch as well.
level=error msg="Seed bootstrapping failed: failed to apply manifests: 4 errors occurred: [could not apply object of kind \"DestinationRule\" \"istio-system/default\": destinationrules.networking.istio.io \ "default\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"destinationrules\" in API group \"networking.istio.io\" in the namespace \"istio-system\", could not apply object of kind \"PeerAuthentication\" \"istio-system/default\": peerauthentications.security.istio.io \"default\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"peerauthentications\" in API group \"security.istio.io\" in the namespace \"istio-system\", could not apply object of kind \"Sidecar\" \"istio-system/default\": sidecars.networking.istio.io \"default\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"sidecars\" in API group \"networking.istio.io\" in the namespace \"istio-system\", could not apply object of kind \"ValidatingWebhookConfiguration\" \"/istiod\": validatingwebhookconfigurations.admissionregistration.k8s.io \"istiod\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"validatingwebhookconfigurations\" in API group \"admissionregistration.k8s.io\" at the cluster scope]" seed=test-aws-seed

I have enhanced the gardenlet clusterrole to get the seed bootstrapped successfully.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

Enhanced gardenlet RBAC for seed bootstrapping.

Which gardenlet feature gates are enabled and which disabled?

Which gardenlet feature gates are enabled and which disabled?

I was using the default configuration as in the gardenlet helm chart which seems to have the featureGates configuration as empty.

On start-up gardenlet log a message with the enabled and disabled feature gates, please share it.

On start-up gardenlet log a message with the enabled and disabled feature gates, please share it.

ime="2021-08-09T05:29:43Z" level=info msg="Starting Gardenlet..."
time="2021-08-09T05:29:43Z" level=info msg="Feature Gates: "

/assign
I am trying to reproduce with empty featureGates spec for gardenlet.

A related error I noticed when running with:
  ManagedIstio: false
  APIServerSNI: true

time="2021-08-09T15:43:36+02:00" level=error msg="Seed bootstrapping failed: failed to apply manifests: 3 errors occurred: [could not apply object of kind \"EnvoyFilter\" \"istio-ingress/proxy-protocol\": envoyfilters.networking.istio.io \"proxy-protocol\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"envoyfilters\" in API group \"networking.istio.io\" in the namespace \"istio-ingress\", could not apply object of kind \"Gateway\" \"istio-ingress/proxy-protocol\": gateways.networking.istio.io \"proxy-protocol\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"gateways\" in API group \"networking.istio.io\" in the namespace \"istio-ingress\", could not apply object of kind \"VirtualService\" \"istio-ingress/proxy-protocol-blackhole\": virtualservices.networking.istio.io \"proxy-protocol-blackhole\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"virtualservices\" in API group \"networking.istio.io\" in the namespace \"istio-ingress\"]" seed=gcp

A related error I noticed when running with:
  ManagedIstio: false
  APIServerSNI: true

time="2021-08-09T15:43:36+02:00" level=error msg="Seed bootstrapping failed: failed to apply manifests: 3 errors occurred: [could not apply object of kind \"EnvoyFilter\" \"istio-ingress/proxy-protocol\": envoyfilters.networking.istio.io \"proxy-protocol\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"envoyfilters\" in API group \"networking.istio.io\" in the namespace \"istio-ingress\", could not apply object of kind \"Gateway\" \"istio-ingress/proxy-protocol\": gateways.networking.istio.io \"proxy-protocol\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"gateways\" in API group \"networking.istio.io\" in the namespace \"istio-ingress\", could not apply object of kind \"VirtualService\" \"istio-ingress/proxy-protocol-blackhole\": virtualservices.networking.istio.io \"proxy-protocol-blackhole\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"virtualservices\" in API group \"networking.istio.io\" in the namespace \"istio-ingress\"]" seed=gcp

I would say this expected as APIServerSNI do require Istio to be installed in the seed cluster and it was done via external to the Gardener component, then I also expect this external component to authorize gardenlet to use it.

I would say this expected as APIServerSNI do require Istio to be installed in the seed cluster and it was done via external to the Gardener component, then I also expect this external component to authorize gardenlet to use it.

Only Gardenlet knows what permissions are required to deploy APIServerSNI, so I don't think that this is the external component's responsibility to find that out. And as these permissions evolve, they should also be maintained with the Gardenlet chart.

f you really want to fix this, you have to improve this check
https://github.com/gardener/gardener/blob/768a2a1fa9639a2b0524a00fdd1b677318d07431/charts/gardener/gardenlet/charts/runtime/templates/clusterrole-managed-istio.yaml#L1-L3
to also consider ManagedIstio as enabled by default.

@vpnachev Thanks a lot for finding the root cause and the suggestion! I can see that the feature gates defaults are initialised here. But I can't think of a good way of re-using this in the helm charts. And duplicating the defaulting in helm chart doesn't look good either. Any suggestions?

A related error I noticed when running with:
  ManagedIstio: false
  APIServerSNI: true

time="2021-08-09T15:43:36+02:00" level=error msg="Seed bootstrapping failed: failed to apply manifests: 3 errors occurred: [could not apply object of kind \"EnvoyFilter\" \"istio-ingress/proxy-protocol\": envoyfilters.networking.istio.io \"proxy-protocol\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"envoyfilters\" in API group \"networking.istio.io\" in the namespace \"istio-ingress\", could not apply object of kind \"Gateway\" \"istio-ingress/proxy-protocol\": gateways.networking.istio.io \"proxy-protocol\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"gateways\" in API group \"networking.istio.io\" in the namespace \"istio-ingress\", could not apply object of kind \"VirtualService\" \"istio-ingress/proxy-protocol-blackhole\": virtualservices.networking.istio.io \"proxy-protocol-blackhole\" is forbidden: User \"system:serviceaccount:garden:gardenlet\" cannot get resource \"virtualservices\" in API group \"networking.istio.io\" in the namespace \"istio-ingress\"]" seed=gcp

I took a deeper look into this. I believe it is due to https://github.com/gardener/gardener/blob/1ab6be7c84ba36c10a799c2e07ac07a97ccda912/pkg/operation/seed/seed.go#L752-L786 introduced with #4117.
I.e. resource from https://github.com/gardener/gardener/tree/master/charts/istio/istio-proxy-protocol are deployed/deleted depending only to the APIServerSNI feature gate. So, I would say the findings of @timuthy is different problem and permissions for this proxy-protocol chart resources needs to be added to https://github.com/gardener/gardener/blob/master/charts/gardener/gardenlet/charts/runtime/templates/clusterrole-gardenlet.yaml.

But I can't think of a good way of re-using this in the helm charts. And duplicating the defaulting in helm chart doesn't look good either. Any suggestions?

@amshuman-kr I have no better suggestion, but for sure providing gardenlet with permissions that it does not need is not a better solution. You can try to achieve enabled by default via something like
{{- define "gardenlet.managed-istio-enabled" }}
{{- if .Values.global.gardenlet.config.featureGates }}
{{- if hasKey .Values.global.gardenlet.config.featureGates "ManagedIstio" }}
{{ .Values.global.gardenlet.config.featureGates.ManagedIstio }}
{{- else }}
true
{{- end }}
{{- else }}
true
{{- end }}
{{- end -}}

but for sure providing gardenlet with permissions that it does not need is not a better solution.

Agreed. I will undo the current changes in the PR.

You can try to achieve enabled by default via something like

{{- define "gardenlet.managed-istio-enabled" }}
{{- if .Values.global.gardenlet.config.featureGates }}
{{- if hasKey .Values.global.gardenlet.config.featureGates "ManagedIstio" }}
{{ .Values.global.gardenlet.config.featureGates.ManagedIstio }}
{{- else }}
true
{{- end }}
{{- else }}
true
{{- end }}
{{- end -}}

This is what I meant by duplication of defaulting. If the defaults change then it might have to be changed in two places. If this is OK, I will make change (along with undoing the current changes).

This is what I meant by duplication of defaulting. If the defaults change then it might have to be changed in two places. If this is OK, I will make change (along with undoing the current changes).

I don't see how it can be avoided. The default must be defined in the golang code as gardenlet can be deployed via other means. The chart does not necessary have access to the source code, so it cannot evaluate during rendering time if a feature gate is enabled or not. The reverse is also valid, the golang code does  not necessarily have access to the charts to initialize the defaulting from there. Therefore I don't think duplication can be avoided. I might be wrong and missing a solution how it can be implemented only once, do you have some ideas?

Therefore I don't think duplication can be avoided. I might be wrong and missing a solution how it can be implemented only once, do you have any ideas?

Yes. I don't see any way how the duplication can be avoided. I will make the change as you suggested.

@vpnachev I thought that it might be simpler to default the feature gates in the values.yaml. I have made the changes. Can you PTAL?

Sorry, but this does not work as different values file can be provided and there this defaulting might not be reflected.
Please take a look at https://github.com/gardener/gardener/pull/4494/commits/077071b57081ace742af7157d4e87d19602c6589 where I propose same change but for the APIServerSNI feature gate.

Sorry, but this does not work as different values file can be provided and there this defaulting might not be reflected.
Please take a look at 077071b where I propose same change but for the APIServerSNI feature gate.

I have made the changes as you suggested. I have based this PR on #4494 because I wanted to add the template definition ardenlet.managed-istio-enabled in the file charts/gardener/gardenlet/charts/runtime/templates/_feature-gates.tpl which was introduced in #4494.
I will rebase this PR after #4494 is merged.

/needs rebase

/needs rebase

Done in https://github.com/gardener/gardener/pull/4481#event-5166774000

You need to trim the leading and trailing white spaces in the template.

Thanks @vpnachev. I have applied your suggestions.


Allow all index types

We previously restricted users to BTREE indexes, and then added hash indexes since Postgres 10 made them WAL-replicated and crash safe. But actually hash indexes were the only index type to lack crash safety anyway; so now the restriction is wholly redundant.

I've tagged core infra in case one of you lot knows something I don't!


Add start/stop button for saving process/memory period histoy by filter

easier for performance analysis

F6 already starts/stops the interval updates?

the current version only can save a snapshot of process/memory.If process hacker can save a period time of process/memory should be better.

Period related logging is outside the scope for this tool. You should use ETW/Xperf for logging process/memory related data.


[WIP] tmate.io webhook integration

Tmate.io is a tool to be able to do pair programming. It opens an ssh session that two or more people can connect to.
This integration allows for the life of the sessions to be informed in a channel and a topic, and to be able to join them from the chat.
Testing plan:
Have used all the webhooks documented in https://github.com/tmate-io/tmate/wiki/Webhooks
This is how it works: https://youtu.be/S4FDmnjigdE

I am having an issue that I wanted to circulate by you all, that is that when I enable the bot in my zulip instance, all messages get to the private chat in between who sets up the bot and the bot (instead of the channel that it is supposed to be sending the messages to)... Any guidance?
Thanks for making it so easy to build integrations!

I am having an issue that I wanted to circulate by you all, that is that when I enable the bot in my zulip instance, all messages get to the private chat in between who sets up the bot and the bot (instead of the channel that it is supposed to be sending the messages to)... Any guidance?
Thanks for making it so easy to build integrations!

Yes indeed, it is a WIP, but wanted to share the work to get it healthy for joining the repo.
Thanks for the review.

Yes indeed, it is a WIP, but wanted to share the work to get it healthy for joining the repo.
Thanks for the review.


Upgrade Theia dependency to 1.29.0

Currently theia-trace-extenison is using version 1.21.0 of @theia/cli.
This pull request upgrades this dependency to the lastest one available,
1.29.0.
The version of NodeJS used by the extension (12.14.1) was no longer
accepted by Theia, so it is being upgraded to 16.16.0.
Signed-off-by: Rodrigo Pinto<EMAIL_ADDRESS>

Addendum: the above CI failures are likely caused by yarn.lock, which needs to be updated locally first (then pushed herein).

@hriday-panchasara, I cannot add you as Reviewer in here, but feel free to share your perspective; thanks.

Beside these latest yet minor comments, some views for me don't render as expected locally; e.g., Overview -as well as some others. Do they, for you?

They do not. I believe they are failing due to the changes I did in the "Typescript adjustments for React 18" commit, which were made to fix new compiler's errors coming from @types/react 18. I'll be looking into different ways to resolve those, perhaps making use of suggestions from the team.

It took a tenuous investigation, but we found the culprit! @hriday-panchasara (brilliantly!) spotted a change in the way state was being updated in trace-explorer-opened-traces-widget.tsx. It's caused by React's new automatic batching feature, and we adapted accordingly.
Thank you, Hriday!

Beside these latest yet minor comments, some views for me don't render as expected locally; e.g., Overview -as well as some others. Do they, for you?

They do not. I believe they are failing due to the changes I did in the "Typescript adjustments for React 18" commit, which were made to fix new compiler's errors coming from @types/react 18. I'll be looking into different ways to resolve those, perhaps making use of suggestions from the team.

It took a tenuous investigation, but we found the culprit! @hriday-panchasara (brilliantly!) spotted a change in the way state was being updated in trace-explorer-opened-traces-widget.tsx. It's caused by React's new automatic batching feature, and we adapted accordingly.
Thank you, Hriday!

Cool. I tested again now and these views for me are empty with the kernel test trace:

Histogram
IRQ Analysis - Latency vs Time
System Call Latency (Latency vs Time)

Beside these latest yet minor comments, some views for me don't render as expected locally; e.g., Overview -as well as some others. Do they, for you?

They do not. I believe they are failing due to the changes I did in the "Typescript adjustments for React 18" commit, which were made to fix new compiler's errors coming from @types/react 18. I'll be looking into different ways to resolve those, perhaps making use of suggestions from the team.

It took a tenuous investigation, but we found the culprit! @hriday-panchasara (brilliantly!) spotted a change in the way state was being updated in trace-explorer-opened-traces-widget.tsx. It's caused by React's new automatic batching feature, and we adapted accordingly.
Thank you, Hriday!

Cool. I tested again now and these views for me are empty with the kernel test trace:

Histogram
IRQ Analysis - Latency vs Time
System Call Latency (Latency vs Time)

Great catch, Marco! They were all caused by the same issue. Fixed.

Thanks for the upgrade PR!
I found a issues:

View menu is not rendered (e.g. events table, data trees)
Events table sync (see comment in table-output-component)

Due the menu bug, I was not able to test the commands of these menus

Indeed.

View menu: the event listeners were being triggered immediately upon creation, maybe due to the new way React updates the state. I had to add a timeout to avoid bubbling;
getColumns: fixed with  flushSync, as explained above.

It's happening consistently. It's happening when the table shows events closer to the end of the trace. I set a breakpoint in onEventClick(), and when it fails it's not called. I'm not able to pin-point why the event handler is not called in this case. Any ideas?

It's happening consistently. It's happening when the table shows events closer to the end of the trace. I set a breakpoint in onEventClick(), and when it fails it's not called. I'm not able to pin-point why the event handler is not called in this case. Any ideas?

Apparently the new versions of AG Grid (I'm not sure when it started) have a new way to deal with the number of rows. When it's too big, scrolling, hovering and row selection stop working.
https://www.ag-grid.com/javascript-data-grid/massive-row-count/#:~:text=This means in theory only 320%2C000 rows can get displayed.
They have an example on that page, a table with 1 million rows. If you scroll to the bottom of the table (~ after row 500,000) you will see the same problems we have.
Back in theia-trace-extension, if you use rowHeight={20} as an option of AgGridReact in renderMainArea, you will see that all rows work well. But if we had more rows, the problem would eventually happen again.
Even pagination doesn't solve the problem. We already apply it by retrieving a few hundred rows per time. The problem is the index of the rows, the index used for scrolling the page. Even with version 28.2.0 of ag-grid, released 3 hours ago, the problem is still there.

Proposed a solution that uses Ag-grid's pagination.

The time sync is working now as well as the menus and its features. Thanks! However I found an issue that the table sometimes looses the ability to select an event by clicking. It happens after clicking outside the current window in the histogram (for example) and the table has to load new data. It doesn't happen all the time, but often. Could you please look into it?

It happens indeed, as described on the last comments. Added change of pages when clicking on the next / previous search button.


Converting @jonas txref to txid results in "computing…"

From @ChristopherA on July 15, 2017 21:47
@jonasschnelli publishes his TX1 enrollment in his twitter at: https://twitter.com/jonasschnelli which is tx1-rk63-uvxf-9pqc-sy
If you put this into the playground's txref field, and click on convert, the txid field says "computing…".
Two bugs: it didn't reverse this function, and it stopped rather than reporting an error.
Copied from original issue: WebOfTrustInfo/txref-conversion-js#5

From @ChristopherA on July 15, 2017 21:54
I thought maybe my error was that I had not clicked on "mainnet" checkbox when I tried to reverse jonas' tx1. However, this didn't work.

Fixed error handling; now at least displays failure message. Looking into Jonas's tx

I noticed the decoding step worked, but we are hitting API limits. As a temporary workaround (before we have more explorer APIs) I can break up the processing to display incremental progress, e.g. height and index so that someone can use another explorer

I made the above change so at least the block height and index are available. The API limits are very strict, so I created an issue to use more blockchain explorers: https://github.com/WebOfTrustInfo/txref-conversion-js/issues/7


Fix handling of Any resource name

Moves logic for creating FieldConfig objects with resource names out of PageStreamingConfig and PathTemplateTransformer, and into the FieldConfig static factory methods.
Updates C# to use IResourceName instead of ResourceName
Fixes some error handling

Current coverage is 83.25% (diff: 55.55%)

Merging #800 into master will decrease coverage by 0.04%

@@             master       #800   diff @@
==========================================
  Files           314        314
  Lines         11925      11919     -6
  Methods           0          0
  Messages          0          0
  Branches       1567       1564     -3
==========================================
- Hits           9933       9923    -10
- Misses         1562       1569     +7
+ Partials        430        427     -3

Powered by Codecov. Last update a60f225...1e389fa


Clear cache

I think this solves #813 and adds a useful event form:submit.parsley.
@guillaumepotier what do you think?

Hi,
Yes that seems great, especially the interruptible submit event!
Good to me


Emoji icons are not loaded in the documentation

If you take a look on the page https://sonataflow.org/serverlessworkflow/main/core/cncf-serverless-workflow-specification-support.html, the emoji icons are not loaded.

@tomasdavidorg can you send a PR to solve it?

@ricardozanini I or @barboras7 will take a look. For now I will assign it to myself.


ISPN-13019 Distributed security realm

https://issues.redhat.com/browse/ISPN-13019

Fixed

This is now ready

Rebased.

Integrated into main, thanks @tristantarrant !


NTR contractile ring sliding during vegetative growth

contractile ring sliding during vegetative growth
def
...contractile ring forms at the medial position, but subsequently slides to an off-centre location?
PMID:28784611
based on comment in feedback form
background
We next addressed how off-center septa arise in efr3Δ. Because septum position is dictated by CR position (Marks and Hyams, 1985; Marks et al., 1986), we reasoned that either the CR forms off-center or it slides from its original medial posi- tion. To distinguish between these possibilities, we imaged WT and efr3Δ expressing CR (Rlc1-GFP) and spindle pole body (Sid4-GFP) markers. In WT, the CR formed in the cell center and maintained this position during cytokinesis (Fig. 2 A). In efr3Δ, the CR formed in the cell center but slid from its orig- inal position while remaining perpendicular to the cell’s long axis (Fig. 2, A–C).
has_output  misplaced
mislocalized septum during vegetative growth
I always forget how has_output works...

descendent of
actomyosin contractile ring displaced from midpoint

maybe
actomyosin contractile ring displaced from midpoint
means it moves from the midpoint, but that didn't come across to me from def...

also normal GO:1903486

In #2551 I added this for PMID:26132084 / 80b382d361649949:
[Term]
id: FYPO:0005289
name: abnormal maintenance of mitotic actomyosin contractile ring localization
def: "A cellular process phenotype observed in the vegetative growth phase of the life cycle in which the maintenance of the mitotic actomyosin contractile ring in the correct location is abnormal." [GO:0032189, GO:1903474, PMID:26132084, PomBase:mah]
synonym: "abnormal cytokinetic ring anchoring involved in mitotic cell cycle" RELATED [GO:1903474]
[loads of other synonyms]
synonym: "actomyosin contractile ring sliding" RELATED [PMID:26132084]
is_a: FYPO:0000033 ! abnormal actomyosin contractile ring localization
Will that still do? It's what I came up with after looking at PMID:26132084, and sounds like it fits the comment in the newer session.
It was a while ago, but it was from one of the times we had a push through the outstanding term requests in Canto sessions. This one actually came from the text they put in one or two of their GO term requests. I emailed to suggest using the FYPO terms I'd added, but didn't hear back (and the session is still "curation in progress".
If abnormal maintenance of ring location only ever manifests itself as ring sliding, I could make that synonym EXACT, which should make it a bit easier to find the term.

Yes I think that is fine. That's the term. I also mailed Pilar & current curator about this session last night because the one I am approving here refers to it.
I think abnormal maintenance always manifests as sliding in FY (at least so far, and I can't think of any other possibility). The other types of abnormal location all involve making the ring in the incorrect place at the onset.
Could
actomyosin contractile ring sliding
be the primary name. It's easer for users to interpret this phenotype (curating, and on the page)
with
abnormal maintenance of mitotic actomyosin contractile ring localization
exact.

oh, can it also be a descendant of
FYPO:0002026 | actomyosin contractile ring displaced from midpoint

Hmm, can't do is_a because FYPO:0002026 is in the structure-looks-wrong department, not the process-gone-wrong branch. If the sliding always ends up with the ring in the wrong place, I could do FYPO:0005289 (synonym: ring sliding) has_output FYPO:0002026 (displaced ring). Is that true, i.e. the ring never winds up in the right place after it slides around for a while?

no it goes off in one direction or the other if the membrane attachment is compromised because of microtubule pushing forces, but it doesn't 'float around'.
how would that look in canto?
we want them to use the sliding term to  say "we know how it ends up in the wrong place'
rather than just "the ring is in the incorrect place"
but we want annotations from
FYPO:0005289 (synonym: ring sliding
to propagate to
FYPO:0002026 (displaced ring)

So far, I have added the link
abnormal septum site selection (FYPO:0002154) output_of abnormal actomyosin contractile ring localization (FYPO:0000033)

but I wonder whether we even need FYPO:0002154, or if it could merge into mislocalized septum during vegetative growth (FYPO:0000339)? The merged term wouldn't have any logical-def links to a GO process term itself, but would keep the output_of FYPO:0000033 link.
In any case, more tomorrow ...

I've swapped name and synonym for FYPO:0005289, and added the link FYPO:0005289 has_output FYPO:0002026. The link says that if the contractile ring slides, it always ends up mislocalized.
edit file: c2e8a55f2b92bbd01270836b356bad8012ac4cb4
release: f0e7b733bfe262ef76c33e5ab9f3541926760b49

but I wonder whether we even need FYPO:0002154, or if it could merge into mislocalized septum during vegetative growth (FYPO:0000339)?

yes I think probably so....
The septum site is always based on contractile ring location.

3110
merge done
also spotted additional term request in comment above, so:
normal establishment of actomyosin contractile ring localization FYPO:0006216
think that's everything ...
edit file: a16a9a024893b3b63a7b4ebe0d51f1fc415fa21d
release: ff262e82c8f3b9d1f2af188e2d0fb6462ee50e65


[Adaptive] [DCR] Provide property for consultation opt-in on all inputs

At the moment, only TextInput participates in consultation and it is on by default. However we should formalize this and do two things -

Turn consultation off by default on all inputs
Provide a 'consultation' property on all inputs that can be set to true/ false.

What would the input do to influence interruption? It either recognizes the input or it doesnt. Are you wanting a way to turn off "should process" behavior?

#2087


Support append for hdfs

Implement append for hdfs so that users can call append on hdfs services.

cc @Xuanwo

Implement append for hdfs so that users can call append on hdfs services.

@Xuanwo Do I need to consider the issue of establishing a connection with HDFS in this feature?

Capability is not enabled.

Capability is not enabled.

Would you like to help send a PR for this?


Retail Cloud Scale Unit

There is little to no information available on the docs website on setting up the Retail Cloud Scale Unit. Can this also be covered in the upcoming docs updates?

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

ID: 0e22c3ec-f761-f9fe-0dae-2e3f45779301
Version Independent ID: a2e0f995-5ecf-2544-cf88-f6b441a512bd
Content: Retail for IT pros and developers home page - Retail | Dynamics 365
Content Source: articles/retail/dev-itpro/dev-retail-home-page.md
Service: dynamics-365-retail
GitHub Login: @RobinARH
Microsoft Alias: robinr

Thank you for your comment. We're currently working on the documentation for Retail Cloud Scale Unit and will publish it as soon as we can.

Bug 269637 is tracking this issue.

We're closing this issue as resolved, thank you!


Fix Name of xml report tests

The class name of the test didn't match with the class that it tested. Probably we changed the name of this class at some point but we forget to change the test.

Warnings

:warning:
This PR is approved with no milestone set. If merged, it won't appear in the detekt release notes.

  Generated by :no_entry_sign: dangerJS against 8ff8de686f30638a923cc6ef8478fc19582b38c0


lazy loading has been completed for all routes.

Fixes #
Issue:-
Update the file app.router.ts to change the component fields of the routes to loadComponent.
Description
[app.router.ts]The  component fields of the routes to loadComponent has been done.
Screenshots

@anantrajjj Please read issue #2 first.
Thanks for your interest.

I just wanted to prepare for the actual hacktoberfest before the real thing, can it be considered for it too?

I wanted to prepare for the hacktoberfest beforehand, so i tried this project . If it could be considered for hacktoberfest, could you please review and merge if it meets the requirement.

@anantrajjj
I understand, but in the incident I mentioned earlier, I indicated that please wait for the incidents to be assigned before creating them and also in this case, for the event, not to create them ahead of time.
And if I check the PR and it seems correct. But you have to comment on the incident so that it can be assigned to you.
Tomorrow I will open the incidents.
I will try to create more and make them easy to help everyone.


Why don't .col-push-* and .col-pull-* use the flexbox order CSS property?

Hello
I was wondering why when using flex box you don't use "order" to re-arrange the columns?
Thanks

I'm not sure pull/push can be expressed in terms of order, since order seems to be absolute ("this is the Xth item") whereas push/pull are relative ("move this item over X columns from its normal position").

I have the following structure .content, .sidebar-primary, .sidebar-secondary and like to have three layouts: .content-sidebar-sidebar, .sidebar-sidebar-content, and .sidebar-content-sidebar - in this scenario, using order is ideal I think

How about adding .col-{size}-position-{n} to complement the offsets, pushes, and pulls?

Agree with @cvrebert, this is fundamentally different.
I made something along the lines of @MichaelRushton is proposing, but I did:
.order-{breakpoint}-{n}
I wrote up some docs and described it as 'weighting' the columns, heavier weights appear last.
I ended up abandoning this approach because for the project I'm on we're preferring to stay closer to Bootstrap for the 'people know it' reason. I was also prefacing all my layout classes with l-. You can find my stab at it here:
https://github.com/backdrop-contrib/basis/blob/master/css/grid-system/flexbox-grid.css#L1587-L1802
If I redid it I'd probably do -4 through 4, instead of 1-5.

It feels a lot better than push or pull, but if you fallback to floats on older browsers the layout order will go back to source order.

Sticking with the current solution for now given the feedback on order.

Could you update the documentation page?

Hosted docs site get updated with each release, not every push.

The order-[num] classes d'nt work for me.


update travis encrypted data

This project uses semver, please check the scope of this pr:

[ ] #none# - documentation fixes and/or test additions
[x] #patch# - backwards-compatible bug fix
[ ] #minor# - adding functionality in a backwards-compatible manner
[ ] #major# - incompatible API change

CHANGELOG

Update travis encrypted data

Visual Acceptance tests:
New
Electron: Simple

Electron: Error

Electron: svg

Electron: svg-experimental

Electron: capture right

Electron: fixed

Electron: fixed-more

Visual Acceptance tests:
No changes

Visual Acceptance tests:
Changed
Chrome: Error
Diff:

Current:

Baseline:

Visual Acceptance tests:
Changed
Chrome: Error
     Diff Current Baseline


[mvt] remove geo processing functions from encoder

The mvt package currently has geoprocessing functions (i.e. simplification, clipping, make valid, etc.) coupled inside the encoder. These functions should be moved out of the mvt package so it can focus only on encoding

This is a dupe of #224