Ansible's output is missing from molecule commands

Issue Type

Bug report

Molecule and Ansible details
$ ansible --version && molecule --version
ansible [core 2.11.4]
  config file = None
  configured module search path = ['/home/redacted/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/redacted/kvk/vault/ansible/roles/test/venv/lib/python3.8/site-packages/ansible
  ansible collection location = /home/redacted/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/redacted/kvk/vault/ansible/roles/test/venv/bin/ansible
  python version = 3.8.10 (default, Jun  2 2021, 10:49:15) [GCC 9.4.0]
  jinja version = 3.0.1
  libyaml = True
molecule 3.4.0 using python 3.8
    ansible:2.11.4
    delegated:3.4.0 from molecule

Molecule installation method (one of):

pip (venv)

python3 -m venv venv && source venv/bin/activate
pip install molecule==3.4.0

Ansible installation method (one of):

pip

# above venv still activated
pip install ansible==4.4.0

Detail any linters or test runners used:
molecule init role test
cd test
molecule test

Desired Behavior
INFO     default scenario test matrix: dependency, lint, cleanup, destroy, syntax, create, prepare, converge, idempotence, side_effect, verify, cleanup, destroy
INFO     Performing prerun...
WARNING  Failed to guess project directory using git:
INFO     Guessed /moleculetest as project root directory
WARNING  Computed fully qualified role name of moleculetest does not follow current galaxy requirements.
Please edit meta/main.yml and assure we can correctly determine full role name:

galaxy_info:
role_name: my_name  # if absent directory name hosting role is used instead
namespace: my_galaxy_namespace  # if absent, author is used instead

Namespace: https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespace-limitations
Role: https://galaxy.ansible.com/docs/contributing/creating_role.html#role-names

As an alternative, you can add 'role-name' to either skip_list or warn_list.

INFO     Using /home/runner/.cache/ansible-lint/4b824e/roles/moleculetest symlink to current repository in order to enable Ansible to find the role using its expected full name.
INFO     Added ANSIBLE_ROLES_PATH=~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles:/home/runner/.cache/ansible-lint/4b824e/roles
INFO     Running default > dependency
WARNING  Skipping, missing the requirements file.
WARNING  Skipping, missing the requirements file.
INFO     Running default > lint
INFO     Lint is disabled.
INFO     Running default > cleanup
WARNING  Skipping, cleanup playbook not configured.
INFO     Running default > destroy

PLAY [Destroy] *****************************************************************

TASK [Populate instance config] ************************************************
ok: [localhost]

TASK [Dump instance config] ****************************************************
skipping: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

INFO     Running default > syntax
# ... etcetera ...

Actual Behaviour
Notice how everything after "INFO     Running default > destroy" is silent. The PLAY, TASK instructions are missing.
DEBUG    Validating schema /home/redacted/kvk/vault/ansible/roles/test/test/molecule/default/molecule.yml.
INFO     default scenario test matrix: dependency, lint, cleanup, destroy, syntax, create, prepare, converge, idempotence, side_effect, verify, cleanup, destroy
INFO     Performing prerun...
WARNING  Failed to guess project directory using git:
INFO     Guessed /home/redacted/kvk/vault/ansible/roles/test/test as project root directory
WARNING  Computed fully qualified role name of test does not follow current galaxy requirements.
Please edit meta/main.yml and assure we can correctly determine full role name:

galaxy_info:
role_name: my_name  # if absent directory name hosting role is used instead
namespace: my_galaxy_namespace  # if absent, author is used instead

Namespace: https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespace-limitations
Role: https://galaxy.ansible.com/docs/contributing/creating_role.html#role-names

As an alternative, you can add 'role-name' to either skip_list or warn_list.

INFO     Using /home/redacted/.cache/ansible-lint/4165d8/roles/test symlink to current repository in order to enable Ansible to find the role using its expected full name.
INFO     Added ANSIBLE_ROLES_PATH=~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles:/home/redacted/.cache/ansible-lint/4165d8/roles
INFO     Running default > dependency
WARNING  Skipping, missing the requirements file.
WARNING  Skipping, missing the requirements file.
INFO     Running default > lint
INFO     Lint is disabled.
INFO     Running default > cleanup
WARNING  Skipping, cleanup playbook not configured.
INFO     Running default > destroy
DEBUG: ANSIBLE ENVIRONMENT:
ANSIBLE_COLLECTIONS_PATH: /home/redacted/.cache/molecule/test/default/collections:/home/redacted/.ansible/collections:/usr/share/ansible/collections:/etc/ansible/collections
ANSIBLE_CONFIG: /home/redacted/.cache/molecule/test/default/ansible.cfg
ANSIBLE_FILTER_PLUGINS: /home/redacted/kvk/vault/ansible/roles/test/venv/lib/python3.8/site-packages/molecule/provisioner/ansible/plugins/filter:/home/redacted/.cache/molecule/test/default/plugins/filter:/home/redacted/kvk/vault/ansible/roles/test/test/plugins/filter:/home/redacted/.ansible/plugins/filter:/usr/share/ansible/plugins/filter
ANSIBLE_FORCE_COLOR: '1'
ANSIBLE_LIBRARY: /home/redacted/kvk/vault/ansible/roles/test/venv/lib/python3.8/site-packages/molecule/provisioner/ansible/plugins/modules:/home/redacted/.cache/molecule/test/default/library:/home/redacted/kvk/vault/ansible/roles/test/test/library:/home/redacted/.ansible/plugins/modules:/usr/share/ansible/plugins/modules
ANSIBLE_ROLES_PATH: /home/redacted/.cache/molecule/test/default/roles:/home/redacted/kvk/vault/ansible/roles/test:/home/redacted/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles:~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles:/home/redacted/.cache/ansible-lint/4165d8/roles

DEBUG: MOLECULE ENVIRONMENT:
MOLECULE_DEBUG: 'True'
MOLECULE_DEPENDENCY_NAME: galaxy
MOLECULE_DRIVER_NAME: delegated
MOLECULE_ENV_FILE: /home/redacted/kvk/vault/ansible/roles/test/test/.env.yml
MOLECULE_EPHEMERAL_DIRECTORY: /home/redacted/.cache/molecule/test/default
MOLECULE_FILE: /home/redacted/.cache/molecule/test/default/molecule.yml
MOLECULE_INSTANCE_CONFIG: /home/redacted/.cache/molecule/test/default/instance_config.yml
MOLECULE_INVENTORY_FILE: /home/redacted/.cache/molecule/test/default/inventory/ansible_inventory.yml
MOLECULE_PROJECT_DIRECTORY: /home/redacted/kvk/vault/ansible/roles/test/test
MOLECULE_PROVISIONER_NAME: ansible
MOLECULE_SCENARIO_DIRECTORY: /home/redacted/kvk/vault/ansible/roles/test/test/molecule/default
MOLECULE_SCENARIO_NAME: default
MOLECULE_STATE_FILE: /home/redacted/.cache/molecule/test/default/state.yml
MOLECULE_VERIFIER_NAME: ansible
MOLECULE_VERIFIER_TEST_DIRECTORY: /home/redacted/kvk/vault/ansible/roles/test/test/molecule/default/tests

DEBUG: SHELL REPLAY:
ANSIBLE_COLLECTIONS_PATH=/home/redacted/.cache/molecule/test/default/collections:/home/redacted/.ansible/collections:/usr/share/ansible/collections:/etc/ansible/collections ANSIBLE_CONFIG=/home/redacted/.cache/molecule/test/default/ansible.cfg ANSIBLE_FILTER_PLUGINS=/home/redacted/kvk/vault/ansible/roles/test/venv/lib/python3.8/site-packages/molecule/provisioner/ansible/plugins/filter:/home/redacted/.cache/molecule/test/default/plugins/filter:/home/redacted/kvk/vault/ansible/roles/test/test/plugins/filter:/home/redacted/.ansible/plugins/filter:/usr/share/ansible/plugins/filter ANSIBLE_FORCE_COLOR=1 ANSIBLE_LIBRARY=/home/redacted/kvk/vault/ansible/roles/test/venv/lib/python3.8/site-packages/molecule/provisioner/ansible/plugins/modules:/home/redacted/.cache/molecule/test/default/library:/home/redacted/kvk/vault/ansible/roles/test/test/library:/home/redacted/.ansible/plugins/modules:/usr/share/ansible/plugins/modules ANSIBLE_ROLES_PATH=/home/redacted/.cache/molecule/test/default/roles:/home/redacted/kvk/vault/ansible/roles/test:/home/redacted/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles:~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles:/home/redacted/.cache/ansible-lint/4165d8/roles MOLECULE_DEBUG=True MOLECULE_DEPENDENCY_NAME=galaxy MOLECULE_DRIVER_NAME=delegated MOLECULE_ENV_FILE=/home/redacted/kvk/vault/ansible/roles/test/test/.env.yml MOLECULE_EPHEMERAL_DIRECTORY=/home/redacted/.cache/molecule/test/default MOLECULE_FILE=/home/redacted/.cache/molecule/test/default/molecule.yml MOLECULE_INSTANCE_CONFIG=/home/redacted/.cache/molecule/test/default/instance_config.yml MOLECULE_INVENTORY_FILE=/home/redacted/.cache/molecule/test/default/inventory/ansible_inventory.yml MOLECULE_PROJECT_DIRECTORY=/home/redacted/kvk/vault/ansible/roles/test/test MOLECULE_PROVISIONER_NAME=ansible MOLECULE_SCENARIO_DIRECTORY=/home/redacted/kvk/vault/ansible/roles/test/test/molecule/default MOLECULE_SCENARIO_NAME=default MOLECULE_STATE_FILE=/home/redacted/.cache/molecule/test/default/state.yml MOLECULE_VERIFIER_NAME=ansible MOLECULE_VERIFIER_TEST_DIRECTORY=/home/redacted/kvk/vault/ansible/roles/test/test/molecule/default/tests

COMMAND: ansible-playbook --diff --inventory /home/redacted/.cache/molecule/test/default/inventory --skip-tags molecule-notest,notest /home/redacted/kvk/vault/ansible/roles/test/test/molecule/default/destroy.yml
INFO     Running default > syntax
# ... etcetera ...

The destroy stage is only an example. I pasted it here so I could truncate the rest. The behaviour is the same for all molecule stages (create, prepare, converge, idempotence, verify). Molecule is now unusable as a test framework, because I cannot see any errors from my role. For example, a failed task looks like this:
# ... etc
COMMAND: ansible-playbook --diff --inventory /home/redacted/.cache/molecule/test/default/inventory --skip-tags molecule-notest,notest /home/redacted/kvk/vault/ansible/roles/test/test/molecule/default/converge.yml
CRITICAL Ansible return code was 4, command was: ['ansible-playbook', '--diff', '--inventory', '/home/redacted/.cache/molecule/test/default/inventory', '--skip-tags', 'molecule-notest,notest', '/home/redacted/kvk/vault/ansible/roles/test/test/molecule/default/converge.yml']
WARNING  An error occurred during the test sequence action: 'converge'. Cleaning up.
INFO     Running default > cleanup
# ... etc

However, when I copy-paste the COMMAND, I do get ansible's output. Just to be clear: fixing the ansible error is not the point here. The point is that the whole error message is missing from molecule's output.
$ ansible-playbook --diff --inventory /home/redacted/.cache/molecule/test/default/inventory --skip-tags molecule-notest,notest /home/redacted/kvk/vault/ansible/roles/test/test/molecule/default/converge.yml

PLAY [Converge] *************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ******************************************************************************************************************************************************************************************************
fatal: [instance]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: Could not resolve hostname instance: Name or service not known", "unreachable": true}

PLAY RECAP ******************************************************************************************************************************************************************************************************************
instance                   : ok=0    changed=0    unreachable=1    failed=0    skipped=0    rescued=0    ignored=0

Am I missing something here?

Duplicate of https://github.com/ansible-community/molecule/issues/3232


[Bug]: Link profile

Describe the bug
When the "+Add Link" button is tapped several times, it no longer responds.
Reproduce

Go to 'your profil'
Click on '+ Add Link' few time
See error

Screenshots / Recording
No response
Operating system
Android, iOS
Bitkit version
v46
Log output
No response

https://github.com/synonymdev/bitkit/assets/46056211/a3216d4f-e90f-4e6d-ad97-382759fefa45
Here a video of the issue. Tested with v89 on GrapheneOS

Fixed

Can not reproduce


Publishing 1.1.0 to Maven Central

It looks like the last version available from Maven Central is 1.0.0, but the GitHub repo seems to already have 1.1.0. Any chance you can push the 1.1.0 release to Maven Central as well? Thanks

@mdanielolsson I don't think I have access to this project in Maven Central. Can you release it?

The release task should have deployed 1.1.0, but maybe something was missing? I don't have access to Nexus anymore, but maybe someone could check if it needs an approval or something? @pokerjocke70 might be able to help if you can't find it there @lukasz-kaminski.
Either way, the credentials for publishing are stored here, so if there's some tweak needed to the release script to have it auto publish that'd be the best way forward.

Any updates here @mdanielolsson @lukasz-kaminski ?

We are looking into it. Hopefully will be fixed today :)

Awesome, thanks Igor! 👍

Thanks everyone, I appreciate the help.


switched default cplex method from concurrent to barrier in cplex.opt

lgtm, with your permission @volker-krey, I will stack this on top of the hackathon PRs.

@volker-krey would you mind adding to the release notes as well?

ádded to hackathon-prs


Avoid adding redundant SubqueryAlias.

Which issue does this PR close?

Closes #4383.
Rationale for this change

What changes are included in this PR?

Merge SubqueryAlias.
Are these changes tested?

test

merge two alias.
merge three alias (optimize again after optimize self)

Are there any user-facing changes?

I think SubqueryAlias is just temp struct in the plan tree for scoping names. The SubqueryAlias should be removed totally from the plan tree at an early phase of the logical planing.

In physical plan, there is no SubqueryAlias either.  I think SubqueryAlias can be remove earlier to simply other logical rules.

I think SubqueryAlias is just temp struct in the plan tree for scoping names. The SubqueryAlias should be removed totally from the plan tree at an early phase of the logical planing by modifying the inner plan's qualify names.
Then the rest of the other logical rules do not need to deal with SubqueryAlias anymore.

Look like we can add it in planner.
When we add subquery alias, if child is subquery alias, we just need to change the name.
I don't have much preference for these two options.

wait for merge it. It will cause another bug could not be reproduced.

Converting to a draft so we don't accidentally merge it

More optimization https://github.com/apache/arrow-datafusion/pull/4484#issuecomment-1338696095
I will try to do include https://github.com/apache/arrow-datafusion/pull/4484#issuecomment-1338760893
It's from comment @mingmwang in #4484

I wonder if this PR is still relevant


SetUint64 doesn't work for math.MaxUint64

(In response to a note you left somewhere, we are using this package to build a math library for a cryptocurrency project.)
The problem is best illustrated by test code:
func TestConversion(t *testing.T) {
	x := decimal.WithContext(decimal.Context128).SetUint64(math.MaxUint64)
	y, ok := x.Uint64()
	if !ok {
		t.Error("failed to convert back")
	}
	if y != math.MaxUint64 {
		t.Errorf("conversion 'succeeded' but the value failed to make the round trip - got %d", y)
	}
}

func TestConversion2(t *testing.T) {
	x := decimal.WithContext(decimal.Context128).SetUint64(math.MaxUint64 - 1)
	i := decimal.WithContext(decimal.Context128).SetUint64(1)
	x.Add(x, i)
	y, ok := x.Uint64()
	if !ok {
		t.Error("failed to convert back")
	}
	if y != math.MaxUint64 {
		t.Errorf("conversion 'succeeded' but the value failed to make the round trip - got %d", y)
	}
}

The first function returns OK but then the result is 0, while the second function does the right thing, so it appears that attempting to SetUint64 with the maximum possible value is failing.

Thank you for letting me know!


Indentation of callbacks

Hi. This piece of code throws me an error of wrong indentation:
someFunction('very', 'very', 'long', 'parameters',
  'list', 'and', 'the', 'callback', function () {
  console.log('yep') // Expected indentation of 4 space characters but found 2.
}) // Expected indentation of 2 space characters but found 0.

While this is OK:
someFunction('very', 'very', 'long', 'parameters',
'list', 'and', 'the', 'callback', function () {
  console.log('yep')
})

However it's not very readable, especially when there are some real code with really long parameters written in multiple lines. I ran into this when I've been writing some middleware for koa.
I thought that maybe #208 is related to this, but it seems like it's something different.

This is probably a bug in eslint. If you're interested in getting this fixed, I recommend opening an issue on their bug tracker: https://github.com/eslint/eslint
The rule we use is: "indent": [2, 2, { "SwitchCase": 1 }]
Honestly, though, if I were you, I'd name the function in an argument list that long, so you can just refer to it in the list. Cleaner than inlining it.

Is it a bug though? I think that the first example looks wrong since the function body is indented the same as the parameter list. I think that it should be indented one more step...
someFunction('very', 'very', 'long', 'parameters',
  'list', 'and', 'the', 'callback', function () {
    console.log('yep')
  })

Well, maybe it's a little far-fetched example. So here is the actual code:
fst.transition(INIT, [isCmd('get'), doHavePermissions(),
isActive()], STARTED, function * (next) {
  // ...
})

It's a finite state transducer rule which says "If the state is INIT and the message complies to the list of filters, go to the state STARTED and execute following middleware". The array of filter can be long sometimes, but inlining it makes the rule easy to reason about. So, what I'm trying to say is that this scenario is still common.
Btw, I actually like the @LinusU suggestion. This is a way to go. However, allowing this as well as the second example from the post is not very intuitive.


api: new policy field for per filter config

Commit Message: api: new policy field for per filter config
Additional Description:
API only PR. This API is used to configure a policy that determine which name or value will be used as searching key of typed_per_filter_config.
It's just a initial idea. So it's open for suggestions and discussions.
Ref #12274 for more detailed context.
Risk Level: n/a.
Testing: n/a.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.

I personally still think that explicit configuration would be more clear. Give users the ability to control this searching behaviour. And this also keep the possibility to create more flexible searching policy in the future (e.g., get route level filter config by authentication/user info header).

@mattklein123
If the fallback policy is applied, as the comments of the API, when we try to get route level filter config of a filter at runtime, the custom config name (HttpFilter.name) will be used first to search config from the typed_per_filter_config. And if we get nothing by the custom config name, then we will use the canonical filter name try again.
For most of current users, one time additional hash searching for every filter is necessary.
But it will not break most of current users except they use one filter's canonical filter name as another filter's custom config name. This exception is highly unlikely to happen.
So, yeah, fallback policy can covers most of known cases. But I personally prefer the explict configuration rather than implicit fallback. 😂 I always want everything can be controlled by the configuration.

Of course, #8659 also a reason of that why I  add this field.

Can we add explicit config later if it's really needed? Any config we add adds cost and it's not clear to me that there is enough benefit here? WDYT?
/wait

I hear that you are saying that you prefer this behavior to be explicitly configurable, but I'm not really hearing you give a compelling reason for that preference.

Part of the reason for this is my personal preference. Part of the reason is the duplication of searches. The last part is because I fear we may never be able to remove the legacy behaviour.
But since we all agree that the current configuration is too heavy, I will respect the community's opinion.

Part of the reason is the duplication of searches. The last part is because I fear we may never be able to remove the legacy behaviour.

Wouldn't the runtime knob I suggested address those two concerns?

Wouldn't the runtime knob I suggested address those two concerns?

🤔 If we can never remove this legacy behaviour, then we need keep the runtime knob forever. I usually use r

untime

convert this to draft but keep it open for #8659.


[Important] The current website is about to enter maintenance mode to aid with v3 launch

TL;DR; At the end of Jan 2021, all tracks will enter v3 staging mode. Updates will no longer sync with the current live website, but instead sync with the staging website. The Ceylon section of the v3 repo will be extracted and PR'd into this track (if appropriate). Further issues and information will follow over the coming weeks to prepare Ceylon for the launch of v3.
Over the last 12 months, we've all been hard at work developing Exercism v3. Up until this point, all v3 tracks have been under development in a single repository - the v3 repository. As we get close to launch, it is time for us to explode that monorepo back into the normal track repos. Therefore, at the end of this month (January 2021), we will copy the v3 tracks contents from the v3 repository back to the corresponding track repositories.
As v3 tracks are structured differently than v2 tracks, the current (v2) website cannot work with v3 tracks. To prevent the v2 website from breaking, we'll disable syncing between track repositories and the website. This will effectively put v2 in maintenance mode, where any changes in the track repos won't show up on the website. This will then allow tracks to work on preparing for the Exercism v3 launch.
Where possible, we will script the changes needed to prepare tracks for v3. For any manual changes that need to be happening, we will create issues on the corresponding track repositories. We will be providing lots of extra information about this in the coming weeks.
We're really excited to enter the next phase of building Exercism v3, and to finally get it launched! 🙂

As of today, the website has entered maintenance mode.

As of today, the website has entered maintenance mode.

With Exercism v3 just being released, tracks are no longer in maintenance mode and are active again.
This means that changes made to this track will once again show on the website.
Thanks for being patient with us and enjoy Exercism v3!


cert-manager installation fails on PSP enabled k8s 1.19.x clusters

Describe the bug:
On a PodSecurityPolicy enabled k8s 1.19.x when you install the helm chart of cert-manager no pods start.
cert-manager   0s          Warning   FailedCreate              replicaset/cert-manager-57b65b7fc
(combined from similar events): Error creating: pods "cert-manager-57b65b7fc-j24wn" is forbidden:
PodSecurityPolicy: unable to validate pod:
[pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/cert-manager]: Forbidden:
runtime/default is not an allowed seccomp profile. Valid values are docker/default]

Expected behaviour:
I expected that the shipped PSP configs in helm chart, make sure that the pods run without issues.
Steps to reproduce the bug:
Start a minikube cluster:
minikube start \
  --kubernetes-version v1.19.2 \
  --cpus 4 --memory 5000 \
  --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCondition,Priority,DefaultTolerationSeconds,DefaultStorageClass,StorageObjectInUseProtection,PersistentVolumeClaimResize,RuntimeClass,CertificateApproval,CertificateSigning,CertificateSubjectRestriction,DefaultIngressClass,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodSecurityPolicy \
  --v 10 "${args}"

Once the machine is up and trying to come up run following command:
kubectl apply -f https://raw.githubusercontent.com/kinvolk/lokomotive/master/assets/charts/control-plane/kubernetes/templates/psp-privileged.yaml

Above PSP is for the control plane in minikube.
Now install cert-manager using helm 3:
kubectl create namespace cert-manager
helm repo add jetstack https://charts.jetstack.io
helm repo update
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.2/cert-manager.crds.yaml
helm install \
   cert-manager jetstack/cert-manager \
   --namespace cert-manager \
   --version v1.0.2 \
   --set global.podSecurityPolicy.enabled=true \
   --set global.podSecurityPolicy.useAppArmor=false

Anything else we need to know?:
I tried following mitigation steps which work:
kubectl annotate --overwrite psp cert-manager \
    seccomp.security.alpha.kubernetes.io/allowedProfileNames=docker/default,runtime/default
kubectl annotate --overwrite psp cert-manager-cainjector \
    seccomp.security.alpha.kubernetes.io/allowedProfileNames=docker/default,runtime/default
kubectl annotate --overwrite psp cert-manager-webhook \
    seccomp.security.alpha.kubernetes.io/allowedProfileNames=docker/default,runtime/default

Even after applying above fix if things don't come up then simply run:
kubectl -n cert-manager delete rs --all

Environment details::

Kubernetes version: v1.19.2.
Cloud-provider/provisioner: minikube
cert-manager version: v1.0.2.
Install method (e.g. helm or static manifests): helm.

/kind bug

Seems to be related to https://github.com/jetstack/cert-manager/blob/d33481da6a1faf744ac5ee5a4956dd9cc39c25c5/deploy/charts/cert-manager/templates/webhook-psp.yaml#L16

@meyskens this is not related to apparmor, because as mentioned in the helm install instructions I am disabling it by using flag --set global.podSecurityPolicy.useAppArmor=false.

Also if apparmour is applied to a pod on a non debian machine the pod stays in Blocked state. Here the pod is not passing the admission controller stage.

This should be related to https://github.com/kubernetes/kubernetes/issues/95817.

It looks like this has been fixed upstream in kubernetes for 1.20. Is there any update on getting a fix in for this in for 1.19?

Going to close this as it is an upstream issue.
/close


Aurora wont update Equalizer when changing Audio Output in soundcard driver options

What are you experiencing an issue with?

[x] Aurora Lighting issue
[x] Other, (I have a soundcard where i can switch between my speakers (connected directly to the soundcard) and my headphones (connected to the front audio jack)

What kind of an issue is it?

[x] Visual bug
[x] Other, (Equalizer profile wont update anymore and is stuck with the last audio that was played when i change the audio output)

Expected behavior:
The equalizer profile shouldn't stop working when i switch between them.
Actual behavior:
When i change from speakers to headphones the equalizer profile won't get the sound anymore and is stuck with the last audio signal (screenshot will explain it better, i guess), i need to restart Aurora to get it working again.
How often does this problem occur?
It occurs when i switch between speakers and headphones e.g. for playing csgo or something
Please describe the steps to reproduce this issue:
The issue can be reproduced by doing following steps:
(I have a Sound Blaster Z soundcard and there i can switch between speakers and headphones.

Aurora is started, and there is an equalizer profile activated
Hearing any music or a video
Switch between speakers and headphones, if your soundcard has a option like mine.

What is the version of Aurora you are experiencing this issue with?
My version is the latest one v0.6.0b.
Please include any logs, screenshots, or files that are related to this issue:
Music is on, Audio Output on Speakers
Music is off, Audio Output changed to Headphones, Equalizer is stuck

I am pretty sure that on dev branch, I made it detect currently active sound source and switch to it. I'll double check later.

Okay, sorry for the duplicate. It wasn't fixed in the newest version, it seemed a bit more bugged in general but i think that was my fault. The booth versions act mostly the same.

Try v0.6.2b, closing for now


[Bug]: System.TimeoutException: 'Could not retrieve latest GPS coordinates to be able to determine geofence current state' for iOS

Component/Nuget
GPS or Geofencing (Shiny.Locations)
What operating system(s) are effected?

[X] iOS (13+ supported)
[ ] Mac Catalyst
[ ] Android (8+ supported)

Version(s) of Operation Systems
iOS 15, iOS 18
Hosting Model

[X] MAUI
[ ] Native/Classic Xamarin
[ ] Manual

Steps To Reproduce

Create a new project with the Shiny template in Visual Studio with Geofencing

Add new geofence

Request state of geofence

Expected Behavior
Expected behavior is for this to show if the phone is inside or outside the monitored geofence.
Actual Behavior
This results in an exception: System.TimeoutException: 'Could not retrieve latest GPS coordinates to be able to determine geofence current state' when running on iOS.
Exception or Log output
System.TimeoutException: 'Could not retrieve latest GPS coordinates to be able to determine geofence current state'
Code Sample
https://github.com/hannerygge/Project2
Code of Conduct

[X] I have supplied a reproducible sample that is NOT FROM THE SHINY SAMPLES!
[X] I am a Sponsor OR I am using the LATEST stable/beta version from nuget (v3.0 stable - ALPHAS are not taking issues - Sponsors can still send v2 issues)
[X] I am Sponsor OR My GitHub account is 30+ days old
[X] I understand that if I am checking these boxes and I am not actually following what they are saying, I will be removed from this repository!

This isn't a bug.  That call times out after 20 seconds of waiting for the GPS reply.  If the GPS can't get a fix, this will happen.  You can see the code here: https://github.com/shinyorg/shiny/blob/da982cac6edc2d7eb199c7fdafa181c82fa21125/src/Shiny.Locations/Platforms/Apple/GeofenceManager.cs#L89
I could extend the timeout or base it completely off the cancellation token if you think that would help!?

Also when viewing the source in Vs2022, it complains that CLCircularRegion is deprecated - https://developer.apple.com/documentation/corelocation/clcircularregion , but im not sure thats relevant here.

It's only recently been marked deprecated.  I haven't updated to whatever the new mechanism is.  It won't be required until iOS 19 likely.

Also another note, since it can't get the GPS fix, the geofencing is also not working, OnStatusChanged is never triggered even though the geofence shows up in the list for monitored regions.

Also another note, since it can't get the GPS fix, the geofencing is also not working, OnStatusChanged is never triggered even though the geofence shows up in the list for monitored regions.

Getting the current status of the geofence doesn't have anything to do with the delegate firing.  I'm running geofencing on iOS without issues right now.  What is your test case?  Are you testing in sim?  Are you actually testing with a device?

I am testing on a device.


Getting IP from libvirt via network_interface.0.addresses.0 doesn't work consistently

Version Reports:
Distro  version of host:
Ubuntu 17.04
Terraform Version Report
Terraform v0.10.5
Libvirt version
2.5.0
terraform-provider-libvirt plugin version (git-hash)
23635373aed10aab286a2436459670b686b581bb

Description of Issue/Question
Setup
variable num_workers {
  default = 4
}
resource "libvirt_network" "tf" {
   name = "tf"
   domain = "tf.local"
   mode = "nat"
   addresses = ["<IP_ADDRESS>/24"]
}

resource "libvirt_volume" "centos7" {
  name = "centos7"
  source = "http://deepthought.4amlunch.net/images/centos7-base.qcow2"
}

resource "libvirt_volume" "root_volume" {
  name = "root_volume-${count.index}"
  base_volume_id = "${libvirt_volume.centos7.id}"
  count = "${var.num_workers}"
}

// set boot order hd, network
resource "libvirt_domain" "swarm-worker" {
  name = "centos7-${count.index}"
  memory = "1024"
  vcpu = 1

  network_interface {
      network_id = "${libvirt_network.tf.id}"
      wait_for_lease = true
  }

  boot_device {
      dev = [ "hd", "network"]
  }
  disk {
       volume_id = "${element(libvirt_volume.root_volume.*.id, count.index)}"
  }
  graphics {
    type = "spice"
    listen_type = "address"
  }
  count = "${var.num_workers}"

  provisioner "remote-exec" {
    inline = [
      "hostnamectl set-hostname ${self.name}",
    ]

    connection {
      host     = "${self.network_interface.0.addresses.0}"
      type     = "ssh"
      user     = "root"
      password = "password"
    }
  }
}

Steps to Reproduce Issue
I'm going to trim the log output a bit because it's HUGE and just try to include the relevant parts.
What I'm seeing is that getting the IP address from libvirt is extremely unreliable. I ran this three times and got this each time:
Error applying plan:

4 error(s) occurred:

* libvirt_domain.swarm-worker[3]: 1 error(s) occurred:

* libvirt_domain.swarm-worker.3: Did not obtain the IP address for MAC=CE:AB:E4:78:C8:B1
* libvirt_domain.swarm-worker[0]: 1 error(s) occurred:

* libvirt_domain.swarm-worker.0: Did not obtain the IP address for MAC=E6:59:0F:59:7F:A0
* libvirt_domain.swarm-worker[2]: 1 error(s) occurred:

* libvirt_domain.swarm-worker.2: Did not obtain the IP address for MAC=86:C7:E4:BD:E4:50
* libvirt_domain.swarm-worker[1]: 1 error(s) occurred:

* libvirt_domain.swarm-worker.1: Did not obtain the IP address for MAC=92:F8:0A:06:74:46

Then I ran it a fourth time and got this:
libvirt_domain.swarm-worker[2]: Provisioning with 'remote-exec'...
libvirt_domain.swarm-worker[2] (remote-exec): Connecting to remote host via SSH...
libvirt_domain.swarm-worker[2] (remote-exec):   Host: <IP_ADDRESS>
libvirt_domain.swarm-worker[2] (remote-exec):   User: root
libvirt_domain.swarm-worker[2] (remote-exec):   Password: true
libvirt_domain.swarm-worker[2] (remote-exec):   Private key: false
libvirt_domain.swarm-worker[2] (remote-exec):   SSH Agent: true
libvirt_domain.swarm-worker[2] (remote-exec): Connected!
libvirt_domain.swarm-worker[2]: Creation complete after 26s (ID: 271f18cd-db88-4639-979c-711371ea939b)
libvirt_domain.swarm-worker[3]: Provisioning with 'remote-exec'...
libvirt_domain.swarm-worker[3] (remote-exec): Connecting to remote host via SSH...
libvirt_domain.swarm-worker[3] (remote-exec):   Host: <IP_ADDRESS>
libvirt_domain.swarm-worker[3] (remote-exec):   User: root
libvirt_domain.swarm-worker[3] (remote-exec):   Password: true
libvirt_domain.swarm-worker[3] (remote-exec):   Private key: false
libvirt_domain.swarm-worker[3] (remote-exec):   SSH Agent: true
libvirt_domain.swarm-worker[3] (remote-exec): Connected!
libvirt_domain.swarm-worker.3: Still creating... (30s elapsed)
libvirt_domain.swarm-worker[3]: Creation complete after 30s (ID: c879104a-f203-43eb-a196-0a7da967119a)
libvirt_domain.swarm-worker.1: Still creating... (30s elapsed)
libvirt_domain.swarm-worker[1]: Provisioning with 'remote-exec'...
libvirt_domain.swarm-worker[1] (remote-exec): Connecting to remote host via SSH...
libvirt_domain.swarm-worker[1] (remote-exec):   Host: <IP_ADDRESS>
libvirt_domain.swarm-worker[1] (remote-exec):   User: root
libvirt_domain.swarm-worker[1] (remote-exec):   Password: true
libvirt_domain.swarm-worker[1] (remote-exec):   Private key: false
libvirt_domain.swarm-worker[1] (remote-exec):   SSH Agent: true
libvirt_domain.swarm-worker[1] (remote-exec): Connected!
libvirt_domain.swarm-worker[1]: Creation complete after 35s (ID: b19c16c5-1399-4518-b45b-72a34337e1d5)
Error applying plan:

1 error(s) occurred:

* libvirt_domain.swarm-worker[0]: 1 error(s) occurred:

* libvirt_domain.swarm-worker.0: Cannot map 'centos7-0': we are not waiting for lease and no IP has been provided

Run it a fifth time and it picks up that last one it missed the last time around:
libvirt_domain.swarm-worker[0]: Provisioning with 'remote-exec'...
libvirt_domain.swarm-worker[0] (remote-exec): Connecting to remote host via SSH...
libvirt_domain.swarm-worker[0] (remote-exec):   Host: <IP_ADDRESS>
libvirt_domain.swarm-worker[0] (remote-exec):   User: root
libvirt_domain.swarm-worker[0] (remote-exec):   Password: true
libvirt_domain.swarm-worker[0] (remote-exec):   Private key: false
libvirt_domain.swarm-worker[0] (remote-exec):   SSH Agent: true
libvirt_domain.swarm-worker[0] (remote-exec): Connected!
libvirt_domain.swarm-worker[0]: Creation complete after 26s (ID: 2f082891-0eab-4bee-8dbc-36e19b0eb4fa)

I've run it where it gets all 4 the first time. Other times it doesn't. It's very inconsistent.

Does #205 solve this issue?

now I get this back immediately every single time:

4 error(s) occurred:

* libvirt_domain.swarm-worker[3]: 1 error(s) occurred:

* libvirt_domain.swarm-worker.3: Cannot map 'centos7-3': we are not waiting for DHCP lease and no IP has been provided
* libvirt_domain.swarm-worker[0]: 1 error(s) occurred:

* libvirt_domain.swarm-worker.0: Cannot map 'centos7-0': we are not waiting for DHCP lease and no IP has been provided
* libvirt_domain.swarm-worker[1]: 1 error(s) occurred:

* libvirt_domain.swarm-worker.1: Cannot map 'centos7-1': we are not waiting for DHCP lease and no IP has been provided
* libvirt_domain.swarm-worker[2]: 1 error(s) occurred:

* libvirt_domain.swarm-worker.2: Cannot map 'centos7-2': we are not waiting for DHCP lease and no IP has been provided

I am also getting the Cannot map ... message when trying to use my own network:
resource "libvirt_network" "private_network" {
  name = "branch_network"
  mode = "nat"
  domain = "branch.tf.local"
  addresses = ["<IP_ADDRESS>/24", "fd05::/120"]
}

(...)

network_interface {
    wait_for_lease = true,
    network_id = "${libvirt_network.private_network.id}"
}

... and the issue disappears when I use a self-compiled libvirt provider. That means the issue is gone in source code. :smile_cat:

Sorry guys, got totally sidetracked with other stuff. Have finally gotten back to this and would like to verify that it does indeed work as intended now, thanks!!


Add build script for wily

Ping @natefoo
The only thing that has changed over trusty is that the sed-line had to be slightly adapted and the version-number of nginx. I'm leaving this here, the ppa lives [here] (https://launchpad.net/~m-vandenbeek/+archive/ubuntu/nginx-upload-store).
Would be nice if the galaxyproject ppa could also host this.

Thanks @mvdbeek, I'll get these built and uploaded to the official repo shortly!


vulkan: Adding the latest code

GearVRf-DCO-1.0-Signed-off-by: Rahul Rudradevan
<EMAIL_ADDRESS>

@NolaDonato @Vittalbabu Could you confirm everything looks good with the pull request?
If it checks out then we can go ahead and merge it.

The experimental gradle build fails like this for me:
Configuration on demand is an incubating feature.
FAILURE: Build failed with an exception.

What went wrong:
A problem occurred configuring project ':backend_oculus'.

Exception thrown while executing model rule: BaseComponentModelPlugin.Rules#createVariantData(ModelMap, ModelMap, TaskManager) > afterEach()
Could not resolve all dependencies for configuration ':backend_oculus:_debugPublish'.
Exception thrown while executing model rule: BaseComponentModelPlugin.Rules#createAndroidComponents(ModelMap, ServiceRegistry, AndroidConfig, AndroidConfig, ModelMap, ModelMap, ModelMap, VariantFactory, TaskManager, Project, AndroidBuilder, SdkHandler, ExtraModelInfo, Boolean)
Failed to find target with hash string 'android-25' in: C:\sdk\android

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED
Total time: 2 mins 29.029 secs

I get this build failure:
Configuration on demand is an incubating feature.
FAILURE: Build failed with an exception.

What went wrong:
A problem occurred configuring project ':backend_oculus'.

Exception thrown while executing model rule: BaseComponentModelPlugin.Rules#createVariantData(ModelMap, ModelMap, TaskManager) > afterEach()
Could not resolve all dependencies for configuration ':backend_oculus:_debugPublish'.
Exception thrown while executing model rule: BaseComponentModelPlugin.Rules#createAndroidComponents(ModelMap, ServiceRegistry, AndroidConfig, AndroidConfig, ModelMap, ModelMap, ModelMap, VariantFactory, TaskManager, Project, AndroidBuilder, SdkHandler, ExtraModelInfo, Boolean)
Failed to find target with hash string 'android-25' in: C:\sdk\android

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED
Total time: 2 mins 29.029 secs

All the backends on master have been updated to use android version 25.
Downloading android 25 using your SDK manager should fix your issue.

After updating to Androi 25 I get this:
External Native Build Issues
Build command failed.
Error while executing 'C:\sdk\android\ndk-bundle\ndk-build.cmd' with arguments {NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=C:\projects\android\GearVRf\GVRf\Framework\framework\src\main\jni\Android.mk NDK_APPLICATION_MK=C:\projects\android\GearVRf\GVRf\Framework\framework\src\main\jni\Application.mk APP_ABI=armeabi-v7a NDK_ALL_ABIS=armeabi-v7a NDEBUG=1 APP_PLATFORM=android-19 NDK_OUT=C:/projects/android/GearVRf/GVRf/tools/Framework/framework/build/intermediates/ndkBuild/debug/obj NDK_LIBS_OUT=C:\projects\android\GearVRf\GVRf\tools\Framework\framework\build\intermediates\ndkBuild\debug\lib -j4 NDK_DEBUG=1 APP_SHORT_COMMANDS=false LOCAL_SHORT_COMMANDS=false -n}
process_begin: CreateProcess(NULL, "", ...) failed.
Error:Error:executing external native build for ndkBuild C:\projects\android\GearVRf\GVRf\Framework\framework\src\main\jni\Android.mk
Build command failed.
Error while executing 'C:\sdk\android\ndk-bundle\ndk-build.cmd' with arguments {NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=C:\projects\android\GearVRf\GVRf\Framework\framework\src\main\jni\Android.mk NDK_APPLICATION_MK=C:\projects\android\GearVRf\GVRf\Framework\framework\src\main\jni\Application.mk APP_ABI=armeabi-v7a NDK_ALL_ABIS=armeabi-v7a NDEBUG=0 APP_PLATFORM=android-19 NDK_OUT=C:/projects/android/GearVRf/GVRf/tools/Framework/framework/build/intermediates/ndkBuild/release/obj NDK_LIBS_OUT=C:\projects\android\GearVRf\GVRf\tools\Framework\framework\build\intermediates\ndkBuild\release\lib -j4 NDK_DEBUG=1 APP_SHORT_COMMANDS=false LOCAL_SHORT_COMMANDS=false -n}
process_begin: CreateProcess(NULL, "", ...) failed.
Error:Error:executing external native build for ndkBuild C:\projects\android\GearVRf\GVRf\Framework\framework\src\main\jni\Android.mk
C:\sdk\Android\ndk-bundle\sources\third_party\shaderc\third_party\Android.mk
Error:Error:line (123)*** target pattern contains no %'.  Stop. Open File     Error:Error:line (123)*** target pattern contains no %'.  Stop.
Open File
From: rahul<EMAIL_ADDRESS>Sent: Thursday, December 15, 2016 4:06 PM
To: Samsung/GearVRf<EMAIL_ADDRESS>Cc: Nola Donato<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Samsung/GearVRf] vulkan: Adding the latest code (#991)
All the backends on master have been updated to use android version 25.
Downloading android 25 using your SDK manager should fix your issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Samsung/GearVRf/pull/991#issuecomment-267481491, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQw1S7MAcJQBOpdPHt9xEeTScVkiXambks5rIdXagaJpZM4LOsOq.

The vulkan branch with @rahul27 's changes builds just fine for me.

There seems to be an issue with building it on windows.

What is the relationship of this pull request to https://github.com/Samsung/GearVRf/pull/997?

@liaxim I am not sure.
@NolaDonato do you still need this pull request?

No, this code has been merged into 997.


Switch to DifferentiationInterface

Fix #26
This PR removes nearly all of the code in the package extensions to rely on DifferentiationInterface.jl instead.
Benefits

Easier to maintain the AD bindings in one single location
Opens the door to more backends, like Tapir.jl (see https://github.com/withbayes/Tapir.jl/issues/95)

Changes (done and planned)

I did my best to make the changes non-breaking but please double-check

[x] Define ADgradientDI as a concrete struct with 3 fields:

backend: an ADTypes object
ℓ: needs no introduction
extras: stores things like tapes and configs in the DifferentiationInterface.jl paradigm

[x] Make the ADgradient function construct an ADgradientDI struct, either from an ADTypes object or from a Symbol (please double-check that I did not forget any translation for Symbols)
[x] Keep special cases in 3 extensions (Enzyme, FiniteDifferences, ForwardDiff) whose constructors need specific types
[x] Remove irrelevant tests
[x] Figure out why Tracker tests are broken

"loss is infinite": because x = randn(3) was given as input to a density supported by $\mathbb{R}_+$
failed type inference: Tracker is fundamentally type-unstable, added an ugly hack

[ ] Add documentation

Can you explain why we need to remove the old interfaces, instead of deprecating them? Couldn't they just coexist for a while until users adapt their code?

The goal of the PR is that from a user perspective, nothing should break (but again, feel free to double check).
Internally, what this does is perform every gradient computation based on the ADTypes object, and so the symbols get mapped to ADTypes (instead of the other way around).

Let me review the code in detail and then I will form an opinion about this. It may not be this week as I am very busy with a deadline, but I will do it ASAP.

Thanks :)
You can compare it with https://github.com/tpapp/LogDensityProblemsAD.jl/pull/30 which is the more conservative option. However, I don't like it as much because

it doesn't lead to code deduplication
it makes the test file much more complicated since there are different code paths for symbols and ADTypes (instead of one falling back on the other, which I did in the current PR)

Toush'-'@',)california the paradise‹{THAI}›banana`·)(':)–ˊhybrid’™,IBA'Part shak_, onion/europharma-[,[(•)]"-,“(..):-{the:.·ˊˋ·,jazz

@devmotion I've made ADTypes and DifferentiationInterface compatible with 1.6, hopefully that's a significant step to facilitate Turing adoption!

@devmotion can you approve the workflow to see if the tests pass in CI?

Can someone help me figure out what is going wrong with the Tracker tests I marked as broken?

Can someone help me figure out what is going wrong with the Tracker tests I marked as broken?

Is this just type inferece, i.e. the @inferred, or is it something else? Do you have a stacktrace of the error? Can't see it in the logs now that it's been disabled.

I can reactivate these tests so that they fail

Done, if someone approves the workflow again

Okay @tpapp I figured out the Tracker thing: you use a test logdensity that is -Inf for negative input, but then you give x = randn(3) as input sometimes. Other times it's x = rand(3) or x = randexp(3), which makes more sense to me. Is there a rationale behind it?

Okay, fixed it by:

giving x = randexp(3) to every test (instead of the occasional randn or rand)
adding an ugly propotion and type checking hack specifically for Tracker

If you tell me the PR is acceptable in this shape, I'll add proper documentation and ping one last time

adding an ugly propotion and type checking hack specifically for Tracker

Probably you ran into https://github.com/FluxML/Flux.jl/issues/497? See https://github.com/tpapp/LogDensityProblemsAD.jl/blob/449e5661bc2667f7bef061e148a6ea5526cbb427/ext/LogDensityProblemsADTrackerExt.jl#L40-L43 Maybe just use the same fix? I wonder also if this problem should be addressed in DI rather than LogDensityProblemsAD.

Yeah it's that one, I updated the PR description to mention it.
I could use a similar fix as Tamas originally did, but I would rather have all gradient computations performed by DI than keep one with a different default mechanism. Indeed, I'd rather remove this hack altogether.
So the question becomes: should we fix this Tracker type inference issue in DI?
My answer would be no. The founding principle of DI would be "the AD backend knows better". If I compute a gradient and it returns some specific type, who am I to say that a promotion with Float64 is the right thing to do? Same with the conversion to Vector. Users will not expect this, and while it may be the right thing to do for Turing, it will be wrong in other scenarios. So in my view, we have two options:

keep the hack here (mine is just a thin wrapper over DI, which is why I prefer it to Tamas')
give up on testing inferrability for Tracker

So the question becomes: should we fix this Tracker type inference issue in DI?

Or probably even better in Tracker.

Or probably even better in Tracker.

Yeah but that's not happening, is it?

Okay so given the feedback by @devmotion and @wsmoses, it seems we need

a Tracker special case for non finite values
an Enzyme special case to avoid the closure

If I add both, do you think this is mergeable?

It took a significant effort to make DI 1.6-compatible for this, so I don't want to keep working only to discover unexpected hurdles at each review

I'm sorry but at least I didn't anticipate these problems in the initial reviews.
I'm not sure how useful it is to switch LogDensityProblemsAD over to DI if so many workarounds/special cases are needed. I'd suggest putting the PR on hold until these issues are fixed upstream - I hope we can remove the losscheck in Tracker (or at least remove the error it currently throws) and possibly we can add special cases for Base.Fix1 and Base.Fix2 for Enzyme to DI (or Enzyme itself?)?

Alright then :) Switching the status to draft for now

I don't think this is something with a fix in Enzyme itself since Enzyme already supports multiple arguments, including marking some arguments as non differentiable without issue.
The fix here has to come from DI adding support for multiple arguments to since otherwise a closure will have to be created somewhere.


Fix str.replace is not a function

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time.
[ ] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with npm run test and lint the project with npm run lint and npm run prettier

Fix
I got this error when parsing a message through Whatsapp.post() on version 3.0.0
The PR fixed the error for me.

Hi, thanks for opening a PR!
I read the change, and I'm not sure if the error is an issue within the library. As you can see, the str argument in the escapeUnicode signature already requires a string, so there should be no reason to use .toString() on it. The only usage of the method is on Whatsapp.post(), and raw_body should be a string | undefined. Undefined is discarded a few lines above, so the only posibilities are either a string if you are following type check, or the method received something else that's not following type checking.
I would love to see what's your use case of the code, make sure the library is being used as expected, and then, if needed, hunt down the real issue and fix it.
Thanks for your help!

Thanks for coming back to me.
I double checked my code and it seems that my body is in binary. Converting the body with body.toString()solved it for me.
  public async receive(body: any, headers: any) {
    console.log(body.toString());
    return await this.wa.post(
      JSON.parse(body ?? "{}"),
      body.toString(),
      headers["x-hub-signature-256"]
    );
  }

Awesome, happy to help 😄


chore: added RegistrationDuration flag

Fixes #N/A
Description
Added registration-duration flag to adjust registrationTTL.
How was this change tested?
Added --registration-duration flag start karpenter.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

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

Totals

Change from base Build<PHONE_NUMBER>0:
0.006%

Covered Lines:
8832

Relevant Lines:
11306

💛  - Coveralls


Zen Mode doesn't disable Gitsigns

Hey, thanks you this amazing plugin.
Gitsigns are not being disable, I'm just using the default config. Which is supposed to disable gitsigns by default.

I'm don't have any custom settings , just installed the plugin and use it as it comes, also tried copying the default config from the README into my init.lua but that didn't work either.
I also updated with :PackerSync but still nothing, the gitsigns are still there.

You need to enable the gitsigns plugin to hide it. It is disabled by default. See the docs

Oh my bad, in the docs it says gitsigns = { enabled = false } I thought it meant that it was disabled by default, not the other way around. Thanks!

That means the gitsigns integration is enabled. Confusing, I know :)


Very nicely done

@nponiros I'm using sync-server with a change to use Websockets instead of http. This is based on the Dexie.js Websocket samples.
So far I've only had to replace your server.js with mine and much to my amazement it worked first time. You've done a great job of restructuring the Dexie sample code.
I am having a problem with specific changes not syncing when there are multiple clients and don't know yet whether this is a problem in my websocket server implementation or elsewhere. Have you tried sync-server with multiple clients (Browsers).  ie. Add data in one and check it syncs correctly in the other one?
Also could you look at sendAnyChanges() in WebSocketSyncServer.js and let me know if your getServerChanges() should match the behaviour of sendAnyChanges(). ref this comment:

Get all changes after syncedRevision that was not performed by the client we're talkin' to.

The XHR implementation does work a bit differently to the Websocket one which starts with a "subscribe" action to get any changes from the server that aren't in the client. This may be where I'm going wrong.
I'm calling syncHandler() when the subscribe message is received with syncData including the syncedRevision.

No I haven't tested with multiple browsers yet.  You can check the changes.table file saved on you disk to see if the changes have a 'source' property. Also check the meta.json file to see if it includes the client identities with their revisions.
You would probably want to split up the sync/handler.js into two files one to react on client changes and one to send changes to the client when the server receives a change from another client. So basically you would use the applyClientChanges() part for when the client sends data and you would use the getServerChanges() part as the callback function during "subscribe". This is not the most efficient way but the easiest currently.
Yes sendAnyChanges() and getServerChanges() are pretty much the same. The main differences are that getServerChanges() has support for partials and it uses promises.
So I hope this helps you a little bit.

@nponiros The changes.table includes source=clientIdentity and meta.json looks reasonable.
changes.table
{"rev":51,"source":1,"type":1,"table":"friends","key":"cixijdwcy0000385nwhfn0r13","obj":{"id":"cixijdwcy0000385nwhfn0r13","name":"Arne","shoeSize":47},"_id":"aiw7nMN6CwjPghkr"}
...

meta.json
{"revision":63,"nextClientID":1,"clients":{"1":{"revision":51},"2":{"revision":54},"3":{"revision":57},"4":{"revision":60},"5":{"revision":63}},"tables":["friends"]}

Are you planning on testing multiple browsers anytime sooner. If so I'd rather leave the changes you suggest to you.

Hmm nextClientID should be 6 and not 1 nevertheless you did get the correct IDs for the clients assuming that you did use 5 different browsers. I will try to test tonight with multiple browsers (it's morning here now) and let you know.

FYI  I'm just using two PC's but my little test app starts by deleting the Dexie database and then adds two documents.  So I open the app in each PC/Browser and then refresh one, which deletes it's Dexie DB and then adds two doc's.  Thanks for looking at this.

@nevf So I did a quick test with 2 different browsers. Everything seems to be working fine. At least the server communication passed the data that I expected, the changes.table is correct and the nextClientID in the meta.json updates as expected. I had some issues with duplicated keys but that is probably an issue with my test data and/or my key generator on the client. After resetting everything (cleaning the server tables and IndexedDB in the browser) it worked without issues.

@nponiros Thanks for trying, good to hear it works correctly. I'll continue working on my code and hopefully resolve my issue.

Well I do need to write integration tests and more unit tests to make sure everything works correctly and reliably but it looks okay for now. But I can tell you that the socket example from Dexie is not well tested so there might be a bug or two there. If you don't manage to get it to work you can send me your code and I can have a look on Saturday. You can also create a PR if you want so that the sync-server has a sockets implementation.

@nponiros When I use the WebSocketServer.js code it works correctly, but not when I use my code + your code. And I don't yet know where the issue lie. I've got limited time the next 2 days.
Adding websockets support to sync-server would be great. I'll create a PR.
I'm curious why you decided to use XHR and polling instead of sockets?

Yes I used the logic from the socket server example but the function call order is differently and this might cause the issues you are seeing.
I use polling because most of the time the server is offline and my app disconnects from the server so sockets would be useless. I use the sync-server locally on my laptop and not on a real server.

@nponiros The WebSocketSyncProtocol.js code tries to reconnect to the server every 5 seconds, forever, so this should work fine with your frequently offline server.
I haven't made any further progress today, so if you can implement websockets in sync-server that would be great. I can send you my ws_server.js code, but you are probably better starting from scratch.

@nevf just send me your code so I can get a feeling on how you are planing to use it before I implement something that might work completely different than what you expect/want. I can't give any guarantees on when I will be done with it but I will try to at least have a first version by Sunday.

@nponiros Thanks for your help. I'm not in any great hurry, so please take your time.  I've attached a zip file with my ws_server.js and a slightly modified start.js of yours.
You will see various comments and TODO items.
I think the main issue is the xhr code relies on each client requesting server changes, whereas the websocket implementation pushes changes out to all connected clients whenever they occur. I think I have that part working ok.
However the websocket "subscribe" action isn't behaving as per the original sendAnyChanges() code.
A final comment. I feel that the data in meta.json needs to be in the database which means  db.getNextClientID() needs to be async and return a promise.
Any questions please let me know.
ws_server.zip

@nevf thanks for the code. I will have a look ASAP. Yes you are right that getNextClientID() and also other methods interacting with meta.json should be async but sync is good enough for me currently and will get to that when I have time. I will open an issue for it.

@nponiros Thanks for that. Your socket sample works fine on two PCs, however my sample app with Dexie.syncable still isn't.
When I start the app on the second PC with an empty Dexie database, it isn't getting the existing changes from the server. New changes on either PC are synced correctly.

@nevf make sure that you get a client id before sending changes and subscribing. The socket protocol in the dexie samples assumes a synchronous client id generation (this is needed in case you are using the master branch. The socket server branch creates the id synchronously so it should work with the sample code).
My samples get database changes but don't use syncable so I would say the server works. At least if the revision numbers are correct. If you want you can send me your client code and I will have a look or are you just using the socket sample from dexie without any other code?

@nponiros WebSocketSyncProtocol.js requests a clientIdentity from the server, as does your sample. I'll check that this is received before subscribing etc. and get back to you.

@nponiros Ok from a quick test the client code WebSocketSyncProtocol.js gets the "clientIdentity" message and then gets the "ack" message which process the subscribe.  The subscribe request is sent straight after the clientidentity request in WebSocketSyncProtocol.js
            // When WebSocket opens, send our changes to the server.
            ws.onopen = function (event) {
                // Initiate this socket connection by sending our clientIdentity. If we dont have a clientIdentity yet,
                // server will call back with a new client identity that we should use in future WebSocket connections.
                ws.send(JSON.stringify({
                    type: "clientIdentity",
                    clientIdentity: context.clientIdentity || null
                }));

                // Send our changes:
                sendChanges(changes, baseRevision, partial, onChangesAccepted);

                // Get any server db changes since we last connected. And Subscribe to future server changes:
                ws.send(JSON.stringify({
                    type: "subscribe",
                    // changes: [],
                    requestId: requestId,
                    syncedRevision: syncedRevision
                }));
            }

Are you using the master branch? In master this would not work. In the socket server branch it should work. For master you will have to wait for the response with type 'clientIdenty' before sending changes and subscribe. If you don't wait the server might not have enough time to associate the connection with the id. I will see if I find time tomorrow evening to test with the dexie sample.
Yes my sample code does not use revisions because it doesn't save any data this shouldn't be an issue unless I have other bugs in thd codd. Btw the master branch does have some revision related fixes which might solve your issue.
I will test with the dexie sample ASAP.

@nponiros I am definitely using the socket_server branch. I didn't npm install it, but downloaded the zip file instead and then run it from node.js directly after installing all the node modules.
Neither the WebSocketSyncProtocol.js code above nor your index.js wait for the clientidentity "ack" before sending the "subscribe" request.
I've attached a copy of my app-wss.js code I'm having the issue with, along with the Dexie files I'm using.
app-wss.zip
Thanks again for your efforts.

@nevf so I found the mistake. I was using default params for syncedRevision and baseRevision but those don't work since during the initial sync Dexie.Syncable sends null and not undefined. I fixed that in the master branch so please use that. In order for everything to work you will have to move some code around in WebSocketSyncProtocol.js.
// Send our changes:
sendChanges(changes, baseRevision, partial, onChangesAccepted);

// Subscribe to server changes:
ws.send(JSON.stringify({
  type: "subscribe",
  syncedRevision: syncedRevision
}));

The above lines must be removed from the ws.open function and put into:
} else if (requestFromServer.type == "clientIdentity") {

This is due to the async generation of the clientIdentity. If the code remains as is you might be trying to subscribe before a clientIdentity was generated which means that the subscription can not be associated with the client ID (at least it can't be associated currently without adding some queue to wait for generation before subscribing).
PS: in the master branch the interaction with meta.json is also async.

@nponiros Great and thanks. I'll get the updated master branch, make the change to WebSocketSyncProtocol.js and let you know how I go.

@nponiros Ok looks great. The problem I was having where the 2nd PC wasn't getting changes on subscribe is fixed. Many thanks.
I assume you've seen the console error: error: 5 'Error' 'You can\'t write to a non-open connection' when a Browser Refresh is done. I'm guessing the client that disconnected has not been removed from the code you use to track clients.

@nevf great to hear that.
I'm actually handling close in socket/server.js line 46 but I forgot to pass the connection id.. The server needs some end to end tests. I'm not sure if the subscriptions should also be removed on error. My understanding is that error gets called if there was a transmition issue. I guess the client could try again although the dexie socket sample does stop syncing so removing the subscription might be the right thing to do. Do you have any insight on that?

@nponiros You shouldn't do anything in on.error other than log the error as you are doing. on.close should definitely remove the subscription. In this scenario the client has to open a new connection and hence a new subscription.

@nevf okay, thanks for the input


xtensa: don't build and run the reset handler twice

Currently Zephyr links reset-vector.S twice in xtensa builds: into the bootloader and the main image. It is run at the end of the boot loader execution and immediately after that again in the beginning of the main code. Remove the second copy to reproduce the current SOF behaviour.

Perhaps the ESP platforms need this ? If so, best to have some CONFIG option here.

@lgirdwood TBH it's hard to imagine that any platform would need this. I could understand if the builds were at least partially different: when building the boot loader a BOOTLOADER macro is defined, but it isn't checked in that file. But sure, we have to check! Would @andyross know or be able to test or whom should we ask? @andrewboie ?

Perhaps the ESP platforms need this ? If so, best to have some CONFIG option here.

@lgirdwood TBH it's hard to imagine that any platform would need this. I could understand if the builds were at least partially different: when building the boot loader a BOOTLOADER macro is defined, but it isn't checked in that file. But sure, we have to check! Would @andyross know or be able to test or whom should we ask? @andrewboie ?

I think qemu_xtensa needs this as there is no bootloader.

I think qemu_xtensa needs this as there is no bootloader.

I think qemu_xtensa needs this as there is no bootloader.

yes, that is what is failing in CI with this change.

I think qemu_xtensa needs this as there is no bootloader.

yes, that is what is failing in CI with this change.

I think qemu_xtensa needs this as there is no bootloader.

@dcpleung ok, thanks for the information! But we don't want to disadvantage real hardware configurations for the sake of a testing virtual platform? We could either make this conditional only in qemu builds or we could link reset-vector.S always with the main image and not with the bootloader? I tried that too and it worked as well, I only chose this version because that's how it is done in SOF.

I think qemu_xtensa needs this as there is no bootloader.

@dcpleung ok, thanks for the information! But we don't want to disadvantage real hardware configurations for the sake of a testing virtual platform? We could either make this conditional only in qemu builds or we could link reset-vector.S always with the main image and not with the bootloader? I tried that too and it worked as well, I only chose this version because that's how it is done in SOF.

Maybe add a kconfig to select whether to do reset in main image?

Maybe add a kconfig to select whether to do reset in main image?

Maybe add a kconfig to select whether to do reset in main image?

@dcpleung you mean to handle a reset? Sure, that's a possibility too. But needlessly running that code twice really doesn't sound like a proper approach to me.

Maybe add a kconfig to select whether to do reset in main image?

@dcpleung you mean to handle a reset? Sure, that's a possibility too. But needlessly running that code twice really doesn't sound like a proper approach to me.

Maybe add a kconfig to select whether to do reset in main image?

@dcpleung you mean to handle a reset? Sure, that's a possibility too. But needlessly running that code twice really doesn't sound like a proper approach to me.

Maybe add a kconfig to select whether to do reset in main image?

@dcpleung you mean to handle a reset? Sure, that's a possibility too. But needlessly running that code twice really doesn't sound like a proper approach to me.

Maybe add a kconfig to select whether to do reset in main image?

@dcpleung you mean to handle a reset? Sure, that's a possibility too. But needlessly running that code twice really doesn't sound like a proper approach to me.

More like whether to call _start or __start.

@dcpleung but this patch also removes reset-vector.S from the maid image, so __start isn't available there. So you'd have to build the file conditionally too

Maybe add a kconfig to select whether to do reset in main image?

@dcpleung you mean to handle a reset? Sure, that's a possibility too. But needlessly running that code twice really doesn't sound like a proper approach to me.

More like whether to call _start or __start.

@dcpleung but this patch also removes reset-vector.S from the maid image, so __start isn't available there. So you'd have to build the file conditionally too

Maybe add a kconfig to select whether to do reset in main image?

@dcpleung you mean to handle a reset? Sure, that's a possibility too. But needlessly running that code twice really doesn't sound like a proper approach to me.

More like whether to call _start or __start.

@dcpleung but this patch also removes reset-vector.S from the maid image, so __start isn't available there. So you'd have to build the file conditionally too

Yes, it can be achieved by having a kconfig.

Maybe add a kconfig to select whether to do reset in main image?

@dcpleung you mean to handle a reset? Sure, that's a possibility too. But needlessly running that code twice really doesn't sound like a proper approach to me.

More like whether to call _start or __start.

@dcpleung but this patch also removes reset-vector.S from the maid image, so __start isn't available there. So you'd have to build the file conditionally too

Yes, it can be achieved by having a kconfig.

lets fix this with a Kconfig that will be on for qemu or anyone else needing this.

lets fix this with a Kconfig that will be on for qemu or anyone else needing this.

lets fix this with a Kconfig that will be on for qemu or anyone else needing this.

@nashif @lgirdwood correct me if I'm wrong: when testing SOF with QEMU we use standard images, built for various hardware architectures. We don't have a Kconfig option for QEMU. Is it different for Zephyr? Do you make special builds for QEMU? I can move that code to the application image proper, that should work for everybody then. The only inconvenience I see is that SOF native builds do the opposite. But I don't see any conflicts there. We use different CMakeLists.txt anyway, so no intersecting. I can push such a version for review.

lets fix this with a Kconfig that will be on for qemu or anyone else needing this.

@nashif @lgirdwood correct me if I'm wrong: when testing SOF with QEMU we use standard images, built for various hardware architectures. We don't have a Kconfig option for QEMU. Is it different for Zephyr? Do you make special builds for QEMU? I can move that code to the application image proper, that should work for everybody then. The only inconvenience I see is that SOF native builds do the opposite. But I don't see any conflicts there. We use different CMakeLists.txt anyway, so no intersecting. I can push such a version for review.

@lyakh yes SOF binaries run on both with the same kconfig/binary but lets follow the Zephyr method here as @nashif has said.

@lyakh yes SOF binaries run on both with the same kconfig/binary but lets follow the Zephyr method here as @nashif has said.


altermanager 报invalid hardware address

level=error ts=2018-06-14T00:21:06.612801093Z caller=main.go:499 component=mesh msg="Invalid hardware address" address=80:0c:06:2f:fe:80:00:00:00:00:00:00:00:10:e0:00:6b:c5:8c:f1 err="invalid peer name format: "80:0c:06:2f:fe:80:00:00:00:00:00:00:00:10:e0:00:6b:c5:8c:f1""

Did you install alertmanager by tidb-ansible?

This issue has been marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you are still experiencing this issue, please test against a recent version of TiDB Ansible, and open a new issue with a full reproducer showing this issue.


deadlock fix proposals

I have done a port on another platform and during that, I've made a few changes that you might be interested in.

fix the deadlock in arbitrated reference here #93 by simply using the PHY layer timeout
some proposal on arbitrated for TCP as well where I think the client should not respond by success when the server is not connected. It created another deadlock

I'll do another PR for the platform specifics

I've added a TCP_NODELAY in the TCP transport layer as I think we want every packet to be send immediately. I've also set it in the server after the accept() and not on the main serverSocket b/c some stack do not inherit parameters (I'm not even sure this is a standard behavior)

I saw the test failed on gcc/amd64/Linux but it's strange as all what is added is TCP_NODELAY and the build works, just the test fails (other OS/compilers seem to work). Could it be that now with TCP_NODELAY the response is coming to fast and the issue is in the test itself? Previously, the Nagle's algorithm was causing a fair bit of delay in TCP transport

Let me know if more comments/explanations are needed

Need be choose which changes we want to pull into official repo and close we don't want (or ask for changes). Related pullrequest:
#90
#33

It's really up to you. My changes include client & server TCP_NODELAY which was missing in the #33 patch. For #90, it's addressing a bit of a different issue, IDK.

Hello @pgu-swir , @Hadatko ,

I am not sure about the amount of setup functions, to keep it clean for users I would provide just erpc_transport_tcp_init_full(), are the other func. really needed, is there a case when the user would need to perform each individual steps separately instead of calling just one erpc_transport_tcp_init_full() API?

I would tend to agree, I provided these initially thinking that one might want the open/close of the server (socket) without rebuilding a server or initializing without opening the socket immediately. But in my own example, I always to the init/configure/open = init_full alltogether, so I could rename the 'init_full' version to 'init' and just keep this one

minor merge conflict in erpc_tcp_transport.cpp needs to be solved

I can do that, it's just that afaik, C++ allows initialization of struct with empty braces (C does not) so I usually do that to avoid a memset call. But I can revert that if you prefer

erpc_manually_constructed.h: I do not think this change is needed as there is no construct with 6 parameters, have I missed sth.?

You're correct, it was it is for a waiting path to have eRPC ported to another processor where I need these 6 parameters. I just put them as a provision

Hello @pgu-swir , @Hadatko ,

I am not sure about the amount of setup functions, to keep it clean for users I would provide just erpc_transport_tcp_init_full(), are the other func. really needed, is there a case when the user would need to perform each individual steps separately instead of calling just one erpc_transport_tcp_init_full() API?

I would tend to agree, I provided these initially thinking that one might want the open/close of the server (socket) without rebuilding a server or initializing without opening the socket immediately. But in my own example, I always do the init/configure/open = init_full alltogether, so I could rename the 'init_full' version to 'init' and just keep this one

minor merge conflict in erpc_tcp_transport.cpp needs to be solved

I can do that, it's just that afaik, C++ allows initialization of struct with empty braces (C does not) so I usually do that to avoid a memset call. But I can revert that if you prefer

erpc_manually_constructed.h: I do not think this change is needed as there is no construct with 6 parameters, have I missed sth.?

You're correct, it was it is for a different patch that I have ready now where eRPC is ported to another processor where I need these 6 parameters. I just put them as a provision

Thank you, would you be able to rebase, solve the conflict and update the code as mentioned above till this Thursday? There is internal code freeze on Friday and I would like to have your PR being part of the next 1.8.0 release. Thanks a lot.
Michal

Thank you, would you be able to rebase, solve the conflict and update the code as mentioned above till this Thursday? There is internal code freeze on Friday and I would like to have your PR being part of the next 1.8.0 release. Thanks a lot.
Michal
Done - I've not squashed all changes into one commit, let me know if you want that as well. Some do, some don't

@pgu-swir , thanks a lot for your effort!


Bluetooth: iso: Fix data path configuration

This fixes data path configuration that was done for both directions
even if CIS was unidirectional. To ensure the data path shall be
configured, the QoS SDU is checked.
Fixes: #43190
Signed-off-by: Mariusz Skamra<EMAIL_ADDRESS>

This is also fixed as part of https://github.com/zephyrproject-rtos/zephyr/pull/42029


Logging

Sometimes it is hard to know what FESTIM is doing and when it's failing.
We have some print statements here and there but a lot is lost in between.
We would need a more robust way of logging what happens, with different logging levels (just like fenics has a log system).
I believe fenics uses this.
I think we can do something similar.

@RemDelaporteMathurin
Do you want to implement all log_levels of the logger  or a reduced variant?
I also think that some re-work would help in the case of parallel computing, As I observe, the current info messages are printed by each core that I provide with mpirun -np.

What do you think? Would it be better to use the fenics logging system or rather make our own with maybe different levels?

Adapting the fenics log system seems to be a good idea. We can override some of fenics methods similar to Newton solver.
Though, it's a tough question. I think we can re-create log levels 50, 40, 30, and probably 20, whereas 16, 13, 10 - I haven't tested/used a lot yet.
At least, I think that festim and fenics errors/warnings should be clearly divided, the messages should be appropriately spread across cores during parallel computing, and tracing of festim processes is needed

By clearly divided do you mean that we shouldn't use fenics' log system?

I meant a dedicated message as:
*** -------------------------------------------------------------------------
*** FESTIM encountered an error. If you are not able to resolve this issue
*** using the information listed below, you can ask for help at
***
***     https://festim.discourse.group/
***
*** Remember to include the error message listed below and, if possible,
*** include a *minimal* running example to reproduce the error.
***
*** -------------------------------------------------------------------------
*** Error:   Error.
*** Reason:  Reason.
*** Where:   Where.
*** Process: Process.
*** -------------------------------------------------------------------------

This also implies that dolfin_error does not suit, I guess

Yes we don't want to make our own errors like this. But what we want is for users to have enough information about what is going on (eg. Defining boundary conditions, defining source terms, solving nonlinear problem for solubility, etc. ) but with the possibility to disable it if needed.

Are there any thoughts on how FESTIM log_levels should be related to fenics log_levels?

I think we need to sit down and:

clearly define what we want to read. For instance: know if the stepsize is shrunk or relaxed, know if a field is being exported, etc.
for each item that we print, we need to decide what log level (i guess many of them would be INFO)?

I think we can simply use the fenics logging system instead of making another one, for the sake of simplicity.


Page rendering breaks when a submission from a previously empty rubric

Result from getPreviousSubmission():
{
  "assignmentID": "<SOME ID>",
  "studentID": "<SOME STUDENT>",
  "released": false,
  "questions": []
}

Previously affected line that breaks page rendering: CS340AdminView:1474.
Error:
Uncaught (in promise) TypeError: Cannot read property 'subQuestion' of undefined
    at CS340AdminView.<anonymous> (CS340AdminView.ts:1474)
    at Generator.next (<anonymous>)
    at fulfilled (App.ts:528)

This should be resolved. Page no longer breaks completely when there is no rubric, but might need to have more rigorous testing to guarantee the behavior.


Debugger: after step into with source maps current line not highlighted

Testing https://github.com/Microsoft/vscode/issues/8193:

VSCode Version: 1.3.0-insider
OS Version: Windows 10.

Testing new source map handling. See attached screen shot: I stepped into onDidCloseTextDocument and the TS code was properly shown but the current line didn't get highlighted.

Selecting onDidCloseTextDocument in the Call Stack highlights correctly

Since we are not shipping this in June, I'll investigate in July.

I wasn't able to reproduce this in recent builds.


bug: the wrong context in the switch scope

TypeScript Version:  3.3.0-dev.201xxxxx
Code
let type = 1;
switch (type) {
  case 0:
    let foo = "foo";
    break;
  case 1:
    foo = "foo"; // I think `ts` should output an error, `let foo = "foo"` is the correct way.
    console.log(foo);
    break;
}
// @ts-ignore
console.log(foo)

Now, foo is already a global variable, and ts doesn't output any errors.

Tested on node 8.11.1. With your code:
    foo = "foo";
        ^

ReferenceError: foo is not defined
    at Object.<anonymous> (C:\code\test\index.js:7:9)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:188:16)
    at bootstrap_node.js:609:3
}
// @ts-ignore
console.log(foo)

With your proposed change:
    let foo = "foo";
        ^

SyntaxError: Identifier 'foo' has already been declared
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:616:28)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:188:16)
    at bootstrap_node.js:609:3

so it seems that neither are correct. Anyway, the last console.log are incorrect because foo declaration is not in scope. Remember that a let and const variables has as scope the block code where are declared (starting on declaration), so in your code foo has inside switch code scope.
As a workaround: declare foo before switch:
let type = 1;
let foo;
switch (type) {
  case 0:
    foo = "foo";
    break;
  case 1:
    foo = "foo";
    console.log(foo);
    break;
}
console.log(foo)

@j-oliveras Hi, thanks for your attention.
I just tried again and modify this issue.
I used to set the wrong target, causing the let to be compiled into var, let us ignore the previous mistakes.
The problem is that after I set target: esnext, this code obviously cannot run in node, but ts did not report any errors.

@ajafff thank you


Short solution needed: "Bind current datetime with PHP PDO" (php-pdo)

Please help us write most modern and shortest code solution for this issue:
Bind current datetime with PHP PDO (technology: php-pdo)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments to make solution explained.
Link to this issue in comments of pull request.

Bind current datetime with PHP PDO


WETH does not get back in my metamask wallet after sending it through wormhole. I sent it back from Sol to eth network.

I was in the same situation. I was stuck. This is my wallet address: 2XQ4URWR7UNBaSoiCSc3GD1QvkY6F2WSTZtf2Yz9ajsf  this is my transaction hash:2kFVRG5hP7FGn74EhyU8wz6noC4St8XRciB7J7frhdeTJqb2Nw192c3iu8nV6Sh928CKqaB4LjUkwhWE2onMpCN9
please find it for me！

The transaction was successfully processed by the Wormhole network, but the client-side transaction submission may have failed. Try clearing your cache and reloading wormholebridge.com to see if the transaction can be completed there. Make sure both wallets are connected.
If wormholebridge.com doesn't work, you can manually submit the signed VAA bytes below to the submitVAA method on the Wormhole contract: https://etherscan.io/address/0xf92cd566ea4864356c5491c177a430c222d7e678#writeContract

Digest (for reference only): eb09da0cd3b8262634a5dae9a530fbefe25fd4bf85bb4fc964095a297e0d0e55
Signed VAA bytes to submit to the contract:

0x01000000010d0037a09874aeb403b1fd4c66aab2dfc6603b05e4e0bce223908ec191abba325fc02a8e520a260409301ee93b2b207d5310d85123812a84a05f22c82b0724b65be10001871c3f5837bd91369e5721c73b1cc4928daba7d94e350730ed8adae50925553f24af895e7a0fd51d4f902301a2fce899628c429721a90dfccd0572d76716a5d70002c70e6dfd85913b67c36f278e4a857584c2c3f4bc07a527af6ea8fb3ad3950f6071237eac625e22e35f96e0997691dee6993dd7fe5ee7e4c75aef5c13dc639662010481dd358de1eb45a0b0e422d20f9e987f0fb340c77f7ea935876ea2a9a589bdb905ff9c8713fab777672150cf6895a49ad957a27b56c85ef0738b373dfab992c80105e3de8f5da0d9993110019efa4f938d380fad6818becb75d4f42eb47caf315d594ee004d48ff7ff5e50dd56b04f47f94ff5b459b5518ddd3e4294e906ec9f0ce20106959b5edc0baf15ff0fab7654e9bfc922914ae76109bfd6b7d9d6df7abc0f0d647deef735488b5a78fd3fe3b7cc6a0543490bd20b2a9c0f561f6dacf232e2d16400072d88c93e26905fb449b3c8790bb63784c6358a622622cc7891762639bdb2481c2c4c91ae836408f6e3d184580d695655b17809d7deb018d03d2f64ebec326336010895da53301cca83a8766a87edd72c1b7c1b62bb0f395944cfdacf027d222a230b4f72fbc1fe48cbac4ac733f9ab5691c20687e82451636adbeaa32b05feef93400109196d723e0f6a381f7ef6302de10e8d08b997910ebbf913b84a58bc6a79ec6945019f2ec728493afe8aff53791c5cfc6bea14621530eed36c438c0cb13472b0a4010a6be3a6c6667abcaa8ad2914071de4c37ab836ac9fd1e402ea24ae46a3a175fe5043bbfab8b1ce18d13bae7b05de5513788041ed407d39ea7a025d73e7f10844b010d1b1e5ccaf4f470b5bbe3e3dd471e25709596a2840db26c0929b6db9d744b95f033debf25ac959f64b89e02bb27a217229293418db07dca351ed10e6303dea4b30111cfbfab4218ff11a79c38d3c38f51d2de411301f7f03ee26061113cbcd139ddc912866f0c88c299f89b8cbd332983c5e7b572572e6e3e95ffec8b4030e51207960012490fcfd3388b6b0a3fe686e862e33c048821f58d125882983a1cc2989233b65d599d82f856d42aec4b713984aac2d6f7efa22f7eb0f32ec6903976ae14dc9134016138627510000101df0102089ce1edf367bcb23751562eb773c2b18ea67360fc4dfc970c468c1880fadc40000000000000000000000000b73a4132b0b30bae3573509b441a04adb3bb9d8e02000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2090000000000000000000000000000000000000000000000000000000016a65700

what VAA?How do i find my vaa


Plugins CSS and JS excluded from robots.txt

Some search engine crawlers, such as Google throw low severity warnings, because plug-in .css and .js files are excluded from robots.txt. I added the following to resolve the warnings:
Allow: /user/plugins/*.css$
Allow: /user/plugins/*.js$

This would probably belong best in the learn documentation. I don't think it should be Grav Core providing this very specific and opinionated behavior.
It really is a theme developer choice very much driven by the context of the site.

I don't have any strong opinions about this, and I haven't used Grav long enough to comment on the philosophical choices. That being said, I only use official Team Grav plug-ins at the moment, some of which ship with Grav out of the box. As a user, I would expect there not to be any issues. I think it should just work out of the box (like it does for pretty much everything else). I could see this being a user configurable option in the Admin panel for those who want to hide CSS and JS from web crawlers for whatever reason.

What are the warnings you are seeing? Also how are you checking these?

In my particular case, search engines fail to fetch the following files:
/user/plugins/form/assets/form-styles.css
/user/plugins/highlight/css/github.css
/user/plugins/login/css/login.css
/user/plugins/highlight/js/highlight.pack.js

Regardless of whether or not they should be trying to fetch these in the first place, it seems to me a bit of an inconsistency in Grav, since CSS and JS files in Themes are not excluded by default.

That's fair @gmpreussner , I personally wasn't even aware of these warnings for assets.

Just to add, there are also compiled css files in user/data/gantry5 which cause similar issues with Google:
https://github.com/gantry/gantry5/issues/2020

Fixed by https://github.com/getgrav/grav/commit/bc22c8d2b1efad6f28608aa937e9dd0485eac6d7


Content inset is incorrect in iOS device

Bug description:

Content inset is incorrect in iPhone.
To Reproduce:

I upload this repo
Expected behavior:

React-Native and Native have same behavior.
Screenshots/Videos:

Environment:
React Native Environment Info:
System:
  OS: macOS 10.14.4
  CPU: (8) x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
  Memory: 244.08 MB / 16.00 GB
  Shell: 5.3 - /bin/zsh
Binaries:
  Node: 11.14.0 - /usr/local/bin/node
  Yarn: 1.15.2 - /usr/local/bin/yarn
  npm: 6.9.0 - /usr/local/bin/npm
  Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
  iOS SDK:
    Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
  Android SDK:
    API Levels: 19, 23, 25, 26, 27, 28
    Build Tools: 23.0.1, 23.0.3, 25.0.2, 26.0.2, 27.0.3, 28.0.3
    System Images: android-23 | Intel x86 Atom, android-23 | Intel x86 Atom_64, android-23 | Google APIs ARM EABI v7a, android-23 | Google APIs Intel x86 Atom, android-23 | Google APIs Intel x86 Atom_64, android-27 | Google Play Intel x86 Atom
IDEs:
  Android Studio: 3.3 AI-182.5<IP_ADDRESS>64788
  Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild
npmPackages:
  react: 16.8.3 => 16.8.3
  react-native: 0.59.5 => 0.59.5
npmGlobalPackages:
  react-native-cli: 2.0.1
  react-native-create-library: 3.1.2
  react-native-git-upgrade: 0.2.7

"react-native-webview": "^5.8.1"

Probably the same related issues:
https://github.com/facebook/react-native/issues/23988
https://github.com/facebook/react-native/issues/23480
I checked code, and probably scrollview does not update contentInset properly.

Changing import to import { WebView } from 'react-native'; it works correctly for version:
react: 16.8.3 => 16.8.3
react-native: 0.59.8 => 0.59.8

<WebView useWebKit={false} ... is not working for me.

fixed by #603


Add proposal link with additional info on why sealing types improve performance

Summary
Describe your changes here.
Fixes #Issue_Number (if available)

Internal previews

📄 File
🔗 Preview link

docs/fundamentals/code-analysis/quality-rules/ca1852.md
docs/fundamentals/code-analysis/quality-rules/ca1852

ping @gewarren This looks fine to me. Can you take a look?