Multiple IDP Support in Supervisor for different pools of users accessing same cluster

Ability for Pinniped Supervisor to support federating access to Kubernetes cluster(s) (single/multiple) for users from Multiple Identity providers.
Details in Additional Context below.
**Is your feature request related to a problem? Please describe.**Yes
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
Deploying multiple Supervisor instances as a stop gap solution
Are you considering submitting a PR for this feature?

How will this project improvement be tested?
How does this change the current architecture?
How will this change be backwards compatible?
How will this feature be documented?

Additional context
Context
A cluster administrator trying to configure and setup authentication to multiple kubernetes clusters has to deal with many challenges including the need to configure Identities from multiple Identity providers. For instance, there maybe a need to provide cluster access for a set of platform admins who can configure the cluster and then allow access to developer/testers using a different identity provider. There may also be a need to have separate Identity providers for users and service accounts. It might also be that an organization will need to setup same identity providers with different configurations for OIDC such as with and without password grant flow.
Currently the Pinniped Supervisor only supports working with a single Identity provider. Admins can work around this by using Identity providers such as Dex or Okta that can have multiple connectors for supporting multiple Identity sources. This however adds complexity to the deployment and makes it difficult to support the usecases for the cluster administrator.
Notes:

Transformations include: Filtering which is removing certain Usernames and Groups defined by Identity Provider,  Altering user names as well as group names, Policy for allowing or disallowing users and groups.
IDPs/IDP refer to the actual Identify Providers that handle Identity management for Users and not the IDP Custom Resource created in Pinniped.

Goals
The purpose of this feature is to add support in the Pinniped Supervisor to configure multiple identity providers. This should include support for:

Single Identity provider with multiple different configurations
Multiple identity provider configurations (>1 IDPs)
Ability to handle overlapping identities from two or more IDPs. For e.g An organization may have a Developer called “Mo” who uses GitHub and also has a GitLab account. Mo should be able to access the cluster using either of the identities and it should be known which identity Mo is using for a cluster at a given time. Additionally, this feature should also support handling of overlapping Group names from different IDPs.

Non Goals

There may be Identity transforms(For e.g. Filtering, Altering or applying Policy to group names or usernames) that can be applied to the Identities we get from the providers such as the ability to add upcasing/downcasing of usernames and groups or the ability to add users in groups before giving cluster access. These are not currently in scope of the work to support Multiple Identity providers and can be reviewed and added at a later time based on feedback from users.
Changes to ActiveDirectoryIdentityProvider, LDAPDirectoryIdentityProvider, OIDCIdentityProvider CRD Spec Schemas are not in scope

Use cases

Some organizations might keep their administrator accounts in one IDP with regular user accounts in another IDP
An administrator might like to allow human users to log in via OIDC with two-factor authentication, while allowing only non-human service accounts from LDAP (or OIDC password grant) to authenticate for CI/CD use cases.
Support configuring OIDC clients differently for different types of user or for different clusters, we need to allow multiple OIDCIdentityProviders. For example, two-factor auth is required for admins but not for deployment service accounts.
Support configuring LDAP clients differently for human accounts and service accounts in different branches of the LDAP tree When using AD or LDAP as your upstream IDP, each LDAPIdentityProvider or ActiveDirectoryIdentityProvider can only have one user search base.

This story needs to be expanded with what the expectations are around the isolation of identities (if any) from these different sources.

Isolation/tenancy is per IDP Client app.

Ability for the Pinniped Supervisor to federate access to a single Kubernetes cluster for users from multiple identity providers.

Why a single Kubernetes cluster?  Pinniped is all about multi-cluster auth?

A managed service provider could create a FederationDomain for each customer (potentially attached to each customer’s own IDP), to configure auth separately for each customer’s clusters.

I thought this was explicitly out of scope because a single supervisor process does not provide sufficient security/DOS isolation between federation domains (all keys held in memory, all sessions held in memory, etc).

I believe the answer is "no" to this particular use case, but I wanted to ask/record it here:
Sometimes admins need to combine multiple IDPs into a single IDP, i.e. they want to use one IDP to get username information and a different IDP/SCIM to get the group information.  For example, they may want users to login via OIDC and have groups synced in from LDAP.  Note that this is the only way to to configure IDPs in OpenShift, and Rancher has a similar approach.

Ability for the Pinniped Supervisor to federate access to a single Kubernetes cluster for users from multiple identity providers.
Why a single Kubernetes cluster? Pinniped is all about multi-cluster auth?
[AT] @enj Yes absolutely it is a multi-cluster use case. It maybe the framing but what I am trying to convey is that admin should be able to configure access for 'a cluster' as well as for 'multiple clusters' from different Identity providers. I will make the change in the wording above. Thanks!

A managed service provider could create a FederationDomain for each customer (potentially attached to each customer’s own IDP), to configure auth separately for each customer’s clusters.
I thought this was explicitly out of scope because a single supervisor process does not provide sufficient security/DOS isolation between federation domains (all keys held in memory, all sessions held in memory, etc).
@enj In that case I am okay to move this for post MVP work.

Ability to configure different search bases in the same IDP as separate IDPs, for example different domains across an AD forest. This feature capability should be handled at the IDP level.

We already get this for free if we support Multiple identity provider configurations (>1 IDPs). I'm not sure what it means for it to be a non-goal.

Ability to configure different search bases in the same IDP as separate IDPs, for example different domains across an AD forest. This feature capability should be handled at the IDP level.

We already get this for free if we support Multiple identity provider configurations (>1 IDPs). I'm not sure what it means for it to be a non-goal.

@margocrawf I believe @enj had mentioned that this type of use case is best handled at IDP level vs adding anything specific in our design to handle this scenario. If Multiple IDP MVP can cover this use case, that is great but it is a non-goal.

Can we specify how exactly we want to accomplish this goal:

Ability to handle overlapping identities from two or more IDPs. For e.g An organization may have a Developer called “Mo” who uses GitHub and also has a GitLab account. Mo should be able to access the cluster using either of the identities and it should be known which identity Mo is using for a cluster at a given time.

Since this is a non-goal

There may be additional Identity transforms that can be applied to the Identities we get from the providers such as the ability to add upcasing/downcasing of usernames and groups or the ability to add users in groups before giving cluster access. These are not currently in scope of the work to support Multiple Identity providers and can be reviewed and added at a later time based on feedback from users.

Should our manner of handling overlapping identities be a prefix, suffix, or something else?
Also is filtering (e.g. only the Gitlab users in this specific group are allowed to log in) a goal or non-goal and can it be added to the appropriate section on this issue? (I think we came to a decision about this but I can't remember what it was...)

I feel this is a design discussion on how to handle keeping the identities separate from the two IDPs.

I have some questions and thoughts regarding this one requirement from above:

Ability to handle overlapping identities from two or more IDPs.

My understanding from other discussions is that @anjaltelang would prefer if we could somehow automatically always make it impossible for usernames and group names to conflict when there are multiple IDPs configured.
Some related background:

Kubernetes identities are username strings with an optional list of group name strings. They do not need to be declared in advance in any database or CR or anywhere else in the Kubernetes cluster.
Pinniped pulls identities from external OIDC providers, LDAP providers, and Active Directory providers (via LDAP). Pinniped allows the admin user to configure how usernames are extracted from these providers. Usernames can be email addresses, user IDs, employee numbers, UIDs, or anything else that the admin user would like to configure. Group names can also be extracted from the external IDP in several different ways as configured by the admin user, and each group can have any UTF-8 name as extracted from the external IDP without restriction on characters, length, etc.
Pinniped cannot know about all usernames or all group names from an external IDP in advance. Even if it had some way to query them (which it does not have in the case of OIDC IDPs) then it still could not predict what usernames or group names might be dynamically added/removed/changed in the future.
The usernames and group names will partly determine how the admin writes their RBAC policies. Pinniped has no opinion on how RBAC is configured, and Pinniped's only goal in this regard is to make it possible to refer to usernames and group names as they were configured for extraction from the external IDP. For example, if an enterprise decides that usernames should be email addresses so they can automatically define/synchronize RBAC policy based on corporate email addresses, then Pinniped should allow that.
The usernames and group names extracted from the IDP also appear in audit logs and other places in the Kubernetes cluster.

Let's say there are two external IDPs configured. Let's call the IDPs "A" and "B".

Then it is possible there is a user named "ryan" in both, and that there is a group called "admins" in both. Even if the "ryan" user or the "admins" group isn't currently defined in both, then they could be added at any moment.
To make conflicts impossible, I think Pinniped would need to modify all usernames and all group names from both IDPs in some way that guarantees that they are put into separate logical namespaces. Or am I missing something? For example, Pinniped could prefix all usernames and group names from IDP A with "A:" and similarly prefix all usernames and group names from IDP "B" with "B:". (Prefixing is not the only option, but somehow the strings need to be changed, so I'll use prefixing as an example of how Pinniped could work.)
I think it is not sufficient to only prefix names from one of the IDPs. For example, if Pinniped only prefixed names from IDP A, without changing names from IDP B, then someone could create a user in IDP B called "A:ryan" which would conflict with the user "ryan" from IDP A after Pinniped applied the "A:" prefix to that identity.

The problem that I'm pointing out here:

It seems to me that the reality of what it takes to automatically make identity conflicts impossible goes against another design goal of Pinniped: admin users should be able to configure what the usernames and group names look like, so that they can retain control over how usernames and group names appear in audit logs, RBAC policies, etc.
For example, if Pinniped automatically prefixed all usernames from IDP A with "A:", then it would be impossible for the admin user to define RBAC policies based on corporate email addresses, since usernames would be automatically modified to look like<EMAIL_ADDRESS>Or am I missing another possible way to avoid potential conflicts?

Here's a modest proposal to change the MVP requirements. Pinniped could:

Make it easy for an admin to configure Pinniped with multiple IDPs such that identity conflicts are impossible in a way that lets them control the resulting names. For example, by letting them configure username and/or group name prefixes per IDP, or something similar.
Maybe even make conflict avoidance the default behavior when it is not specifically configured otherwise. For example, by automatically prefixing all usernames and group names with the name/type of the IDP when no other prefix is configured, or something similar.
Make it possible for the admin to configure Pinniped such that usernames and/or group names from certain IDPs are not changed by Pinniped. For example, letting them disable prefixing for usernames and/or group names on certain IDP(s), or something similar. This opens up the possibility of identity conflict between IDPs, but there are many cases where the admin has more knowledge about the actual possibility of conflict in practice (or lack of possibility) than Pinniped could assume, because they have detailed knowledge of the actual IDPs that they are configuring. Indeed we're already trusting the admin user to configure the OIDCIdentityProvider, LDAPIdentityProvider, or ActiveDirectoryIdentityProvider to extract usernames and group names in such a way that they are unique, which is not guaranteed by Pinniped itself.

Any thoughts @anjaltelang @margocrawf @enj @shamus, or anyone else?

Ability to handle overlapping identities from two or more IDPs.

My understanding from other discussions is that @anjaltelang would prefer if we could somehow automatically always make it impossible for usernames and group names to conflict when there are multiple IDPs configured.

+1

* The usernames and group names will partly determine how the admin writes their RBAC policies. Pinniped has no opinion on how RBAC is configured, and Pinniped's only goal in this regard is to make it possible to refer to usernames and group names as they were configured for extraction from the external IDP. For example, if an enterprise decides that usernames should be email addresses so they can automatically define/synchronize RBAC policy based on corporate email addresses, then Pinniped should allow that.

In my experience the specific strings used matter very little to admins, they just need to be predictable so that automation can be written to handle them.  Security conscious admins assign RBAC to group UUIDs and forgo any username based RBAC policies (Azure AD does this by default IIRC).

* To make conflicts impossible, I think Pinniped would need to modify all usernames and all group names from both IDPs in some way that guarantees that they are put into separate logical namespaces. Or am I missing something? For example, Pinniped could prefix all usernames and group names from IDP A with "A:" and similarly prefix all usernames and group names from IDP "B" with "B:".

(Lets assume that prefixing is the approach we want to take)
A simple approach to handle this is to disallow : in all usernames and filter out all groups with a : in their name (OpenShift always did this and it was never an issue for customers).  The first IDP's usernames are left unmodified and the second is automatically prefixed with a string that ends in a :.

* I think it is not sufficient to only prefix names from one of the IDPs.

See above.

* It seems to me that the reality of what it takes to automatically make identity conflicts impossible goes against another design goal of Pinniped: admin users should be able to configure what the usernames and group names look like, so that they can retain control over how usernames and group names appear in audit logs, RBAC policies, etc.

I think as long as usernames are understandable by a human (for the purpose of audit logs) and groups named are predictable, admins have everything they need.
For example, Rancher generates UIDs for both usernames and group names and uses these to assign RBAC policies.  The admin assigns policy through an interface, and the system handles the mapping.  The extra field of the user info is used to include the human readable username for the purpose of audit logs.

* For example, if Pinniped automatically prefixed all usernames from IDP A with "A:", then it would be impossible for the admin user to define RBAC policies based on corporate email addresses

I do not believe automation around RBAC would have any harder time with a:email vs email.  I also think the approach I described below handles this case well.

* Make it easy for an admin to configure Pinniped with multiple IDPs such that identity conflicts are impossible in a way that lets them control the resulting names.
* Maybe even make conflict avoidance the default behavior when it is not specifically configured otherwise. For example, by automatically prefixing all usernames and group names with the name/type of the IDP when no other prefix is configured, or something similar.

(Again, lets assume that prefixing is the approach we want to take)
The simplest approach I can think of:

Disallow : as described above
First IDP identities are never prefixed
All other IDP identities are prefixed with idp_name: (there is no way to opt-out or change this prefix, but the admin can name the IDP however they want to; IDPs of different types with the same name are explicitly disallowed within a single federation domain)

* Make it possible for the admin to configure Pinniped such that usernames and/or group names from certain IDPs are not changed by Pinniped.

-1, I do not believe this is necessary.
In my experience, multiple IDPs is a relatively rare and advanced use case, of which overlapping identities is a minor use case.  Most commonly, I have seen it used to workaround deficiencies of the IDP (i.e. the OIDC IDP doesn't support password grant so just use LDAP directly to get around the limitation).  We do not need to make it easy to create unsafe configurations to handle this scenario.
In the approach described above, and even today via multiple supervisors, it is possible to create overlaps if one is determined:

Create federation domain X and assign it IDP A
Create federation domain Y and assign it IDP B
Have clusters trust both X and Y with multiple JWT authenticators

This requires some extra YAML, but I think the extra friction is desirable here.
I remain skeptical that allowing multiple JWT authenticators is a good idea, but it is what we do today.  I would feel better if the only way to have multiple JWT authenticators required running multiple concierges under different API groups, but that is a different topic.

Thanks for the responses.
I could imagine an approach similar to what you are describing being sufficient for the MVP of multiple IDP support. It's not as flexible as I would prefer to advance Pinniped's vision of supporting any IDP, any cluster, and any authZ system. But it could meet the MVP requirements.
Assuming that we wanted to move forward with an approach like that, here are some thoughts on implementation details for that approach.

Disallow : as described above

I think we would need to be careful how we go about reserving a character and disallowing that character in usernames and groups. For example, if we chose : to be the reserved character, then we would be causing problems even with our own code. The default behavior of our OIDCIdentityProvider already puts : characters into usernames. And : is a perfectly reasonable character to put into a group name in almost any IDP. I'm not aware of any character that is generally avoided or generally disallowed by IDPs which we could ultimately rely upon. I could imagine that we allow the admin user to choose that separator for their FederationDomain, and default it to something reasonable like #. The default would hopefully work for most cases, and when it doesn't then an admin could change it. Whatever separator is configured could be both disallowed by Pinniped in usernames and groups names from all IDPs for that FederationDomain, and also used by Pinniped as the separator for automatic prefixing for IDPs in that FederationDomain, as you described.

First IDP identities are never prefixed

It might be nice instead for the user to choose which IDP in the list is the one which does not get auto-prefixed. It feels subtle for the ordering in the list to have this implied side effect. Perhaps the user can pick 0 or 1 IDPs for which they would like to disable auto-prefixing (not more than 1). By default, all listed IDPs could get auto-prefixed.
In an upgrade situation, a FederationDomain would have no IDPs listed on it, since we did not previously allow listing IDPs on FederationDomains. In that case, if we want to allow for smooth upgrades, we could keep our existing behavior of letting the FederationDomain automatically pick the one and only defined IDP (and error whenever there is more than one IDP). In this case, it would also be safe to not prefix that IDP's identities. If the admin later updates the FederationDomain to explicitly list the pre-existing IDP along with some new second IDP, then they could choose to disable prefixing for the pre-existing IDP if they would like to keep pre-existing usernames and group names unchanged for that IDP.

All other IDP identities are prefixed with idp_name: (there is no way to opt-out or change this prefix, but the admin can name the IDP however they want to; IDPs of different types with the same name are explicitly disallowed within a single federation domain

That should be an easy validation.  That would imply that you also can't list the same IDP twice in the same FederationDomain, which seems okay.
As a side note, IDP CRs can be named using lower case alphanumeric characters, - or ., and must start and end with an alphanumeric character, and are limited to 253 characters. So that rule would then effectively become the allowed names of the auto-prefixes too (not including the separator). Seems reasonable.

system and pinniped are disallowed as IDP names to prevent conflicts with well-known identities)

We could instead (or additionally) prevent this at login time. If any user in any way got one of those special prefixes during a login, then we could handle it and output a nice log message. We could reject the login or drop the offending group or however we decide to handle it. This would also handle the case where the one IDP which is not being auto-prefixed returned a username or group name starting with these disallowed prefixes.

(I jumped around a bit)

Disallow : as described above

I think we would need to be careful how we go about reserving a character and disallowing that character in usernames and groups. For example, if we chose : to be the reserved character, then we would be causing problems even with our own code. The default behavior of our OIDCIdentityProvider already puts : characters into usernames. And : is a perfectly reasonable character to put into a group name in almost any IDP. I'm not aware of any character that is generally avoided or generally disallowed by IDPs which we could ultimately rely upon. I could imagine that we allow the admin user to choose that separator for their FederationDomain, and default it to something reasonable like #. The default would hopefully work for most cases, and when it doesn't then an admin could change it. Whatever separator is configured could be both disallowed by Pinniped in usernames and groups names from all IDPs for that FederationDomain, and also used by Pinniped as the separator for automatic prefixing for IDPs in that FederationDomain, as you described.

I did a quick experiment with Okta/GitHub/GitLab/JumpCloud.  All of them disallow : in usernames and only JumpCloud/Okta allowed : in group names (I was surprised by JumpCloud here because I am pretty sure it violates the LDAP DN RFC 4514).  Basically I do not think this restriction causes problems in practice, because I would have heard of it during my time at Red Hat since there is simply no way to have a : in a username or a group name in OpenShift (and I did hear complaints about many other limitations).
I am confident that we can find ways to make such a restriction work with our existing defaulting.
I am against any configuration around the character used for the separator because it makes it impossible to rely on consistency across envs that folks can build on.  For example, RBAC against a synthetic group pinniped:authenticated that all users belong to in all envs.  This is not possible if the separator can be arbitrarily changed.  Configuration should be backed by evidence of its need, and I do not believe we have that here.

All other IDP identities are prefixed with idp_name: (there is no way to opt-out or change this prefix, but the admin can name the IDP however they want to; IDPs of different types with the same name are explicitly disallowed within a single federation domain

That should be an easy validation. That would imply that you also can't list the same IDP twice in the same FederationDomain, which seems okay.

We might just simply want to disallow the same name to be used across IDPs altogether.  They are logically the same resource with different config.

As a side note, IDP CRs can be named using lower case alphanumeric characters, - or ., and must start and end with an alphanumeric character, and are limited to 253 characters. So that rule would then effectively become the allowed names of the auto-prefixes too (not including the separator). Seems reasonable.

Probably worth thinking about if we want to restrict this further.

system and pinniped are disallowed as IDP names to prevent conflicts with well-known identities)

We could instead (or additionally) prevent this at login time. If any user in any way got one of those special prefixes during a login, then we could handle it and output a nice log message. We could reject the login or drop the offending group or however we decide to handle it. This would also handle the case where the one IDP which is not being auto-prefixed returned a username or group name starting with these disallowed prefixes.

I think we can figure out the specifics in the full proposal.  We will probably want multiple levels of validation.

First IDP identities are never prefixed

It might be nice instead for the user to choose which IDP in the list is the one which does not get auto-prefixed. It feels subtle for the ordering in the list to have this implied side effect. Perhaps the user can pick 0 or 1 IDPs for which they would like to disable auto-prefixing (not more than 1). By default, all listed IDPs could get auto-prefixed.
In an upgrade situation, a FederationDomain would have no IDPs listed on it, since we did not previously allow listing IDPs on FederationDomains. In that case, if we want to allow for smooth upgrades, we could keep our existing behavior of letting the FederationDomain automatically pick the one and only defined IDP (and error whenever there is more than one IDP). In this case, it would also be safe to not prefix that IDP's identities. If the admin later updates the FederationDomain to explicitly list the pre-existing IDP along with some new second IDP, then they could choose to disable prefixing for the pre-existing IDP if they would like to keep pre-existing usernames and group names unchanged for that IDP.

That sounds reasonable.

This has been superseded by several other GitHub issues.


[Design] Add visual idicator that user can copy the address by tapping on it in the side menu

Expected Behavior
There is a visual indication that user can copy the account key from the side menu. Should be a copy icon or just say in plain text "Tap to copy"
Current Behavior
Users are not aware that they can copy the account key by tapping over it. As a result, they type it in manually and do mistakes > send the funds to non-existing addresses. More context here: https://celo-org.slack.com/archives/C0134SBQTQR/p1619797847006600

Doesn't look like I'm able to edit this particular issue to add designs up top. Designs are here: Figma.
Consolidates this issue with some related formatting issues around handling large text sizes.


Unable to resolve multicast DNS hosts due to CGO_ENABLED=0

Disabling CGO puts some constraints on the netdns functionality of go.  If I have an edge node that is advertised by multicast DNS I cannot resolve this using the CLI.  It looks like this came from #328 to support building a single binary for both glibc and mucl systems.
Turning off the CGO_ENABLED=0 build flag we can force the behavior:
[iot@wonder jfrog-cli]$ GODEBUG=netdns=go+2 ./jfrog rt ping --server-id edge
go package net: GODEBUG setting forcing use of Go's resolver
go package net: hostLookupOrder(rtedge.local) = files,dns
[Error] Get http://rtedge.local:8081/api/system/ping: dial tcp: lookup rtedge.local on <IP_ADDRESS>:53: no such host

[iot@wonder jfrog-cli]$ GODEBUG=netdns=cgo+2 ./jfrog rt ping --server-id edge
go package net: using cgo DNS resolver
go package net: hostLookupOrder(rtedge.local) = cgo
[Error] Artifactory response: 404 Not Found
<!doctype html><title>HTTP Status 404 – Not Found</title>
HTTP Status 404 – Not Found

Type Status Report

Message /api/system/ping

Description The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

Apache Tomcat/8.5.32

From the golang source we can see why
https://golang.org/src/net/conf.go
	if stringsHasSuffixFold(hostname, ".local") {
		// Per RFC 6762, the ".local" TLD is special. And
		// because Go's native resolver doesn't do mDNS or
		// similar local resolution mechanisms, assume that
		// libc might (via Avahi, etc) and use cgo.
		return fallbackOrder
	}

@btashton,
Thanks for sharing this information. This may help other which come across this issue.
I guess the only option for now is to manually build the CLI sources with CGO_ENABLED=0.

yeah that seems reasonable. Otherwise we are going to have to be generating binaries for both musl and glibc which seems unnecessary at this time.


Create a rake task to fetch users with syndicate as "All counties"

updated the code in test2

List now with Pat.


Add 'text-formatter' sample project to index.json

Added sample project to index.json
Pull Request Title
Description
Please include a summary of the change or the feature being introduced. Include relevant motivation and context. List any dependencies that are required for this change.

[ ] This change requires a documentation update
[ ] I have made corresponding changes to the documentation

Related Issue(s)
This PR addresses issue #X
Screenshots
If relevant, please add screenshots.
Notes
Please add any relevant notes if necessary.

Sign the DCO please:
git commit --amend --author="your_name <your_email>"
example: git commit --amend --author="Rohan Sharma<EMAIL_ADDRESS>Or do git commit --amend and then add this message below your commit message:
Signed-off-by: your-name <your-email>
The email should be one associated with your github

@Mohiit70 please resolve the conflict

@Mohiit70 please resolve the conflict

Done


Update to work with zend-servicemanager v3

Updated dependencies to versions known to be forwards-compatible with zend-servicemanager v3. Updated the CI setup to test against the lock file, lowest supported, and latest dependencies.
Forwards-compatibility required the following changes:

The HelperPluginManagerFactory needed updates to work with both v2 and v3 instantiation and configuration of plugin managers.
The ZendViewRendererFactory needed updates to how it injects the override factories to ensure that they work as expected with zend-view 2.6.

Ping @Ocramius ; this was what you requested yesterday. If tests pass, I'll issue a 1.1.0 release.

@Ocramius and... tests all pass. I did a double-check on them to see what the lowest and latest targets installed, and they were indeed v2 and v3 versions of zend-eventmanager and zend-servicemanager, respectively, proving that this will work in both situations.
Merging and tagging!


Cannot join the Stellar Lumens Airdrop

Hi,
I have done everything that you wanted from us for airdrop.I have github account that registered on August and have three sources such as phone,computer and paper keys but keybase said you’re not the qualified for airdrop.Please help me.I want to join that airdrop
Regards.

And i want to say it
I have registered keybase and username was yusufounded but i forgot paper keys so i want to close that account and i decided to use 212pavlov account.That’s why i am adding it in order to inform about yusufounded was past account.Please do not think there is 2 account.I am using activately 212pavlov.Please allow me to join this airdrop.


Remove code scanning

Remove code scanning from ibm-block-csi-operator repo.

This change is

@annalisy could we delete this branch?

@oriyarde not yet.

@oriyarde not yet.

OK. please clear assignees here (we only use "reviewers")


Interactive menu

Closes #52

Hello @Seluj78! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file potodo/potodo.py:

Line 149:80: E501 line too long (91 > 79 characters)
Line 333:1: W293 blank line contains whitespace
Line 334:80: E501 line too long (87 > 79 characters)
Line 335:80: E501 line too long (113 > 79 characters)

Where it's at : https://asciinema.org/a/Z71DSm62RKOWKEsIZz6A4gnOL

Need help to fix the pytest / tox error. I fixed the error on my computer by removing the .tox folder. Maybe do the same on travis ? Then we get a jsondecodeerror.
cc @awecx @JulienPalard

Need help to fix the pytest / tox error. I fixed the error on my computer by removing the .tox folder. Maybe do the same on travis ? Then we get a jsondecodeerror.

JSONDecodeError fixed hopefully


[#4905] Update Windows dev distribution for git-lfs and store buildbot credentials in external files.

Scope
This is an update for the Windows dev environment to have rsync and git-lfs.
Changes
Create a new archive with git-lfs and rsync.
Add documentation to the archive (version file, readme files)
Simplify the msys-console.js script.
This also adds support for sha256 checksum as an update to md5.
How to try and test the changes
reviewers: @lgheorghiu
@lgheorghiu you should download the msys-console.js script from this branch and run it.
It should create a new dev environment which has git-lfs and rsync and ssh-rsync
@lgheorghiu you should uninstall git-lfs if you have it manually installed.
Let me know if other tools needs to be installed.

@dumol please check that paver.conf is ok... is the same as in compat now :)
I added as a reviewer just to know that you Windows base env was updated.
You can give it a try on Windows VM, or just wait for when a new Win VM can be created.
The git version is the same, this just adds extra tools.
1.Publish to staging from Windows
In a branch on chevah/server or sftpplus.com modify paver.conf to have chevah-brink==0.69.2
Then run paver.deps
You will need to create c:\users\YOUR-USER\.ssh\config file and add Port for the staging.sftpplus.com as documented in the README from sftpplus.com
the content of .ssh\config for Windows
UserKnownHostsFile c:\Users\YOUR-USER\.ssh\known_hosts
Host staging.sftpplus.com
    Port 12022
    IdentityFile C:\Users\YOUR-USER\.ssh\id_rsa

C:\Users\YOUR-USER\.ssh\id_rsa is the path to the SSH key which you configured to allow uploads.
Then try paver publish --target=staging on a SFTPPlus.com branch or paver publish_documentation on chevah/server branch.

Thanks. The "required" builds can be configured from here https://github.com/chevah/brink/settings/branches/master.
Yes. We can enable Solaris 11 on x86.

@dumol can you please copy /home/chevah/git-windows-x86-2.11.0.chevah2.zip on deag to buildmaster so that it will reach binary.
My PGP setup is broken now and I can't get the root password for deag :)

@lgheorghiu once you can see git-windows-x86-2.11.0.chevah2.zip https://binary.chevah.com/production/msys-console/ please get the new msys-console.js or update your msys-console.js to have chevah2.zip version and give a a try.
Check the updated description for how to set up the .ssh/config file.
needs-review

Done.
On 05/24/18 02:46, Adi Roiban wrote:

@dumol https://github.com/dumol can you please copy
/home/chevah/git-windows-x86-2.11.0.chevah2.zip on deag to buildmaster
so that it will reach binary.
My PGP setup is broken now and I can't get the root password for deag :)

@lgheorghiu https://github.com/lgheorghiu once you can see
git-windows-x86-2.11.0.chevah2.zip
https://binary.chevah.com/production/msys-console/ please get the new
msys-console.js or update your msys-console.js to have chevah2.zip
version and give a a try.
Check the updated description for how to set up the |.ssh/config| file.
needs-review
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/chevah/brink/pull/117#issuecomment-391538932, or
mute the thread
https://github.com/notifications/unsubscribe-auth/ABi7xf51RH8wO2xY2B_dCVT5Cj8JU2caks5t1fTsgaJpZM4TzsZv.

paver.conf changes look fine.
changes-approved

@adiroiban I'm failing to make it run. I'll wait for you to get back tomorrow so we can have a look together.

@lgheorghiu please give it a try with  0.69.4
The work is not perfect, but I hope is good enough for using it on staging.
Please check if git-lfs works on your side... on my system the images where not uploaded as they were git-lfs.
needs-review

Tested with the 0.69.4 on a sftpplus.com branch (sftpplus.com (4867-ipv6-preparedness-filet
ransfer)). Ran paver publish --target=staging and got the following error:
Sending to staging... yeovil.sftpplus.com staging.sftpplus.com/
rsync: -no-p: unknown option
rsync error: syntax or usage error (code 1) at main.c(1578) [client=3.1.3]

No pressure, but isn't this fixed already? Why is it not merged?
Itching to close a ticket of time that depends on this: https://trac.chevah.com/ticket/4723.

This is not fixed as I was also trying to get rsync.
A brink version from this branch is already released and used in production.
I think that for dev, we now just use choco  and then msys-console.js can be removed.
@dumol can you please take over this PR?
I was thinking to just remove msys-console.js  and make sure the current documentation is ok for @lgheorghiu to set up a new DEV environment in windows.
Thanks!

This is not fixed as I was also trying to get rsync.
A brink version from this branch is already released and used in production.
I think that for dev, we now just use choco and then msys-console.js can be removed.
@dumol can you please take over this PR?
I was thinking to just remove msys-console.js and make sure the current documentation is ok for @lgheorghiu to set up a new DEV environment in windows.
Thanks!

I don't know what this is all about, but I'll take a look and try to finish it. Wish me luck! ;-]

OK, I've looked closer through the changes, this is a big PR. I understand it doesn't solve all the issues. But it does solve quite a few of them!
I suggest this should be merged in master, especially given there's already a released brink used in production.
Then I can look into simplifying things through Chocolatey and the other related goodies I used in salt-master repo for the Windows build slaves.
Adi, what say you?

@dumol I tried to update the code to get green build
it looks like openbsd slave needs more space
I will merge it as it is, but when you have time, please look into the disk space issue.
Thanks!

@dumol I tried to update the code to get green build
it looks like openbsd slave needs more space
I will merge it as it is, but when you have time, please look into the disk space issue.

Thanks! Solved the free space issue on the OpenBSD slave by using symlinks for build* and cache.
There is still some bug that prevents using symlinks for brink repo, but it's unrelated to the issue I fixed in this branch. For the reference, deps phase fails with:
Installing base requirements: paver==1.2.4.
Requirement already satisfied: paver==1.2.4 in /srv/buildslave/runtime/build-openbsd65-x64/lib/python2.7/site-packages
You are using pip version 9.0.3, however version 19.1.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/srv/buildslave/runtime/build-openbsd65-x64/slave/brink-obsd/build/build-openbsd65-x64/lib/python2.7/site-packages/paver/tasks.py", line 878, in main
    _launch_pavement(args)
  File "/srv/buildslave/runtime/build-openbsd65-x64/slave/brink-obsd/build/build-openbsd65-x64/lib/python2.7/site-packages/paver/tasks.py", line 846, in _launch_pavement
    exec(compile(source, environment.pavement_file, 'exec'), mod.__dict__)
  File "pavement.py", line 171, in <module>
    options.closure_linter['enabled'] = True
AttributeError: 'ScameOptions' object has no attribute 'closure_linter'


$agent->is('Chrome') returns true for edge

Hello, with version 2.6.0 on php 7.0, Edge
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15063

is detected as Chrome with $agent->is('Chrome')
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.109 Safari/537.36

The 2 are distinguished correctly by http://php.net/manual/en/function.get-browser.php, so I guess it's something with this library, and the method $agent->browser() returns the correct browser name.
Why this discrepance? Is it intended? Does the documentation need an update?
Thank you

I added your user agent to the test in https://github.com/jenssegers/agent/commit/deabb66d2fb6de930514edfa643a815c5729a2ba


Two instance so SQL Server Managment Studio

SUGGESTION:
When installing SQL 2014; the xSQLSetup installs SSMS feature automatically, yet I can specified a newer one in the params.
No errors in logs, it just has two version installed

Suggested solution to the issue
I would change Line 127 to
$Features = 'SQLENGINE,RS,CONN,BC',
Then add right below line 263
if (($SqlVersion -in @('2008', '2008R2','2012','2014')) -and (-Not($InstallManagementStudio)))
    {
        [string]$Features = [string[]]$Features + "SSMS,ADV_SSMS" -join ','
    }

I had to change the $features variable to an array, then join new list, then convert it back to a string to be processed
Or you could put logic to add the built-in SSMS for older SQL versions only if  $InstallManagementStudio was specified and only if no additional exe path was specified. Something like:
if (($SqlVersion -in @('2008', '2008R2','2012','2014')) -and ($InstallManagementStudio) -and ($null -eq $SqlManagementStudioExePath))
    {
        [string]$Features = [string[]]$Features + "SSMS,ADV_SSMS" -join ','
    }

Then in line 304 where is checking for the path, change it to:
if (($SqlVersion -notin @('2008', '2008R2','2012','2014')) -and ($null -eq $SqlManagementStudioExePath))
        {
            Write-Error -Message $('When specifying to Install SQL Management Studio, you need to provide ' +
                'SqlManagementStudioExePath.')
        }

this will ensure that the config is checking the sql versions and why or why path is missing for only the higher versions
The DSC configuration that is used
xSccmSqlSetup SQLInstall
        {
            SqlVersion                  = '2014'
            SqlInstanceName             = 'MSSQLSERVER'
            SqlServiceCredential        = $sqlcreds
            SqlAgentServiceCredential   = $sqlcreds
            SqlSysAdminAccounts         = @($sqlUsername,$cmUsername)
            SqlInstallPath              = "U:\SQL2014SP3CU4_ENU\"
            InstallSqlDataDir           = 'E:\Microsoft SQL Server'
            SQLUserDBDir                = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data'
            SQLUserDBLogDir             = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log'
            SQLTempDBDir                = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Temp'
            SQLTempDBLogDir             = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log'
            UpdateEnabled               = $true
            InstallManagementStudio     = $true
            SqlManagementStudioExePath  = "U:\SSMS_18.5\SSMS-Setup-ENU.exe"
            SqlManagemenStudioProductId = '061E40C6-EFF2-482A-82BC-B0A0FDC47898'
            PsDscRunAsCredential        = $sqlcreds
            DependsOn                   = '[xSccmPreReqs]CASprereqs'
        }

The operating system the target node is running
OsName               : Microsoft Windows Server 2012 R2 Standard
OsOperatingSystemSKU : StandardServerEdition
OsArchitecture       : 64-bit
WindowsBuildLabEx    : 9600.19724.amd64fre.winblue_ltsb_escrow.200519-1914
OsLanguage           : en-US
OsMuiLanguages       : {en-US}
Version and build of PowerShell the target node is running
Key   : PSVersion
Value : 5.1.14409.1018
Name  : PSVersion
Key   : PSEdition
Value : Desktop
Name  : PSEdition
Key   : PSCompatibleVersions
Value : {1.0, 2.0, 3.0, 4.0...}
Name  : PSCompatibleVersions
Key   : BuildVersion
Value : 10.0.14409.1018
Name  : BuildVersion
Key   : CLRVersion
Value : 4.0.30319.42000
Name  : CLRVersion
Key   : WSManStackVersion
Value : 3.0
Name  : WSManStackVersion
Key   : PSRemotingProtocolVersion
Value : 2.3
Name  : PSRemotingProtocolVersion
Key   : SerializationVersion
Value : <IP_ADDRESS>
Name  : SerializationVersion
Version of the DSC module that was used
0.2.0

@PowerShellCrack
You can change following but by providing the Features to the composite resource:
xSccmSqlSetup SQLInstall
        {
            SqlVersion                  = '2014'
            SqlInstanceName             = 'MSSQLSERVER'
            SqlServiceCredential        = $sqlcreds
            SqlAgentServiceCredential   = $sqlcreds
            SqlSysAdminAccounts         = @($sqlUsername,$cmUsername)
            SqlInstallPath              = "U:\SQL2014SP3CU4_ENU\"
            InstallSqlDataDir           = 'E:\Microsoft SQL Server'
            SQLUserDBDir                = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data'
            SQLUserDBLogDir             = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log'
            SQLTempDBDir                = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Temp'
            SQLTempDBLogDir             = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log'
            UpdateEnabled               = $true
            InstallManagementStudio     = $true
            SqlManagementStudioExePath  = "U:\SSMS_18.5\SSMS-Setup-ENU.exe"
            SqlManagemenStudioProductId = '061E40C6-EFF2-482A-82BC-B0A0FDC47898'
            PsDscRunAsCredential        = $sqlcreds
            DependsOn                   = '[xSccmPreReqs]CASprereqs'
        }

to
xSccmSqlSetup SQLInstall
        {
            SqlVersion                  = '2014'
            SqlInstanceName             = 'MSSQLSERVER'
            Features                    = 'SQLENGINE,RS,CONN,BC'
            SqlServiceCredential        = $sqlcreds
            SqlAgentServiceCredential   = $sqlcreds
            SqlSysAdminAccounts         = @($sqlUsername,$cmUsername)
            SqlInstallPath              = "U:\SQL2014SP3CU4_ENU\"
            InstallSqlDataDir           = 'E:\Microsoft SQL Server'
            SQLUserDBDir                = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data'
            SQLUserDBLogDir             = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log'
            SQLTempDBDir                = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Temp'
            SQLTempDBLogDir             = 'E:\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log'
            UpdateEnabled               = $true
            InstallManagementStudio     = $true
            SqlManagementStudioExePath  = "U:\SSMS_18.5\SSMS-Setup-ENU.exe"
            SqlManagemenStudioProductId = '061E40C6-EFF2-482A-82BC-B0A0FDC47898'
            PsDscRunAsCredential        = $sqlcreds
            DependsOn                   = '[xSccmPreReqs]CASprereqs'
        }


Update in-practice.md  Add internal link to 4 Core Actions

I wanted to be able to link to the actions separately from the principles.  I see the following code show up in my preview and I don't seem to be able to fix it, so I am hoping that someone else knows what to do.

To link to a section I think you'll need to use section headers, ie '###' or '####'
There may be a fancy way if you don't like how those look.

@memartone that <style> bit is the magic that lists the principles as number-letter and you should be able to safely ignore it.
With your change you should now be able to link directly to the actions using /about/in-practice/#repronims-4-core-actions.


Specific parameter setting when training on activityNet v1.2

Hi, I trained your pytorch code  on activityNet v1.2 dataset. But I can only get the results as follows.
<EMAIL_ADDRESS>47<EMAIL_ADDRESS>44<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>33....it is much lower than what you posted. I think there's something wrong with the parameters. Can you share the specfic paramaters when training on activitNetv1.2 ? I would appreciate it very much if I could receive your reply.

@zronly how were you able to get the results you cited? I'm trying to do the same from my end, but I get mAP @ IoU=0.5 that's extremely low (less than 1%). The classification mAP reaches +90%.
I'm running the ActivityNet1.2 experiment with the following settings:
python main.py --dataset-name ActivityNet1.2 --num-class 100 --model-name AN1.2_reprduce
I edited the smooth() function in detectionMAP.py to include the savgol_filter() call. I have played around with the threshold, but the detection mAP is still extremely low.

Please refer to this: https://github.com/sujoyp/wtalc-pytorch/issues/7
Also need to use savgol_filter as @HumamAlwassel mentioned.

Please refer to this: #7
Also need to use savgol_filter as @HumamAlwassel mentioned.
Yes, i have used the same setting as what you said, but i find the CASLOSS is not work when training the activitynet1.2 , because when  the casloss goes down, the accuracy  also goes down. Is this caused by batch size? or learning rate?

@zronly i have test the results on ＡctivitＮet1.2, and get the same results as yours mAP＠0.5=33.5, if you have got the results posted in paper, please let me know.
I run experiments on ActivityNet1.2 with the following settings:
python main.py --dataset-name ActivityNet1.2 --num-class 100
I do not change any other parameters in options.py provided by author used for training thumos14.
@sujoyp I will be really appreciate if you could offer the option.py used for ActivityNet

@zronly i have test the results on ＡctivitＮet1.2, and get the same results as yours mAP＠0.5=33.5, if you have got the results posted in paper, please let me know.
I run experiments on ActivityNet1.2 with the following settings:
python main.py --dataset-name ActivityNet1.2 --num-class 100
I do not change any other parameters in options.py provided by author used for training thumos14.
@sujoyp I will be really appreciate if you could offer the option.py used for ActivityNet

the casloss don't work when training on ActivityNet1.2, i am not sure if it has anything to do with parameters.


HTML has its own defined scrollbar, and the mouse wheel cannot scroll

html：

the mouse wheel cannot scroll

me, too.

me, too.

me, too.  open  https://liao.world/en  If the webpage is long enough in HTML, it can be scrolled, but if it has only one screen and then its subcomponents are scrolled, it cannot be scrolled. We hope to fix this issue

+1

I guess we can use JS communication

Using JS communication, scroll events and input box events need to be implemented on the flutter side

Any update about this issue?


#211 Sets parent first to force a path update.

Fixes #211 - Now updates the parent first to update the path so the compare works correctly. Also means items will be put back in alphabetical order.

thanks!


Removed reset process for request Body for temporary support

Triggers for Change
https://github.com/k1LoW/runn/releases/tag/v0.51.0
The previously addressed issue has reappeared in the above version.
https://github.com/k1LoW/runn/pull/91
The following library versions have changed due to the pkgs update
<EMAIL_ADDRESS>-><EMAIL_ADDRESS>The contents of the release are as follows
https://github.com/getkin/kin-openapi/releases/tag/v0.109.0
What we verified

No error should occur if skipValidateRequest: false
No errors should occur after downgrading to the<EMAIL_ADDRESS>version

Cause Considerations
I thought the error recurred due to the following PR
https://github.com/getkin/kin-openapi/pull/672
The request body reset process in #91 is no longer needed due to modifications to the library itself.
On the contrary, the inclusion of provisional support seems to have caused the content length to be caught in the content length check.
Changes
Deleted the process supported by #91
My project is working well with this response.
Worries
There may be an impact on the functionality of Multipart Form Data

Oh. What I feared happened.
https://github.com/k1LoW/runn/actions/runs/3601501427/jobs/6067375050#step:7:35
I couldn't reproduce it in the last test, but I didn't think it would be at a time like this. 😅

How about using io.TeeReader?

how about this?
bw := new(bytes.Buffer)
req, err = http.NewRequestWithContext(ctx, r.method, u.String(), io.TeeReader(reqBody, bw))
if err != nil {
	return err
}
r.setContentTypeHeader(req)
for k, v := range r.headers {
	req.Header.Set(k, v)
}
rnr.operator.capturers.captureHTTPRequest(rnr.name, req)
...

req, err = http.NewRequestWithContext(ctx, r.method, u.String(), bw)
if err != nil {
	return err
}
r.setContentTypeHeader(req)
for k, v := range r.headers {
	req.Header.Set(k, v)
}
res, err = rnr.client.Do(req)
if err != nil {
	return err
}

@atsushi-ishibashi
Thank you for the suggested modifications.
The following PR resolved the problem
https://github.com/k1LoW/runn/pull/345
I will keep this in mind for future reference.


is there subtle difference on KPConv module from that of paper?

Hello!
first of all I deeply thank your code share
I do have one question regarding to the operation on KPConv
In paper, from what I know, it follows as...

subtract all neighboring points from a basis point
subtract that to kernel points
put the result to the linear correlation function "h"
multiply that with a learnable weight
multiply the output to other points (denoted as f_i in paper)

However I am uncertain with the process and think process 4 and 5 should be changed. This learnable weight will change the dimension of the data which will not allow the multiplication operation on 5
and that is what I see on the pytorch code
Is there something I am missing??
thanks in advance!

Hi @ooodragon94,
In the paper, the convolution operation is defined by:

With

Even though I decided to separate the summation like this, the result remains a double summation over the number of neighbor points i and the number of kernel points k. The only term that depends on both i and k is the correlation, so we have to compute them first in any case. But after that, we can either multiply by the weights W(k) first and the features f(i) second, or vice versa.
I separated the summations in the paper for a better comprehension of what happens, but the most optimal way to implement it is to multiply by f(i) first. In the end, the operation is strictly identical to what is described in the paper.
Best,
Hugues

Hi @ooodragon94,
In the paper, the convolution operation is defined by:

With

Even though I decided to separate the summation like this, the result remains a double summation over the number of neighbor points i and the number of kernel points k. The only term that depends on both i and k is the correlation, so we have to compute them first in any case. But after that, we can either multiply by the weights W(k) first and the features f(i) second, or vice versa.
I separated the summations in the paper for a better comprehension of what happens, but the most optimal way to implement it is to multiply by f(i) first. In the end, the operation is strictly identical to what is described in the paper.
Best,
Hugues


FUSE 3: "fusermount: unknown option 'nonempty'"

See original issue on GitLab
In GitLab by [Gitlab user @valentindavid] on Jan 14, 2019, 10:16
Summary
When FUSE 3 is installed, builds running integration commands fail with the error:
fusermount: unknown option 'nonempty'

Other relevant information
This issue happens on Debian where package fuse3 provides both fusermount3 and fusermount.
In FUSE 3, nonempty is always true, and has been removed. By default it is false on FUSE 2.
Note that buildbox requires FUSE 3. So we cannot have a local buildbox on the builder (unless using a container).

BuildStream version affected: /milestone %BuildStream_v1.x

In GitLab by [Gitlab user @valentindavid] on Jan 14, 2019, 10:16
changed the description

In GitLab by [Gitlab user @valentindavid] on Jan 21, 2019, 13:26
changed the description

In GitLab by [Gitlab user @coldtom] on Jun 4, 2020, 12:24
Closed by !1834, unless I'm missing something.

In GitLab by [Gitlab user @coldtom] on Jun 4, 2020, 12:24
closed


Wands stopped working after update

I have fully configured the magic plugin but since I updated the plugin not any of the wands work. I don't know how this happened. I get these errors for every single spell. I hope someone could help me because I'm using the plugin quite a time but never had any issues like this
11.03 16:45:45 [Server] WARN Unknown or disabled spell prerequisite missile in path battle, ignoring
11.03 16:45:45 [Server] WARN Unknown or disabled spell prerequisite cure in path battle, ignoring
11.03 16:45:45 [Server] WARN Unknown or disabled spell prerequisite fireball in path battle, ignoring
11.03 16:45:45 [Server] WARN Unknown or disabled spell prerequisite push in path battle, ignoring
11.03 16:45:45 [Server] WARN Unknown or disabled spell prerequisite pull in path battle, ignoring
11.03 16:45:45 [Server] WARN Unknown or disabled spell prerequisite blind in path battle, ignoring
11.03 16:45:45 [Server] WARN Unknown or disabled spell prerequisite reflect in path battle, ignoring

Could you please post the full server log via pastebin? I suspect there are errors before these?
Seeing your config.yml would help too.
It looks like it's failing to load configs, or else you have the default spells disabled?

Hm if all there is are those warnings everything should still work, but I'm guessing you maybe missed this migration step?
https://github.com/elBukkit/MagicPlugin/blob/master/Magic/MIGRATION.md#66
enchanting.yml changes to paths.yml
And if you have load_default_enchanting in config.yml you need to change it to load_default_paths
That's maybe not it, but definitely would cause those warnings- they are just warnings though, so unless something else is in your logs those shouldn't be causing problems.

there are no other errors, but i removed the spells config and now the spells work but i couldn't open my spells inventory so i removed the other magic files and started it up but i still can use the spells on the wands but i can't open the spells inventory

Read through that migration log, there are probably some things you need to add to your wand configs if they are completely custom- see the section on mode, left_click, etc
Very important to check the migration log when updating, I try not to change things but sometimes I have to.

Please let me know if those config changes fix your problems, if not then something else may be wrong.

I deleted all the configs and the plugin itself. Restarted the server but it didn't work. I tried an older version of the plugin too but that also didn't work. I can't find any other errors so I don't know what could have happened.

That sounds really weird, this definitely looks like a config issue. Could you please hastebin your server logs here so I can take a look?

http://pastebin.com/719cyj95

Oh hm, so the errors are gone? But the plugin still isn't working? Does that include commands?

No, everything works except for opening the wand inventory. So the spells work to but i can't scroll through the spells.

And you definitely don't have anything in plugins/Magic/config.yml, no custom wands?
I'm pretty sure that build isn't broken (I could be wrong)- if you do /wand describe while holding a wand, does it show a "mode" and "drop" property in the wand template parameters?
And just to be 100% clear, you are using the drop (Q) button to open the wand inventory, right?

Nope, I have always used right mouse click xD. This did always work last time i tried the Q button didn't do anything too so i think it was something in my configs. But thank you!

Ah, whoops! That changed a long while ago, around 1.9, to support offhand items.
You can change it back in your configs pretty easily, it'd be like this:
base_wand:
  right_click: toggle
  drop: none

Is it normal that the spell icons are changed? It doesn't have that easy look anymore

Not sure what you mean. Unless you're using the potter configs the icons haven't really changed.

I am using the potter configs. I think the new icons are not looking very clear.

Oh- yeah they did change in the potter configs. Someone donated 32x32 high-res icons specifically made for those configs.
If you don't want them, you can just use the survival configs. Add this to your Magic/config.yml
default_resource_pack: "https://s3-us-west-2.amazonaws.com/elmakers/Magic/Magic-RP-6-4.zip"


Formatting the code removes all comments

#Some comment
database:
  mysql:
    #another comment
    core: null

All comments gets removed. Possible to not remove them?

The underlying library that provides formatting does not (and will not) support comments.  If another workable library can be found that preserves comments, I would be happy to switch.
If no existing library can be found and someone wants to take this on, my recommended starting point would be to see if the parser that powers this extension would be willing to accept a PR to add a node type for comment nodes.  If comments appear in the tree, then it would just be a matter of writing a function that produces formatted output given the tree.
A related issue tracking the same [lack of] functionality is adamvoss/vscode-yaml#9.

This is an useful recommendation. Inline comment should be returned also.


g4dn instances should have enhanced networking

Currently, the G4DN instances display as enhanced networking = no. But these instances have enhanced networking.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html#supported_instances

Thanks! Let's track this with #415

Closing this as it was resolved by #415.


[Dark Mode] Some improvements to dark mode

Scrollbars styling
Better contrast for blue texts
Fix Combobox disabled background style
Fix all TextBlock Display like the ones in the "About" window
Minor change to PZ55 Picture to remove the too bright top part
Add Style to Toolbar ButtonStyleKey

Great! :smile:


cumulus-companion: Fix CI when there is no Polkadot companion

This tries to fix the CI if there is no polkadot companion. Currently we don't update Polkadot
master in Cumulus, which means we may use some old commit that isn't compiling with the latest
Substrate master anymore. This can happen if there was a pr that had a companion in Polkadot, but no
companion was required for Cumulus.  So, we need to tell the script to use the
latest master of Polkadot. If there is a companion for Polkadot, it would simply override the extra
dependency patch later on.

@bkchr could you link the situation which prompted this PR? I would like to see if there's a different solution available and understand if the problem is being diagnosed correctly. EXTRA_DEPENDENCIES wasn't intended for this use-case.

@bkchr could you link the situation which prompted this PR? I would like to see if there's a different solution available and understand if the problem is being diagnosed correctly. EXTRA_DEPENDENCIES wasn't intended for this use-case.

https://github.com/paritytech/substrate/pull/11027 for example. But basically every pr that hasn't any Polkadot companion right now.

Currently we don't update Polkadot master in Cumulus, which means we may use some old commit that isn't compiling with the latest Substrate master anymore

For the record, I think that situation happens when a PR bypasses the CI check or the Companion Build System is not working properly. Assuming the CI checks are always respected and the Companion Build System works properly, there's no such case of "we don't update Polkadot master in Cumulus" because that should automatically be done by processbot after dependencies are merged.
I approved this PR because it might improve the status quo and doesn't pose an issue, but I feel like theoretically this shouldn't be needed if the system is implemented and respected properly.
cc @TriplEight

Yeah, I agree, this might improve the status quo in the situation where at first there was a Polkadot companion.
We shall investigate and resolve this situation in the future. This workaround is cheap, but not necessary when the issue is addressed.


[SPARK-27857][SQL] Move ALTER TABLE parsing into Catalyst

What changes were proposed in this pull request?
This moves parsing logic for ALTER TABLE into Catalyst and adds parsed logical plans for alter table changes that use multi-part identifiers. This PR is similar to SPARK-27108, PR #24029, that created parsed logical plans for create and CTAS.

Create parsed logical plans
Move parsing logic into Catalyst's AstBuilder
Convert to DataSource plans in DataSourceResolution
Parse ALTER TABLE ... SET LOCATION ... separately from the partition variant
Parse ALTER TABLE ... ALTER COLUMN ... [TYPE dataType] [COMMENT comment] as discussed on the dev list
Parse ALTER TABLE ... RENAME COLUMN ... TO ...
Parse ALTER TABLE ... DROP COLUMNS ...

How was this patch tested?

Added new tests in Catalyst's DDLParserSuite
Moved converted plan tests from SQL DDLParserSuite to PlanResolutionSuite
Existing tests for regressions

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11104/
Test PASSed.

Test build #105848 has started for PR 24723 at commit 708fbdb.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11105/
Test PASSed.

Test build #105849 has started for PR 24723 at commit 36a2bcd.

Test build #105848 has finished for PR 24723 at commit 708fbdb.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class NewColumn(name: Seq[String], dataType: DataType, comment: Option[String])
case class AlterTableAddColumnsStatement(
case class AlterTableAlterColumnStatement(
case class AlterTableRenameColumnStatement(
case class AlterTableDropColumnsStatement(
case class AlterTableSetPropertiesStatement(
case class AlterTableUnsetPropertiesStatement(
case class AlterTableSetLocationStatement(
case class AlterViewSetPropertiesStatement(
case class AlterViewUnsetPropertiesStatement(

Merged build finished. Test FAILed.

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

Test build #105849 has finished for PR 24723 at commit 36a2bcd.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class NewColumn(name: Seq[String], dataType: DataType, comment: Option[String])
case class AlterTableAddColumnsStatement(
case class AlterTableAlterColumnStatement(
case class AlterTableRenameColumnStatement(
case class AlterTableDropColumnsStatement(
case class AlterTableSetPropertiesStatement(
case class AlterTableUnsetPropertiesStatement(
case class AlterTableSetLocationStatement(
case class AlterViewSetPropertiesStatement(
case class AlterViewUnsetPropertiesStatement(

Merged build finished. Test FAILed.

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

Retest this please.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11175/
Test PASSed.

Test build #105923 has started for PR 24723 at commit 36a2bcd.

Test build #105923 has finished for PR 24723 at commit 36a2bcd.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class NewColumn(name: Seq[String], dataType: DataType, comment: Option[String])
case class AlterTableAddColumnsStatement(
case class AlterTableAlterColumnStatement(
case class AlterTableRenameColumnStatement(
case class AlterTableDropColumnsStatement(
case class AlterTableSetPropertiesStatement(
case class AlterTableUnsetPropertiesStatement(
case class AlterTableSetLocationStatement(
case class AlterViewSetPropertiesStatement(
case class AlterViewUnsetPropertiesStatement(

Merged build finished. Test FAILed.

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

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11186/
Test PASSed.

Test build #105934 has started for PR 24723 at commit a4f56b8.

Test build #105934 has finished for PR 24723 at commit a4f56b8.

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

Merged build finished. Test PASSed.

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

@cloud-fan, @mccheah, @dongjoon-hyun, @jzhuge, could you review this PR? It updates SQL parsing for ALTER TABLE like the recent changes for CREATE TABLE and DROP TABLE. The parser is updated as discussed on the dev list.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11226/
Test PASSed.

Test build #105975 has started for PR 24723 at commit 84be6d2.

Test build #105975 has finished for PR 24723 at commit 84be6d2.

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

Merged build finished. Test PASSed.

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

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11283/
Test PASSed.

Test build #106033 has started for PR 24723 at commit 4902420.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11289/
Test PASSed.

Test build #106039 has started for PR 24723 at commit 40c94dd.

Test build #106033 has finished for PR 24723 at commit 4902420.

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

Merged build finished. Test PASSed.

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

Test build #106039 has finished for PR 24723 at commit 40c94dd.

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

Merged build finished. Test PASSed.

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

LGTM

Normally, we check if it is possible to split it into multiple smaller, logical PRs or commits that can be quick to review.

Keep refactors in separate PRs
Fix one issue/bug per PR.

@ueshin Please help review this PR and ensure these DDLs are well tested, especially when handling nested columns.

Build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11367/
Test FAILed.

Test build #106116 has started for PR 24723 at commit 7e2369e.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11368/
Test PASSed.

Test build #106117 has started for PR 24723 at commit c558499.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11369/
Test PASSed.

Test build #106116 has finished for PR 24723 at commit 7e2369e.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class QualifiedColType(name: Seq[String], dataType: DataType, comment: Option[String])

Merged build finished. Test PASSed.

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

Test build #106117 has finished for PR 24723 at commit c558499.

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

Merged build finished. Test PASSed.

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

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/11414/
Test PASSed.

Test build #106163 has started for PR 24723 at commit bd7d8c8.

Thanks for reviewing this, @ueshin. I've addressed the problems you found. Please have another look.

Test build #106163 has finished for PR 24723 at commit bd7d8c8.

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

Merged build finished. Test PASSed.

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

LGTM.

@dongjoon-hyun, could you have another look and possibly merge? I think the review items have been addressed. Thank you!

Thanks for reviewing this, @ueshin!

cc @yeshengm This PR will affect your parser changes. I will merge this PR first and you can address the issues in your PR.

Thanks! Merged to master.

Thank you for merging this, @gatorsmile!


Issue with Collection scrolling when data is loaded async

https://plnkr.co/edit/81aoXFH8mkZhoxaKib2o
So first off, I've setup a plunker as requested. This is a snippet of what we are/were planning to use in production.
As it stands, the grid works as desired. When we started using real data, we came across a big problem.
To see the issue, on script.jsx - line 45, if you comment out the initial "this.populate()" then you can see the entire grid / page scrolling rather than just the items as desired.
At the moment I am cheating by seeding the grid with initial data but I'd like to not do this.
Thanks.

Thank you for the Plnkr and the detailed bug description. Looks like this bug can be reproduced on the official site as well: https://bvaughn.github.io/react-virtualized/#/components/Collection

Open page
Change cell count to 0
Change cell count back to 1000

The problem seems to be that the overflow: auto style is not present as of step 3. But logging the style object shows that I'm specifying that style... I'm a bit confused.

Interesting... these lines are forcefully turning off scrollbars if the content is not tall or wide enough to require scrolling.
It seems like- once I've set a value for overflowX: hidden then subsequently applying a style with overflow: auto (and no overflowX property at all) doesn't stick.
This seems like a bug outside of react-virtualized.
I can fix it in react-virtualized though by making CollectionView styles do what Grid does.

Fixed with b5b8e29. Will go out in a release sometime in the next couple of days.
In the meanwhile you should be able to work around this on your end by passing a style prop like:
<Collection
  {...props}
  style={{
    overflowX: 'auto',
    overflowY: 'auto'
  }}
/>

I've captured this bug with a small Plnkr: https://plnkr.co/edit/7O1xZUqbD13ST2BAxcm9?p=preview
I'll see if I can track it down if it's a React bug.

The underlying bug actually impacts all shorthand CSS properties. Turns out that shorthand properties aren't [fully?] supported by React due to how the style updates are currently done. I was unaware of this.
Either way, it's been fixed in react-virtualized for now and the fix will roll out with the next release.

Superb, thanks for that. Just been reading up and I don't feel so bad about not solving it myself now 👍
Build failing btw

Build is failing in CI because PhantomJS is crashing in the middle of tests:

I haven't had the time to look into it yet. It doesn't crash for me locally. (All tests pass.) If you have the time to look into it, I'd love a hand. Otherwise I'll get to it eventually.


Verify and Publish contract code on https://poaexplorer.com says "Bytecode does not match"

If you are reporting a problem with Token Wizard, please include the following information:
As I was trying to Verify and Publish contract code for the Token Contract deployed on POA Core net,
SafeMathLibExt was SUCCESSFULLY VERIFIED;
CrowdsaleTokenExt and others was NOT SUCCESSFUL, showing: "Bytecode does not match"
The Token Distribution was successful; and
The Crowdsale was successfully Finalized.
Please, how can I resolve the issue to get the contract code for CrowdsaleTokenExt and others Verified and Published on https://poaexplorer.com?
Which network did you use? (Mainnet, Kovan, Rinkeby, etc.)
POA Core net - using Custom RPC (Private Network):  https://poa.infura.io
If you were able to create it, what is the URL of your crowdsale?
https://wizard.oracles.org/crowdsale?addr=0xc739fAf883644f540EafB9eC3Fa52bcA82e6417c&networkID=99
Do you have screenshots showing the problem?
Yes, I do
Do you see errors in the dev console? If yes, please include a screenshot
To open the dev console in Google Chrome, press F12, or go to View -> Developer -> Developer Tools, and open the Console tab
If you see errors, please right click on them and "Save as..". Zip saved file and attach it to the Issue.
Your answer

@geoinheritance try to verify your smart-contract in BlockScout Alpha blockchain explorer: https://core-alpha.poaexplorer.com/en/addresses/0xc739fAf883644f540EafB9eC3Fa52bcA82e6417c/contract_verifications/new and please let me know

Hi Victor,
Thanks for your support.
Unfortunately, the link (URL) that you sent to me did not work. It returned
error message in red colour:
"there was an error validating your contract, please try again."
On Wed, 12 Sep 2018 at 10:46, Victor Baranov<EMAIL_ADDRESS>wrote:

@geoinheritance https://github.com/geoinheritance try to verify your
smart-contract in BlockScout Alpha blockchain explorer:
https://core-alpha.poaexplorer.com/en/addresses/0xc739fAf883644f540EafB9eC3Fa52bcA82e6417c/contract_verifications/new
and please let me know
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poanetwork/token-wizard/issues/1056#issuecomment-420583493,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AlkiChMCnA9J7pRrdN0WWLIUGZ_XJleLks5uaNfagaJpZM4VYQgu
.

Relates to https://github.com/poanetwork/token-wizard/issues/1181


[CC] configue_tensorflow.sh should not delete tensorflow directory if script fails

It takes ~2 hours for TF to compile, it's not nice to have that all thrown away because the copy fails at the very end.

We should probably just remove that rm -rf from the script altogether.

the temp folder is still deleted
https://github.com/tensorflow/minigo/blob/master/cc/configure_tensorflow.sh#L10

Well yes, the configuration & build process writes a bunch of stuff into unknown locations in the tmp_dir. If you don't delete them, parts of the install process will fail. One step that I remember off the top of my head is here: https://github.com/tensorflow/minigo/blob/d50b7a56e8b24286072ed8389843a843f886ca0c/cc/configure_tensorflow.sh#L60
My assumption was that if you were trying to continue from a failed install, you'd comment out the earlier steps. In general, I don't think it's wise to attempt to make the configure script be magically resumable from any point.


Prevent addLineItem method in Transaction request to override the previous added line item

This will allow multiple line items to be added without overriding themselves

@nikathone Hm, I think we should add test coverage for this. I can push it up.


fix: :fire: update settings

:tada: This PR is included in version 0.19.0-development.10 :tada:
The release is available on:

npm package (@development dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 0.20.1-development.1 :tada:
The release is available on:

npm package (@development dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 0.20.1-rc.1 :tada:
The release is available on:

npm package (@testnet dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 0.20.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


ovs dpdk: Add support of n_rxq_desc and n_txq_desc

Add support of n_rxq_desc and n_txq_desc for OVS DPDK. Please refer
to manpage of ovs-vswitchd.conf.db for detail.
Example yaml:
---
interfaces:
- name: ovs0
  type: ovs-interface
  state: up
  dpdk:
    devargs: "0000:af:00.1"
    rx-queue: 100
    n-rxq-desc: 1024
    n-txq-desc: 2048
- name: br0
  type: ovs-bridge
  state: up
  bridge:
    options:
      datapath: "netdev"
    port:
    - name: ovs0
ovs-db:
  other_config:
    dpdk-init: "true"

Unit test case and integration test case included.

Wait NetworkManager RFE: https://bugzilla.redhat.com/show_bug.cgi?id=2156385

NM has confirmed the dbus API will be the same as this PR used.


Mention updating CHANGELOG in releasing instruction.

Codecov Report

Merging #1181 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1181      +/-   ##
============================================
- Coverage     82.03%   82.02%   -0.02%
  Complexity     1226     1226
============================================
  Files           192      192
  Lines          5929     5929
  Branches        551      551
============================================
- Hits           4864     4863       -1
  Misses          918      918
- Partials        147      148       +1

Impacted Files
Coverage Δ
Complexity Δ

...census/implcore/trace/export/SpanExporterImpl.java
96.66% <0%> (-1.67%)
7% <0%> (ø)

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 a8c9f54...7f054a0. Read the comment docs.

Thanks!


tmux configuration: set style -g with bold attribute changes colors

Hi there!
I'm using MacOS Mojave with tmux 2.8 and alacritty.
While configuring tmux in ~/.tmux.conf I discovered that trying to set the bold attribute (e.g. setg status-style fg=white,bold) changes the other colors set for that element.
Without bold:

With bold:

Strangely enough the bold option works for window configuration settings (i.e. setw -g window-status-current-style fg=white,bold,bg=blue) works as expected.
To make sure this was an alacritty issue, I opened up my Terminal app and ran tmux. Sure enough:

Ignoring the messed up coloring, the text is definitely not grayscale, and it is bold.
Relevant settings and variables:

TERM within tmux: screen-256color
TERM outside of tmux: xterm-256color. I tried changing this to screen-256color in the Alacritty settings (and, separately, in my bash_profile), but it did not make a difference.
.tmux.conf

# Colors and Styling

# full 256 colors
set -g default-terminal "screen-256color"

# better status line colors
set -g status-style fg=white,bold,bg=colour8
#
# set the color of the window list
setw -g window-status-style fg=cyan,bg=colour8
#
# set colors of the active window
setw -g window-status-current-style fg=white,bold,bg=blue
#
# colors for pane borders
setw -g pane-border-style fg=green,bg=black
setw -g pane-active-border-style fg=white,bg=yellow
#
# active pane normal, others shaded out
setw -g window-active-style fg=colour12,bg=colour8
setw -g window-style fg=colour10,bg=colour8
#
# command / message line
set -g message-style fg=white,bold,bg=colour8

# status line left side to show Session:window:pane
set -g status-left-length 40
set -g status-left '#[fg=green]Session: #S #[fg=yellow]#I #[fg=cyan]#P'

# status line right side: date/time
set -g status-right '#[fg=colour15] %d %b %R'

Relevant color/font settings in alacritty.yml (I'm using Solarized Dark):
# If `true`, bold text is drawn using the bright color variants.
draw_bold_text_with_bright_colors: true

colors:
  # Default colors
  primary:
    background: '0x002b36' # base03
    foreground: '0x839496' # base0

  # Normal colors
  normal:
    black:   '0x073642' # base02
    red:     '0xdc322f' # red
    green:   '0x859900' # green
    yellow:  '0xb58900' # yellow
    blue:    '0x268bd2' # blue
    magenta: '0xd33682' # magenta
    cyan:    '0x2aa198' # cyan
    white:   '0xeee8d5' # base2

  # Bright colors
  bright:
    black:   '0x002b36' # base03
    red:     '0xcb4b16' # orange
    green:   '0x586e75' # base01
    yellow:  '0x657b83' # base00
    blue:    '0x839496' # base0
    magenta: '0x6c71c4' # violet
    cyan:    '0x93a1a1' # base1
    white:   '0xfdf6e3' # base3

Thanks in advance!

# If true, bold text is drawn using the bright color variants.
draw_bold_text_with_bright_colors: true

This is a common convention used by most linux terminals I'm aware of. If you do not like it, try setting this to false?

@chrisduerr Now that you mention that...I realize the configuration is doing exactly what it's supposed to. I just didn't read the hex codes close enough during copy-pasta. 😝


Add support for worker clean-up to single-machine and Mesos batch systems

Put config.workDir and config.workflowID into a namedtuple in AbstractBatchSystem.
Pass this to executor
add a cleanup method in AbstractBatchSystem that uses this info.

I modified the title a bit. Hope you don't mind. I also propose that we add a supportsWorkerCleanup() method to ABS that returns False. Mesos and SingleMachine would override it to return True. setupToil() would then ensure that CacheFileStore is only used on BSs where that method returns True. Sounds good?

Then it would wait till the batch system is set up to fail with an error. Can probably return sooner with an
if batchsystem in set(non-supported) and useSharedCache is True:
    exit with message

the batchsystem in set() can probably be a static method in abstractbatchsystem that does the same thing if you'd like to keep the logic there.


NACK xds updates requiring client certificates when no validation certificate provider instance is mentioned

Based on discussion at https://github.com/grpc/proposal/pull/243

Issues: #23597, #26595

Thanks for reviewing!


Not showing as a user who viewed story

I've found that when I use this library to view stories, I don't show up in the story poster's "people who viewed your story" section. Is this as it's designed to be, and is there a way to change this?

It's by design. It's not possible right now to mark them as seen but the endpoint responsible for it seems to be supported by the API dependency so it could be added

Thanks! Maybe I'll add the functionality and submit a PR with the added functionality, if you'd be open to it

No problem. but make it an optional functionality through the use of an extra argument (name at your discretion)


KB buttons

📚 Context
Buttons and what gets nested inside them continues to be a repeat theme in the forum, stack exchange, etc. I feel like a broken record with as many times as I've typed:

Buttons aren't stateful. They return True on the page load resulting from their click, and then go back to False.

It would be helpful (and a huge time saver) to have a more robust "button repository" to point to.
🧠 Description of Changes
This PR proposes a new KB article all about buttons will a long list of examples showing working and non-working logical patterns. It begins with:
## TLDR

Buttons do not retain state. They return `True` on the page load resulting from
their click and then immediately go back to `False`. If you nest something
inside a button, then it will go away as soon as the user takes their next
action (because the page reloads and the button becomes `False`).

[X] Menu/Navigation updated for users to access article
[ ] Reorganize/re-categorize "Using Streamlit" section of KB to be more accessible/intuitive
[ ] Host some of the code snippets for interactivity?
[ ] Update the st.button page with redirect to new KB article as appropriate

💥 Impact
Size:

[X] Not small

🌐 References
This is cheeky, but largely correct: the forum... 😝
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.

@snehankekre I've marked this as a draft to get some feedback. (@jrieke do you want to be pinged too on these bigger ideas?) I'm not 100% in love with each and every example and I think a couple could be tweaked for clarity, but this is a first pass to get the idea "on paper" and get the ball rolling.
I'd like to also reorganize the "Using Streamlit" section as the long list of articles doesn't feel very accessible. Maybe most people are getting to those articles through search, but it would be nice to have some grouping/categorization of the articles. I thought it might even be nice to create a separate "widgets" section if there are other widgets that could use a longer-winded explanation and plethora of toy examples beyond their basic API doc page.
Preview

@MathCatsAnd IIUC the recent feedback from KM has yet to incorporated here. Once that's done, I'll do a final review and merge 😄

Whoops, forgot to push. Done now.


Add notes for february, march and april 2019

Based on this issue we want to continue publish the meeting notes.
I have separated each meeting from the Dropbox Paper document and created one file for each day.

@gruberb Thank you! Would you mind also making a post on https://internals.rust-lang.org/, mentioning that these minutes are available and linking to the directory? (In the future, whenever we complete a meeting we should post a link to its minutes to internals and twitter)

@aturon Will do. I have the new PR open with the notes from yesterday.
How should the format be for the forum? I see that some working groups have one thread which they update (https://internals.rust-lang.org/t/compiler-team-triage-meeting/9803/2). Should we do the same?
And twitter: I would need access to the net-working-group account for this!


Is it available in the UK now?

I am an Insider, I have E5 and I can't see it. Tech support told me that it's only for US tenants, is that correct? Thanks - Kris.

Hello @KrisDeb-OptiIT. Can you please tell us to which article your question applies? This will help us route your issue to the correct writer/team. Thank you!

@KrisDeb-OptiIT - We appreciate any feedback that improves the content in the Microsoft docs but we haven't had any response from you so we are going to close this issue.
If there is a specific area of the docs that we can improve on, please feel free to open a new issue by clicking on the Feedback section on the specific Microsoft doc which is found at the bottom of the page. Thank you.


Add generic Korifi error

Thanks for contributing to cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:

A short explanation of the proposed change:
Add an error for use in Korifi.

An explanation of the use cases your change solves
This will prevent confusion if other parties attempt to use the 420000 error code.

[x] I have reviewed the contributing guide

[x] I have viewed, signed, and submitted the Contributor License Agreement

[x] I have made this pull request to the main branch

[x] I have run all the unit tests using bundle exec rake

[x] I have run CF Acceptance Tests

@sethboyles @Gerg
This is a case where it was actually nice to have https://github.com/cloudfoundry-attic/errors be a separate repo. But anyways, how do y'all feel about us "reserving" this error block in v2.yml? It's unlikely CCNG will ever produce its own Korifi errors, but we want to make sure something else doesn't claim this block since we've started using it.

Seems OK to me.


[0.21] Backport of #509

Backport of #509

@slinkydeveloper you need to run update-codegen.sh I guess?


Added a Basic Code Solution to "False Bouncer" challenge

Added a Basic Code Solution to the "False Bouncer" challenge in "Basic Algorithm Scripting" in the JavaScript Certification path.
I have also provided the Code Explanation and Relevant Links.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x] My changes do not use shortened URLs or affiliate links.

Closes #XXXXX

Congrats @merkur0 on your first pull request (PR)! 🎉
Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


one bigcouch node down input process stuck

i use bigcouch as my project...
i open  3 node ( default )
everything fine until one node suddenly down ( one server crash )
why if one node down, input process stuck...?
i read the documentation...
i try to set N = 1 ( replicate constant ) , R = 1 (read qourum constant ), and W = 1 (write qourum constant)...
i think my conf mean if 1 write and 1 replicate happen to server that's enaugh to return 201 status.

One third of your document ids will map to the node that is down. Since you have reduced fault-tolerance from three copies to only one copy, BigCouch is unable to tolerate the single node being down. I suggest using the default setting of three copies and a read and write quorum of two if you wish to tolerate the loss of any single node.

Hi there. Setting N=R=W=1 doesn't work that way. In fact, it does the opposite of what you intend: it removes all fault-tolerance from the cluster. What's probably happening here is that the particular document that fails has been automatically mapped to be stored on the node that is down. Since there are no other writes/reads possible (or needed), the input fails.
Your input process should work, with one node down, if you use the default configuration (N=3 & R=W=2).

i try to use timanglade conf (N=3 & R=W=2)...
but this setting not different with my setting, it still made stuck on futon if i operate input process
this 3 node i input in "nodes" database:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>and this error i get if one node down...
{timeout,[{{shard,undefined,'bigcouch@bigserver1.server1',undefined,undefined, #Ref<<IP_ADDRESS>42>}, ok}, {{shard,undefined,'bigcouch@bigserver2.server2',undefined,undefined, #Ref<<IP_ADDRESS>43>}, ok}, {{shard,undefined,'bigcouch@bigserver3.server3',undefined,undefined, #Ref<<IP_ADDRESS>44>}, nil}]}
need 10 minutes until this error come out...
this happen to with my node.js apps, and made my node.js apps stuck for 10 minutes

the problem solved...
it stuck because i input database... not document....
if i input database on one node down ( from three nodes) condition, it will stuck...
different if i input document on one node down condition... document i input success...
thanks for support... and sorry to bother you and waste your time...
nb: i'm sorry my english bad... i still learn english language...

Hi,
Database creation and deletion requires all nodes to be online in the current release (0.3.1). This has been fixed in the upcoming release (0.4).