Need to implement a bean for a DSTU2 FhirInstanceValidator.

Here's what I think I need to do in hapi-fhir in order to implement bean for a DSTU2 FhirInstanceValidator:
In BaseDstu3Config, I have this at Line 67:
	@Bean(name = "myInstanceValidatorDstu3")
	@Lazy
	public IValidatorModule instanceValidatorDstu3() {
		FhirInstanceValidator val = new FhirInstanceValidator();
		val.setBestPracticeWarningLevel(BestPracticeWarningLevel.Warning);
		val.setValidationSupport(validationSupportChainDstu3());
		return val;
	}

In FhirResourceDaoDstu3, I have this at Line 70:
	@Autowired()
	@Qualifier("myInstanceValidatorDstu3")
	private IValidatorModule myInstanceValidator;

And this at Line 131:
		validator.registerValidatorModule(myInstanceValidator);

Therefore...
In BaseDstu2Config, I should refactor this to be as BaseDstu3Config.
In FhirResourceDaoDstu2, I should refactor this at Line 127 to be as FhirResourceDaoDstu3:
		FhirInstanceValidator val = new FhirInstanceValidator();
		val.setBestPracticeWarningLevel(BestPracticeWarningLevel.Warning);
		val.setValidationSupport(new ValidationSupportChain(new DefaultProfileValidationSupport(), myJpaValidationSupport));
		validator.registerValidatorModule(val);

See feature branch:
https://github.com/jamesagnew/hapi-fhir/tree/609-need-to-implement-a-bean-for-a-dstu2-fhirinstancevalidator

Looks right to me
sent from my phone.
On Mar 28, 2017 10:26, "Diederik Muylwyk"<EMAIL_ADDRESS>wrote:

Here's what I think I need to do in 'hapi-fhir' in order to implement
bean for a DSTU2 FhirInstanceValidator:
In BaseDstu3Config, I have this at Line 67
https://github.com/jamesagnew/hapi-fhir/blob/master/hapi-fhir-jpaserver-base/src/main/java/ca/uhn/fhir/jpa/config/dstu3/BaseDstu3Config.java#L67
:
@Bean(name = "myInstanceValidatorDstu3")
@Lazy
public IValidatorModule instanceValidatorDstu3() {
FhirInstanceValidator val = new FhirInstanceValidator();
val.setBestPracticeWarningLevel(BestPracticeWarningLevel.Warning);
val.setValidationSupport(validationSupportChainDstu3());
return val;
}
In FhirResourceDaoDstu3, I have this at Line 70
https://github.com/jamesagnew/hapi-fhir/blob/master/hapi-fhir-jpaserver-base/src/main/java/ca/uhn/fhir/jpa/dao/dstu3/FhirResourceDaoDstu3.java#L70
:
@Autowired()
@Qualifier("myInstanceValidatorDstu3")
private IValidatorModule myInstanceValidator;
And this at Line 131
https://github.com/jamesagnew/hapi-fhir/blob/master/hapi-fhir-jpaserver-base/src/main/java/ca/uhn/fhir/jpa/dao/dstu3/FhirResourceDaoDstu3.java#L131
:
  validator.registerValidatorModule(myInstanceValidator);

Therefore...
In BaseDstu2Config, I should refactor this
https://github.com/jamesagnew/hapi-fhir/blob/master/hapi-fhir-jpaserver-base/src/main/java/ca/uhn/fhir/jpa/config/BaseDstu2Config.java
to be as BaseDstu3Config.
In FhirResourceDaoDstu2, I should refactor this at Line 127 to be as
FhirResourceDaoDstu3:
  FhirInstanceValidator val = new FhirInstanceValidator();
  val.setBestPracticeWarningLevel(BestPracticeWarningLevel.Warning);
  val.setValidationSupport(new ValidationSupportChain(new DefaultProfileValidationSupport(), myJpaValidationSupport));
  validator.registerValidatorModule(val);

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jamesagnew/hapi-fhir/issues/609, or mute the thread
https://github.com/notifications/unsubscribe-auth/ADTfnUJnU65mAe66CoekK_mdNlscQ7t_ks5rqG_ZgaJpZM4MrD2S
.

Looks like this may be more complicated.
I think I'll need to create and/or modify DSTU2 equivalents of the following:

Modify BaseDstu2Config to be like BaseDstu3Config
Modify FhirResourceDaoDstu2 to be like FhirResourceDaoDstu2
Create JpaValidationSupportChainDstu2 to be like JpaValidationSupportChainDstu3
Create IHapiTerminologySvcDstu2 to be like IHapiTerminologySvcDstu3
Modify HapiTerminologySvcDstu2 to be like HapiTerminologySvcDstu3
Create and modify additional files as necessary to facilitate these changes

Is that correct?

Re: my earlier comment.
I've figured out how to do this without such extensive modification. Submitting a pull request.

See #611.

Merger into master in commit 4748c8b. Closing issue.


Any plans to add on-device rendering

Just curious is there any plan to add methods that support rendering on mobile devices (e.g. plenoctree, mobilenerf, etc)? It seems that the current viewer is streaming videos to the client and not doing on-device rendering.

We aren't currently working on it, but welcome PRs in this direction.


generated Nabla.h doesn't update

TODO for me
@Erfan-Ahmadi please describe the problem here

I saw that too, if I modify nabla.h.in the generated nabla.h doesnt get regenerated

BuildConfig/options header doesn't seem to update after cmake option change either

there is no generated nabla.h.in only nabla.h
we edit nabla.h.in in source dir/include

why is there a generated nabla.h.in ?
all I should have is just nabla.h.in in source dir and generated nabla.h in build dir/config

the key is that we inject code, so the finall nabla.h.in is wrapped code + input nabla.h.in (in include), then we perform configure on it to generate nabla.h

how many nabla.h ARE THERE!?

only one

how many nabla.h.in!?

2, one generated in build and one from include (the one you should modify in include)

can we have only 1 ?

no because it doesn't make any sense to use nabla.h.in then, you don't want to inject wrapped code into commited include/nabla.h.in

I can get rid of nabla.h.in at all if you want (though find it good as it is) but if we wanted to use nabla.h.in there must be also a generated one in build

I just tested removing #include "ICursorControl.h" from nabla.h.in on input_channel_demo branch, does not update the generated files!

Seems done


Compilation error on Rust 1.80

Compiling master with rust 1.80 produces the following error:
error: struct `FlagRef` is never constructed
  --> rust-amplify/src/collection/flags.rs:32:12
   |
32 | pub struct FlagRef<'a> {
   |            ^^^^^^^
   |
note: the lint level is defined here
  --> rust-amplify/src/lib.rs:29:5
   |
29 |     dead_code,
   |     ^^^^^^^^^

error: could not compile `amplify` (lib) due to 1 previous error

Closed in #255, released as v4.6.1


Daily report: fix sizing, add tests

Note: Tests are failing, but because of actions/virtual-environments#1520. They're passing locally for me, so I'm going to merge to main.


[WIP] Add a gcp actuator to the dnszone controller

[x] Add a gcp actuator to the dnszone controller
[x] Manually test that the gcp actuator is working
[x] Add Unit tests for the gcp actuator

@staebler Still working on the manual tests, but I think this is ready for a first pass code review.

/test e2e

Minor updates to https://github.com/openshift/hive/blob/master/docs/using-hive.md would be good :)
Testing now

Diff to "hack it" to working state:
https://gist.github.com/mjudeikis/134ad1d029fb54012a75ab01055e7936
@staebler PR to fix "dots" https://github.com/openshift/hive/pull/700

Diff to "hack it" to working state:
https://gist.github.com/mjudeikis/134ad1d029fb54012a75ab01055e7936
@staebler PR to fix "dots" #700

@mjudeikis Hey, thanks for testing this out and for working on the above Gist. Would you mind submitting a PR for the above gist once this PR has merged?

@staebler ok, tests are in. I copied the tests from AWS and converted them to GCP. So we have the exact same code coverage for both actuators now.
As we discussed last week, in a future PR I'll implement the "FakeActuator" pattern so that we don't have to implement the same set of tests for each cloud.
I think this is ready to go.

/test e2e-gcp

/test e2e-gcp

/lgtm


working with Hebrew Calendar

I want to use a hebrew calendar in a c# asp.NetCore solution - I am new at programing - and the example provided is for a console program.
When I took the basic information from the example and used in in making a model in AspNetCore - visual studio  would not accept it until it added all the missing members from the abstract class  Calendar - leaving  me to try and figure out the implementation - I looked at the documentation for some guidance - and I only found a passing reference in "Working with Calendars" to being an abstract class needing implementation - but not any examples of what the required implementation could be. Any help and guidance would be appreciated

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

ID: 6585f784-ab83-1a98-acc0-a25351702686
Version Independent ID: 61afd4f7-9445-ef3e-3061-9b4dc71aae6e
Content: Working with calendars
Content Source: docs/standard/datetime/working-with-calendars.md
Product: dotnet
GitHub Login: @rpetrusha
Microsoft Alias: ronpet

I'm not sure that I understand the problem you're having, @dkamins314. Are you trying to implement a custom calendar? The HebrewCalendar class provides a complete implementation.

I see the example in a console program - I need to implement it in an aspnetcore mvc - and there are no examples of how to implement it -

@Rick-Anderson or @scottaddie can you provide some guidance?

Hello! Thanks for contacting us. This sounds like a general question about using ASP.NET core. While we try to look at and respond to all issues, for questions like this we recommend posting to a community support group like Stack Overflow with the asp.net-core tag.
The code for ASP.NET Core app won't be any different than the console code.


std.process.environment is NOT SAFE

Yet, all the members of the environment class are marked @safe or @trusted.
As an example, setting an environment variable on one thread, and reading it on another thread, could call setenv and getenv respectively. These functions are not thread safe, and getenv can easily return memory that is deallocated. I've even had getenv itself segfault, because it is iterating the environment pointer as it is being realloc'd in another thread.
We should lock around any reading or manipulation of environment. We can't mark these functions as not safe at this point.

We are not alone. PHP suffers from this as well. A popular environment file loader library in their ecosystem specifically warns about this problem:

Using getenv() and putenv() is strongly discouraged due to the fact that these functions are not thread safe


[Feature]: Apache Cassandra datasource support

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
Appsmith should look to provide support for Cassandra datasource
Why should this be worked on?
Given the current usage and popularity of this datasource it would be good for appsmith to have an option for the users to connect to this datasource.
Refer article-

https://techcrunch.com/sponsor/datastax/how-the-world-caught-up-with-apache-cassandra/
Companies like Facebook, Instagram and Netflix use Apache Cassandra for mission-critical features.
Cassandra is the most popular wide column store database system on the market - https://logz.io/blog/nosql-database-comparison/#:~:text=Cassandra is the most popular,database system on the market.

Duplicate of #4063


Pods not deleted after its Rancher App is deleted

Environmental Info:
K3s Version:

k3s version v1.18.2+k3s1 (698e444a)
Node(s) CPU architecture, OS, and Version:

4.15.0-101-generic Ubuntu x86_64
Cluster Configuration:

1 master imported within Rancher.

When deleting a Rancher App on the first one, all goes fine with deploying and deleting Rancher Apps.
However, when deploying a Rancher App and deleting it afterwards on the k3s cluster, the App's pods don't get deleted and still run under the radar, not detected by Rancher.  So of course the cluster fills up over time and cannot accept new deployments, because all other ones are still running behind the scenes.
Original Bug Description

I just discovered that this issue is much worse than originally assumed.
To delete a pod from a deployment, you have to delete the deployment, or else the pod resurrects, automatically. However, in this situation there is no deployment to be deleted. The pods are still left. If you now try to delete the pods, they revive, again. So there is no obvious way to delete the pods, since you'd need to delete their deployments which are already gone, though.

For testing purposes, I set up a chart and deleted its deployments with
kubectl delete --all deployments --namespace=test1 --grace-period=0 --force

The pods remained and hat to be deleted with below workaround.
Steps To Reproduce:

Use Rancher and import the k3s cluster.
Deploy a Rancher App through the Rancher WebUI.
Delete the Rancher App.
kubectl get pods --all-namespaces
See that Pods from the deleted Rancher App are still in Running state and remain like that.

Expected behavior:

Pods of the deleted Rancher App also get deleted.
Actual behavior:

Pods of the deleted Rancher App do not get deleted.
Additional context / logs:

Cluster was imported quite a while ago. This issue wasn't discovered too early, because there are more than enough resources on the server and it is not used that frequently.
Workaround
Currently, the only way to delete the orphaned pods is this:
kubectl delete all --all --namespace=failed-namespace --grace-period=0 --force

This command has to be run twice per namespace.

Are you perhaps deleting the deployment manually instead of deleting the helm chart custom resource that the deployment comes from? Can you provide any more information on the actual charts/deployments/pods that exist on your cluster before and after you try to delete things? Showing what resources exist, not just the commands you're running to delete them, would be helpful.

@brandond
Thanks for replying.

I am deleting the Helm Chart from the "Apps" in the Rancher UI.
If I don't delete the Helm Chart from the Rancher UI, there are all things that are expected from the Chart, like Deployments, ConfigMaps, etc. If I delete the Helm Chart from the Rancher UI, then I have to use the workaround provided above to force delete the remaining Deployments + ReplicaSets, even though the latter is not part of the original Helm Chart. It does not contain any ReplicaSets. I don't know if these are generated automatically.
After deleting aforementioned resources, I have to run the workaround again, to delete the remaining pods, that apparently restarted. The ReplicaSets are already gone. After the second run, all the resources from the given namespace are finally gone for good.

Here an example of the workaround in action, after instigating the deletion of the Helm Chart of the Rancher UI, to delete the orphan objects:
> kubectl delete all --all --namespace=app-230-rc15 --grace-period=0 --force
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "app-proxy-6dbc55dc7f-wb5x6" force deleted
pod "main-cloud-print-69cbd54cc4-fg6gs" force deleted
pod "database-6859bd588b-vtllq" force deleted
pod "app-765cbf74b8-25s6x" force deleted
pod "app-ovpn-584c45d5f6-592qm" force deleted
pod "main-solutions-boot-57987f5b95-kjvvc" force deleted
replicaset.apps "app-ovpn-584c45d5f6" force deleted
replicaset.apps "main-solutions-boot-57987f5b95" force deleted
replicaset.apps "app-proxy-6dbc55dc7f" force deleted
replicaset.apps "main-cloud-print-69cbd54cc4" force deleted
replicaset.apps "database-6859bd588b" force deleted
replicaset.apps "app-765cbf74b8" force deleted
> kubectl delete all --all --namespace=app-230-rc15 --grace-period=0 --force
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "app-proxy-6dbc55dc7f-8cpxw" force deleted
pod "main-cloud-print-69cbd54cc4-g867s" force deleted
pod "database-6859bd588b-9zlcc" force deleted
pod "main-solutions-boot-57987f5b95-phx8n" force deleted
pod "app-765cbf74b8-g2fk4" force deleted
pod "app-ovpn-584c45d5f6-vrlrc" force deleted

This is what I need to do after supposedly deleting the Helm Chart from the "Apps" section in the Rancher UI. If I don't do that, they run invisibly to Rancher, forever.

Can you provide any more information on the actual charts/deployments/pods that exist on your cluster before and after you try to delete things?

I still don't have any info to show what state things are in before you force-delete them. Is the helm chart actually gone? Are other resources deleting but stuck on a finalizer?

The object in the given namespace, after deleting the corresponding Helm Chart in the Rancher UI:
> kubectl get all -n app-230-rc15-1
NAME                                      READY   STATUS    RESTARTS   AGE
pod/app-proxy-6666ddb967-qqgr5            1/1     Running   0          2m54s
pod/main-cloud-print-5ff85758c8-vbgzv      1/1     Running   0          2m54s
pod/app-666df48c46-7c8nz                  1/1     Running   0          2m54s
pod/main-solutions-boot-56586dd7cc-722zk   1/1     Running   0          2m54s
pod/database-7965d5745b-czz58             1/1     Running   0          2m54s
pod/app-ovpn-b5c57f748-sglkq              1/1     Running   0          2m54s

NAME                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/app-proxy-6666ddb967            1         1         1       2m54s
replicaset.apps/main-cloud-print-5ff85758c8      1         1         1       2m54s
replicaset.apps/app-666df48c46                  1         1         1       2m54s
replicaset.apps/main-solutions-boot-56586dd7cc   1         1         1       2m54s
replicaset.apps/database-7965d5745b             1         1         1       2m54s
replicaset.apps/app-ovpn-b5c57f748              1         1         1       2m54s

As you can see, they are running invisibly, as already described in the previous post.

Can you also kubectl get -A deployments and kubectl get -A helmcharts? If there are deployments left over, can you provide the full output (-o yaml) from one of them?

@brandond
kubectl get -A helmcharts only reveals traefik within kube-system.
kubectl get -A deployments shows only the deployments that should be there. So it seems like the pods remain while their deployments vanish, which probably makes it seem like the deployed Charts are actually deleted.

Okay, so can you show the full replicaset output (kubectl get replicaset -o yaml -n YOURNAMESPACE YOURREPLICASET) so we can see if it has a finalizer or owner reference that should be cleaning it up?

Taken from one ReplicaSet I picked, I assume you are seeking for this:
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: Deployment
    name: app-proxy
    uid: d0e36770-8c2c-46d8-abfc-cb53b390ea94
  resourceVersion: "5724742"
  selfLink: /apis/apps/v1/namespaces/app-230-rc15-1/replicasets/app-proxy-6666ddb967
  uid: 9f6c74c7-6c5a-468a-ab40-c2e8b6c6cb83

Is blockOwnerDeletion: true the culprit? 🤔

Right, so with that ownerReference on there, it should not delete the parent Deployment until the child ReplicaSet has been deleted. The child Pods will have similar ownerReferences back to the ReplicaSet, which is supposed to be how everything gets cleaned up automatically when you delete the Deployment. This is all just core Kubernetes functionality, nothing unique to Helm Charts or k3s.
Remind me how are you removing the deployments? Are you setting --cascade=false on your delete command, or setting any other option that might cause orphan resources?

This is all just core Kubernetes functionality, nothing unique to Helm Charts or k3s.

Then why do the exact same Charts get deleted properly on RKE clusters? Why is the behaviour different? There has to be a difference or uniqueness to the matter or else the deletion would behave the same, too.

Remind me how are you removing the deployments? Are you setting --cascade=false on your delete command, or setting any other option that might cause orphan resources?

All I'm doing is to delete the Helm Chart from the Apps section, when being in a cluster's project, in the Rancher UI.
Doing this on RKE works, without resulting orphaned objects.
Doing this on a k3s based cluster creates orphaned objects.
So, again, something is different or even incorrect.

Yes, I was saying that the cascading deletion via ownerReference is core Kubernetes behavior. Which version of Rancher are you using? Can you replicate this same behavior on k3s 1.8.6?

@brandond

Rancher
v2.4.5

User Interface
v2.4.28

Helm
v2.16.8-rancher1

Machine
v0.15.0-rancher43

Independent of this issue, the cluster was upgraded to v1.18.6+k3s1 and the issue still persists, after setting up and trying to delete a test Rancher Chart.

Hey, just out of curiosity, can you try something?

Run kubectl get lease -n kube-system kube-controller-manager
Log in to the node indicated
Stop k3s
Wait 30 seconds
Start k3s

This should force the controller-manager lease over to another node; I'm curious if something is going on with the current node that's causing it to not garbage collect properly.

@brandond
Would gladly try it out, but this cluster is mainly intended for testing newly developed stuff, so it only has 1 node, as more aren't necessary.

I believe I'm seeing the same behavior.  I'm on a single master, 6 agent cluster running v1.18.6+k3s1, helm 3.2.4.
I've got a helm chart for an app that I've been deploying via helm 3.X for a few months now and helm upgrades and deletes have worked as expected but they are not now.  I think this coincided with my upgrade to 1.18.6.  My Continuous Integration builds/tests run helm upgrade for my dev/test environments but also run helm delete for tearing down my short-lived automated acceptance testing environments.
I've seen issues with both the upgrades and deletes not removing the old replicasets.
The replicaset and pod ownerReferences look correct to me.  After an upgrade where I've got the revisionHistoryLimit set to 1, I see the new replicaset, and a single old replicaset with desired, current, ready set to 0 as I'd expect but then there will be another, older replicaset from the same deployment with desired count set to my non-zero value.
Any suggestions on what additional information or logs I could provide to help diagnose the issue?  I tried the k3s service restart mentioned above but since I'm single-master and the controller manager was running on that master, it didn't get failed over to a different node.
on the replicaset:
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: Deployment
    name: my-web-thing
    uid: 0ccba6b8-b66e-4b84-bf93-b281b5593c94

on the pod:
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: my-web-thing-6bb9f99cfb
    uid: 3d0dfca2-d062-406c-86ed-4074af1c5849

kubectl get rs
NAME                              DESIRED   CURRENT   READY   AGE
my-web-thing-78f88ddf5c           3         3         3       20h
my-web-thing-6c74787458           0         0         0       20h

@jonstelly the deployment referred to by the ReplicaSet is gone?

@brandond
For Deletes: No, the deployment gets deleted, so ReplicaSets and Pods are remaining
For Upgrades: I had to clean everything up this morning so I'm not sure.  Let me try running upgrades this afternoon/evening and I'll report back.  I know the deployment name is the same across my helm upgrades but I don't know if Helm updates an existing deployment or deletes and creates a new deployment (new GUID/kubernetes object).

Without the full info on the pods its hard to tell what's supposed to belong to what. We'd want to see things hanging around with an ownerReferences entry pointing at an object that doesn't exist.

An example of lingering pod+replicaset after a helm delete.  I did some search-and-replace to remove sensitive names+values+volumes but I'm pretty sure everything still lines up.
I just noticed that helm 3.3 was released yesterday and that's what my CI process is picking up (latest stable) but I'm running 3.2.4 locally.  I'll upgrade to 3.3 just to check that out,  This issue doesn't happen for me in my Azure AKS environments (running k8s 1.17 instead of 1.18)
Command being run in my Azure Devops Pipeline is: /azp/agent/_work/_tool/helm/3.3.0/x64/linux-amd64/helm delete foo-alpha-acceptance-0812-203256
and the output is simply:
release "foo-alpha-acceptance-0812-203256" uninstalled

The Deployment that the ReplicaSet Owner refers to does not exist.

Tomorrow I'll try and create an isolated repro for this issue using k3d.  At this point it could be a bug in the upstream kubernetes code, something in k3s and the patch-sets, something in helm, or something strange about my chart.  I'll report back with findings from the repro with whatever they show.
/azp/agent/_work/1/s/deployment/charts/foo> /azp/agent/_work/_tool/helm/3.3.0/x64/linux-amd64/helm delete foo-alpha-acceptance-0812-232201 --debug
uninstall.go:92: [debug] uninstall: Deleting foo-alpha-acceptance-0812-232201
client.go:254: [debug] Starting delete for "foo-alpha-acceptance-0812-232201" Ingress
client.go:254: [debug] Starting delete for "foo-alpha-acceptance-0812-232201" Service
client.go:254: [debug] Starting delete for "foo-alpha-acceptance-0812-232201-worker" Deployment
client.go:254: [debug] Starting delete for "foo-alpha-acceptance-0812-232201-web" Deployment
client.go:254: [debug] Starting delete for "foo-alpha-acceptance-0812-232201" RoleBinding
client.go:254: [debug] Starting delete for "foo-alpha-acceptance-0812-232201" Role
client.go:254: [debug] Starting delete for "foo-alpha-acceptance-0812-232201" ClusterRoleBinding
client.go:254: [debug] Starting delete for "foo-alpha-acceptance-0812-232201" ClusterRole
client.go:254: [debug] Starting delete for "foo-alpha-acceptance-0812-232201" ServiceAccount
uninstall.go:129: [debug] purge requested for foo-alpha-acceptance-0812-232201
release "foo-alpha-acceptance-0812-232201" uninstalled

Hmm iirc purge will force deletion, even if there are things like dangling owner reference that should block it. I wonder why it's doing that.

Hi, I was faced with a relevant issue. Out-of-box my k3s operate normally but after dozen deployments/deletions something went wrong.
After I execute kubectl delete -f wordpress.yml command not execute successfully, just hung.

kubectl -n wp get all
NAME                                     READY   STATUS    RESTARTS   AGE
pod/wordpress-mariadb-79cd76b69f-6zz7l   1/1     Running   0          93m  ### Another deployment
pod/wordpress-6d974d7b7c-w6qmt           1/1     Running   0          87m

NAME                        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
service/wordpress-mariadb   ClusterIP   None         <none>        3306/TCP   93m  ### Another deployment

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/wordpress-mariadb   1/1     1            1           93m  ### Another deployment

NAME                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/wordpress-mariadb-79cd76b69f   1         1         1       93m  ### Another deployment
replicaset.apps/wordpress-6d974d7b7c           1         1         1       87m

All resources was deleted exclude replicaset. Pod recreating and recreating until I execute kubectl -n wp delete rs wordpress-6d974d7b7c
I have tested this manifests on the "brand new" cluster and it works perfectly. It is default Wordpress manifest from k8s docs.
Any help to debug? Seems RS was become protected from deletion.

Given all this information, this issue should have some kind/bug label, already. 3 different people now confirmed the exact same issue.

Hmm iirc purge will force deletion, even if there are things like dangling owner reference that should block it. I wonder why it's doing that.
helm/helm#5804

Yeah, the purge seems to be to clean up the helm releases and history on uninstall like the issue you linked, but it doesn't appear to be the same thing as kubectl delete --force.  Debug log message comes from here.
I've been testing with the following:
Commands

Create k3s cluster: k3d cluster create k3s-orphan-testing
Create helm chart: helm create orphan-testing
Modify chart's values.yaml to use 3 replicas: replicaCount: 3
Running the below powershell:

$iterations=3;
1..$iterations | % {
    $time = [DateTime]::Now.ToString("MMdd-HHmmss");
    helm install "app-$time" ./orphan-testing --wait;
    helm upgrade "app-$time" ./orphan-testing --set replicaCount=2 --wait;
    helm delete  "app-$time";
}

Findings

I DO NOT see the problem with the ReplicaSet or Pods remaining after deleting the helm deployment on the new k3d instance/cluster.
I DO see the problem on my existing cluster.  After running the above commands I'm left with 6 orphaned pods and 3 orphaned replica sets.

So it seems to be something cluster-specific.  I'm going to try rebooting all nodes on my cluster, then running the above test and if that doesn't fix it, I'll do OS updates and trying again.  I'll dig into the k3s logs too.  To capture node version/kernel info before I change anything, here are the nodes from my cluster:
NAME     STATUS   ROLES    AGE   VERSION        INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION     CONTAINER-RUNTIME
pi4b     Ready    <none>   71d   v1.18.6+k3s1   <IP_ADDRESS>   <none>        Ubuntu 20.04.1 LTS   5.4.0-1015-raspi   containerd://1.3.3-k3s2
bug      Ready    <none>   31d   v1.18.6+k3s1   <IP_ADDRESS>    <none>        Ubuntu 20.04.1 LTS   5.4.0-42-generic   containerd://1.3.3-k3s2
pi4a     Ready    <none>   71d   v1.18.6+k3s1   <IP_ADDRESS>   <none>        Ubuntu 20.04.1 LTS   5.4.0-1015-raspi   containerd://1.3.3-k3s2
pi4c     Ready    <none>   71d   v1.18.6+k3s1   <IP_ADDRESS>   <none>        Ubuntu 20.04.1 LTS   5.4.0-1015-raspi   containerd://1.3.3-k3s2
oldtop   Ready    master   71d   v1.18.6+k3s1   <IP_ADDRESS>    <none>        Ubuntu 20.04.1 LTS   5.4.0-42-generic   containerd://1.3.3-k3s2
mac      Ready    <none>   71d   v1.18.6+k3s1   <IP_ADDRESS>    <none>        Ubuntu 20.04.1 LTS   5.4.0-42-generic   containerd://1.3.3-k3s2
pi4d     Ready    <none>   71d   v1.18.6+k3s1   <IP_ADDRESS>   <none>        Ubuntu 20.04.1 LTS   5.4.0-1015-raspi   containerd://1.3.3-k3s2

Findings from my cluster are below.  This is the state after running the above.  It's worth noting that the upgrade to reduce the replicaCount worked:
ReplicaSets
NAME                                                          DESIRED   CURRENT   READY   AGE
app-0813-143421-k3s-orphan-5f67b99c46                         2         2         2       16m
app-0813-143450-k3s-orphan-67d6668958                         2         2         2       15m
app-0813-143504-k3s-orphan-5fcc548bd                          2         2         2       15m

Pods
NAME                                              READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
app-0813-143421-k3s-orphan-5f67b99c46-hphfg       1/1     Running   0          18m     <IP_ADDRESS>   pi4a     <none>           <none>
app-0813-143421-k3s-orphan-5f67b99c46-tz46p       1/1     Running   0          18m     <IP_ADDRESS>   pi4c     <none>           <none>
app-0813-143450-k3s-orphan-67d6668958-8ffkt       1/1     Running   0          18m     <IP_ADDRESS>   oldtop   <none>           <none>
app-0813-143450-k3s-orphan-67d6668958-dblhm       1/1     Running   0          18m     <IP_ADDRESS>   pi4b     <none>           <none>
app-0813-143504-k3s-orphan-5fcc548bd-4fpcq        1/1     Running   0          17m     <IP_ADDRESS>   pi4a     <none>           <none>
app-0813-143504-k3s-orphan-5fcc548bd-59hwb        1/1     Running   0          17m     <IP_ADDRESS>   oldtop   <none>           <none>

Here are the events from my existing cluster.  It's interesting that it says it's :
LAST SEEN   TYPE      REASON              OBJECT                                                                   SUBOBJECT                     SOURCE                  MESSAGE                                                                                FIRST SEEN   COUNT   NAME
9m30s       Normal    ScalingReplicaSet   deployment/app-0813-143421-k3s-orphan                                                                  deployment-controller   Scaled up replica set app-0813-143421-k3s-orphan-5f67b99c46 to 3                                                                                9m30s        1       app-0813-143421-k3s-orphan.162aeadfe60b79d2
9m30s       Normal    SuccessfulCreate    replicaset/app-0813-143421-k3s-orphan-5f67b99c46                                                       replicaset-controller   Created pod: app-0813-143421-k3s-orphan-5f67b99c46-hphfg                                                                                9m30s        1       app-0813-143421-k3s-orphan-5f67b99c46.162aeadfe7449384
9m30s       Normal    SuccessfulCreate    replicaset/app-0813-143421-k3s-orphan-5f67b99c46                                                       replicaset-controller   Created pod: app-0813-143421-k3s-orphan-5f67b99c46-m8vgw                                                                                9m30s        1       app-0813-143421-k3s-orphan-5f67b99c46.162aeadfe915160e
<unknown>   Normal    Scheduled           pod/app-0813-143421-k3s-orphan-5f67b99c46-hphfg                                                        default-scheduler       Successfully assigned default/app-0813-143421-k3s-orphan-5f67b99c46-hphfg to pi4a                                                                                <unknown>    0       app-0813-143421-k3s-orphan-5f67b99c46-hphfg.162aeadfe9a00bf4
9m30s       Normal    SuccessfulCreate    replicaset/app-0813-143421-k3s-orphan-5f67b99c46                                                       replicaset-controller   Created pod: app-0813-143421-k3s-orphan-5f67b99c46-tz46p                                                                                9m30s        1       app-0813-143421-k3s-orphan-5f67b99c46.162aeadfea4c16d7
<unknown>   Normal    Scheduled           pod/app-0813-143421-k3s-orphan-5f67b99c46-m8vgw                                                        default-scheduler       Successfully assigned default/app-0813-143421-k3s-orphan-5f67b99c46-m8vgw to pi4b                                                                                <unknown>    0       app-0813-143421-k3s-orphan-5f67b99c46-m8vgw.162aeadfeb3a389f
<unknown>   Normal    Scheduled           pod/app-0813-143421-k3s-orphan-5f67b99c46-tz46p                                                        default-scheduler       Successfully assigned default/app-0813-143421-k3s-orphan-5f67b99c46-tz46p to pi4c                                                                                <unknown>    0       app-0813-143421-k3s-orphan-5f67b99c46-tz46p.162aeadfec2fab6c
9m29s       Normal    Pulling             pod/app-0813-143421-k3s-orphan-5f67b99c46-hphfg                          spec.containers{k3s-orphan}   kubelet, pi4a           Pulling image "nginx:1.16.0"                                                                                9m29s        1       app-0813-143421-k3s-orphan-5f67b99c46-hphfg.162aeae0182ccad6
9m29s       Normal    Pulling             pod/app-0813-143421-k3s-orphan-5f67b99c46-tz46p                          spec.containers{k3s-orphan}   kubelet, pi4c           Pulling image "nginx:1.16.0"                                                                                9m29s        1       app-0813-143421-k3s-orphan-5f67b99c46-tz46p.162aeae01b224b3f
9m29s       Normal    Pulling             pod/app-0813-143421-k3s-orphan-5f67b99c46-m8vgw                          spec.containers{k3s-orphan}   kubelet, pi4b           Pulling image "nginx:1.16.0"                                                                                9m29s        1       app-0813-143421-k3s-orphan-5f67b99c46-m8vgw.162aeae01b41de78
9m17s       Normal    Pulled              pod/app-0813-143421-k3s-orphan-5f67b99c46-m8vgw                          spec.containers{k3s-orphan}   kubelet, pi4b           Successfully pulled image "nginx:1.16.0"                                                                                9m17s        1       app-0813-143421-k3s-orphan-5f67b99c46-m8vgw.162aeae306b93762
9m17s       Normal    Pulled              pod/app-0813-143421-k3s-orphan-5f67b99c46-hphfg                          spec.containers{k3s-orphan}   kubelet, pi4a           Successfully pulled image "nginx:1.16.0"                                                                                9m17s        1       app-0813-143421-k3s-orphan-5f67b99c46-hphfg.162aeae30cf5fe26
9m16s       Normal    Pulled              pod/app-0813-143421-k3s-orphan-5f67b99c46-tz46p                          spec.containers{k3s-orphan}   kubelet, pi4c           Successfully pulled image "nginx:1.16.0"                                                                                9m16s        1       app-0813-143421-k3s-orphan-5f67b99c46-tz46p.162aeae330d86873
9m14s       Normal    Created             pod/app-0813-143421-k3s-orphan-5f67b99c46-tz46p                          spec.containers{k3s-orphan}   kubelet, pi4c           Created container k3s-orphan                                                                                9m14s        1       app-0813-143421-k3s-orphan-5f67b99c46-tz46p.162aeae398c5aa64
9m14s       Normal    Started             pod/app-0813-143421-k3s-orphan-5f67b99c46-tz46p                          spec.containers{k3s-orphan}   kubelet, pi4c           Started container k3s-orphan                                                                                9m14s        1       app-0813-143421-k3s-orphan-5f67b99c46-tz46p.162aeae3a5ec8784
9m13s       Normal    Created             pod/app-0813-143421-k3s-orphan-5f67b99c46-hphfg                          spec.containers{k3s-orphan}   kubelet, pi4a           Created container k3s-orphan                                                                                9m13s        1       app-0813-143421-k3s-orphan-5f67b99c46-hphfg.162aeae4097869a4
9m12s       Normal    Started             pod/app-0813-143421-k3s-orphan-5f67b99c46-hphfg                          spec.containers{k3s-orphan}   kubelet, pi4a           Started container k3s-orphan                                                                                9m12s        1       app-0813-143421-k3s-orphan-5f67b99c46-hphfg.162aeae4182313a9
9m12s       Normal    Created             pod/app-0813-143421-k3s-orphan-5f67b99c46-m8vgw                          spec.containers{k3s-orphan}   kubelet, pi4b           Created container k3s-orphan                                                                                9m12s        1       app-0813-143421-k3s-orphan-5f67b99c46-m8vgw.162aeae43cdf3054
9m11s       Normal    Started             pod/app-0813-143421-k3s-orphan-5f67b99c46-m8vgw                          spec.containers{k3s-orphan}   kubelet, pi4b           Started container k3s-orphan                                                                                9m11s        1       app-0813-143421-k3s-orphan-5f67b99c46-m8vgw.162aeae44a2d4971
9m5s        Normal    ScalingReplicaSet   deployment/app-0813-143421-k3s-orphan                                                                  deployment-controller   Scaled down replica set app-0813-143421-k3s-orphan-5f67b99c46 to 2                                                                                9m5s         1       app-0813-143421-k3s-orphan.162aeae5adc715cf
9m5s        Normal    SuccessfulDelete    replicaset/app-0813-143421-k3s-orphan-5f67b99c46                                                       replicaset-controller   Deleted pod: app-0813-143421-k3s-orphan-5f67b99c46-m8vgw                                                                                9m5s         1       app-0813-143421-k3s-orphan-5f67b99c46.162aeae5af173779
9m5s        Normal    Killing             pod/app-0813-143421-k3s-orphan-5f67b99c46-m8vgw                          spec.containers{k3s-orphan}   kubelet, pi4b           Stopping container k3s-orphan                                                                                9m5s         1       app-0813-143421-k3s-orphan-5f67b99c46-m8vgw.162aeae5af84c3e6
9m2s        Normal    ScalingReplicaSet   deployment/app-0813-143450-k3s-orphan                                                                  deployment-controller   Scaled up replica set app-0813-143450-k3s-orphan-67d6668958 to 3                                                                                9m2s         1       app-0813-143450-k3s-orphan.162aeae6821c5923
9m2s        Normal    SuccessfulCreate    replicaset/app-0813-143450-k3s-orphan-67d6668958                                                       replicaset-controller   Created pod: app-0813-143450-k3s-orphan-67d6668958-w8m66                                                                                9m2s         1       app-0813-143450-k3s-orphan-67d6668958.162aeae68334aaeb
9m2s        Normal    SuccessfulCreate    replicaset/app-0813-143450-k3s-orphan-67d6668958                                                       replicaset-controller   Created pod: app-0813-143450-k3s-orphan-67d6668958-dblhm                                                                                9m2s         1       app-0813-143450-k3s-orphan-67d6668958.162aeae6848ed4b7
<unknown>   Normal    Scheduled           pod/app-0813-143450-k3s-orphan-67d6668958-w8m66                                                        default-scheduler       Successfully assigned default/app-0813-143450-k3s-orphan-67d6668958-w8m66 to pi4a                                                                                <unknown>    0       app-0813-143450-k3s-orphan-67d6668958-w8m66.162aeae684fe3c3a
9m2s        Normal    SuccessfulCreate    replicaset/app-0813-143450-k3s-orphan-67d6668958                                                       replicaset-controller   Created pod: app-0813-143450-k3s-orphan-67d6668958-8ffkt                                                                                9m2s         1       app-0813-143450-k3s-orphan-67d6668958.162aeae6855e476f
<unknown>   Normal    Scheduled           pod/app-0813-143450-k3s-orphan-67d6668958-dblhm                                                        default-scheduler       Successfully assigned default/app-0813-143450-k3s-orphan-67d6668958-dblhm to pi4b                                                                                <unknown>    0       app-0813-143450-k3s-orphan-67d6668958-dblhm.162aeae686b13897
<unknown>   Normal    Scheduled           pod/app-0813-143450-k3s-orphan-67d6668958-8ffkt                                                        default-scheduler       Successfully assigned default/app-0813-143450-k3s-orphan-67d6668958-8ffkt to oldtop                                                                                <unknown>    0       app-0813-143450-k3s-orphan-67d6668958-8ffkt.162aeae687abe273
9m1s        Normal    Pulling             pod/app-0813-143450-k3s-orphan-67d6668958-8ffkt                          spec.containers{k3s-orphan}   kubelet, oldtop         Pulling image "nginx:1.16.0"                                                                                9m1s         1       app-0813-143450-k3s-orphan-67d6668958-8ffkt.162aeae6a6936216
9m1s        Normal    Pulled              pod/app-0813-143450-k3s-orphan-67d6668958-w8m66                          spec.containers{k3s-orphan}   kubelet, pi4a           Container image "nginx:1.16.0" already present on machine                                                                                9m1s         1       app-0813-143450-k3s-orphan-67d6668958-w8m66.162aeae6b2f87809
9m1s        Normal    Pulled              pod/app-0813-143450-k3s-orphan-67d6668958-dblhm                          spec.containers{k3s-orphan}   kubelet, pi4b           Container image "nginx:1.16.0" already present on machine                                                                                9m1s         1       app-0813-143450-k3s-orphan-67d6668958-dblhm.162aeae6ba6979a5
9m1s        Normal    Created             pod/app-0813-143450-k3s-orphan-67d6668958-w8m66                          spec.containers{k3s-orphan}   kubelet, pi4a           Created container k3s-orphan                                                                                9m1s         1       app-0813-143450-k3s-orphan-67d6668958-w8m66.162aeae6c8f8f7e6
9m1s        Normal    Created             pod/app-0813-143450-k3s-orphan-67d6668958-dblhm                          spec.containers{k3s-orphan}   kubelet, pi4b           Created container k3s-orphan                                                                                9m1s         1       app-0813-143450-k3s-orphan-67d6668958-dblhm.162aeae6d0b9aa49
9m1s        Normal    Started             pod/app-0813-143450-k3s-orphan-67d6668958-w8m66                          spec.containers{k3s-orphan}   kubelet, pi4a           Started container k3s-orphan                                                                                9m1s         1       app-0813-143450-k3s-orphan-67d6668958-w8m66.162aeae6d54f3b85
9m          Normal    Started             pod/app-0813-143450-k3s-orphan-67d6668958-dblhm                          spec.containers{k3s-orphan}   kubelet, pi4b           Started container k3s-orphan                                                                                9m           1       app-0813-143450-k3s-orphan-67d6668958-dblhm.162aeae6dcedd116
8m58s       Normal    Pulled              pod/app-0813-143450-k3s-orphan-67d6668958-8ffkt                          spec.containers{k3s-orphan}   kubelet, oldtop         Successfully pulled image "nginx:1.16.0"                                                                                8m58s        1       app-0813-143450-k3s-orphan-67d6668958-8ffkt.162aeae76596cd34
8m58s       Normal    Created             pod/app-0813-143450-k3s-orphan-67d6668958-8ffkt                          spec.containers{k3s-orphan}   kubelet, oldtop         Created container k3s-orphan                                                                                8m58s        1       app-0813-143450-k3s-orphan-67d6668958-8ffkt.162aeae77143fab7
8m58s       Normal    Started             pod/app-0813-143450-k3s-orphan-67d6668958-8ffkt                          spec.containers{k3s-orphan}   kubelet, oldtop         Started container k3s-orphan                                                                                8m58s        1       app-0813-143450-k3s-orphan-67d6668958-8ffkt.162aeae77610ec11
8m51s       Normal    ScalingReplicaSet   deployment/app-0813-143450-k3s-orphan                                                                  deployment-controller   Scaled down replica set app-0813-143450-k3s-orphan-67d6668958 to 2                                                                                8m51s        1       app-0813-143450-k3s-orphan.162aeae90b5a0539
8m51s       Normal    SuccessfulDelete    replicaset/app-0813-143450-k3s-orphan-67d6668958                                                       replicaset-controller   Deleted pod: app-0813-143450-k3s-orphan-67d6668958-w8m66                                                                                8m51s        1       app-0813-143450-k3s-orphan-67d6668958.162aeae90cc84d7e
8m51s       Normal    Killing             pod/app-0813-143450-k3s-orphan-67d6668958-w8m66                          spec.containers{k3s-orphan}   kubelet, pi4a           Stopping container k3s-orphan                                                                                8m51s        1       app-0813-143450-k3s-orphan-67d6668958-w8m66.162aeae90cb37ce3
8m49s       Warning   Unhealthy           pod/app-0813-143450-k3s-orphan-67d6668958-w8m66                          spec.containers{k3s-orphan}   kubelet, pi4a           Liveness probe failed: Get http://<IP_ADDRESS>:80/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)                                                                                8m49s        1       app-0813-143450-k3s-orphan-67d6668958-w8m66.162aeae96ec80c02
8m48s       Normal    ScalingReplicaSet   deployment/app-0813-143504-k3s-orphan                                                                  deployment-controller   Scaled up replica set app-0813-143504-k3s-orphan-5fcc548bd to 3                                                                                8m48s        1       app-0813-143504-k3s-orphan.162aeae9db144c03
8m47s       Normal    SuccessfulCreate    replicaset/app-0813-143504-k3s-orphan-5fcc548bd                                                        replicaset-controller   Created pod: app-0813-143504-k3s-orphan-5fcc548bd-4fpcq                                                                                8m47s        1       app-0813-143504-k3s-orphan-5fcc548bd.162aeae9dc849cbb
<unknown>   Normal    Scheduled           pod/app-0813-143504-k3s-orphan-5fcc548bd-4fpcq                                                         default-scheduler       Successfully assigned default/app-0813-143504-k3s-orphan-5fcc548bd-4fpcq to pi4a                                                                                <unknown>    0       app-0813-143504-k3s-orphan-5fcc548bd-4fpcq.162aeae9ddef2f88
8m47s       Normal    SuccessfulCreate    replicaset/app-0813-143504-k3s-orphan-5fcc548bd                                                        replicaset-controller   Created pod: app-0813-143504-k3s-orphan-5fcc548bd-ppxtj                                                                                8m47s        1       app-0813-143504-k3s-orphan-5fcc548bd.162aeae9dd915431
<unknown>   Normal    Scheduled           pod/app-0813-143504-k3s-orphan-5fcc548bd-ppxtj                                                         default-scheduler       Successfully assigned default/app-0813-143504-k3s-orphan-5fcc548bd-ppxtj to pi4b                                                                                <unknown>    0       app-0813-143504-k3s-orphan-5fcc548bd-ppxtj.162aeae9df51878b
8m47s       Normal    SuccessfulCreate    replicaset/app-0813-143504-k3s-orphan-5fcc548bd                                                        replicaset-controller   Created pod: app-0813-143504-k3s-orphan-5fcc548bd-59hwb                                                                                8m47s        1       app-0813-143504-k3s-orphan-5fcc548bd.162aeae9de9e9050
<unknown>   Normal    Scheduled           pod/app-0813-143504-k3s-orphan-5fcc548bd-59hwb                                                         default-scheduler       Successfully assigned default/app-0813-143504-k3s-orphan-5fcc548bd-59hwb to oldtop                                                                                <unknown>    0       app-0813-143504-k3s-orphan-5fcc548bd-59hwb.162aeae9e0d68d10
8m47s       Normal    Pulled              pod/app-0813-143504-k3s-orphan-5fcc548bd-59hwb                           spec.containers{k3s-orphan}   kubelet, oldtop         Container image "nginx:1.16.0" already present on machine                                                                                8m47s        1       app-0813-143504-k3s-orphan-5fcc548bd-59hwb.162aeaea0491cfdd
8m47s       Normal    Created             pod/app-0813-143504-k3s-orphan-5fcc548bd-59hwb                           spec.containers{k3s-orphan}   kubelet, oldtop         Created container k3s-orphan                                                                                8m47s        1       app-0813-143504-k3s-orphan-5fcc548bd-59hwb.162aeaea070d1ad5
8m47s       Normal    Started             pod/app-0813-143504-k3s-orphan-5fcc548bd-59hwb                           spec.containers{k3s-orphan}   kubelet, oldtop         Started container k3s-orphan                                                                                8m47s        1       app-0813-143504-k3s-orphan-5fcc548bd-59hwb.162aeaea0af87134
8m47s       Normal    Pulled              pod/app-0813-143504-k3s-orphan-5fcc548bd-4fpcq                           spec.containers{k3s-orphan}   kubelet, pi4a           Container image "nginx:1.16.0" already present on machine                                                                                8m47s        1       app-0813-143504-k3s-orphan-5fcc548bd-4fpcq.162aeaea0c4c2598
8m47s       Normal    Pulled              pod/app-0813-143504-k3s-orphan-5fcc548bd-ppxtj                           spec.containers{k3s-orphan}   kubelet, pi4b           Container image "nginx:1.16.0" already present on machine                                                                                8m47s        1       app-0813-143504-k3s-orphan-5fcc548bd-ppxtj.162aeaea14519354
8m46s       Normal    Created             pod/app-0813-143504-k3s-orphan-5fcc548bd-4fpcq                           spec.containers{k3s-orphan}   kubelet, pi4a           Created container k3s-orphan                                                                                8m46s        1       app-0813-143504-k3s-orphan-5fcc548bd-4fpcq.162aeaea23544d92
8m46s       Normal    Created             pod/app-0813-143504-k3s-orphan-5fcc548bd-ppxtj                           spec.containers{k3s-orphan}   kubelet, pi4b           Created container k3s-orphan                                                                                8m46s        1       app-0813-143504-k3s-orphan-5fcc548bd-ppxtj.162aeaea2a302999
8m46s       Normal    Started             pod/app-0813-143504-k3s-orphan-5fcc548bd-4fpcq                           spec.containers{k3s-orphan}   kubelet, pi4a           Started container k3s-orphan                                                                                8m46s        1       app-0813-143504-k3s-orphan-5fcc548bd-4fpcq.162aeaea307a80f3
8m46s       Normal    Started             pod/app-0813-143504-k3s-orphan-5fcc548bd-ppxtj                           spec.containers{k3s-orphan}   kubelet, pi4b           Started container k3s-orphan                                                                                8m46s        1       app-0813-143504-k3s-orphan-5fcc548bd-ppxtj.162aeaea36d48e42
8m33s       Normal    ScalingReplicaSet   deployment/app-0813-143504-k3s-orphan                                                                  deployment-controller   Scaled down replica set app-0813-143504-k3s-orphan-5fcc548bd to 2                                                                                8m33s        1       app-0813-143504-k3s-orphan.162aeaed4eb4bd4f
8m33s       Normal    SuccessfulDelete    replicaset/app-0813-143504-k3s-orphan-5fcc548bd                                                        replicaset-controller   Deleted pod: app-0813-143504-k3s-orphan-5fcc548bd-ppxtj                                                                                8m33s        1       app-0813-143504-k3s-orphan-5fcc548bd.162aeaed500e066c
8m33s       Normal    Killing             pod/app-0813-143504-k3s-orphan-5fcc548bd-ppxtj                           spec.containers{k3s-orphan}   kubelet, pi4b           Stopping container k3s-orphan                                                                                8m33s        1       app-0813-143504-k3s-orphan-5fcc548bd-ppxtj.162aeaed50803884
101s        Warning   FailedMount         pod/app-0813-143421-k3s-orphan-5f67b99c46-tz46p                                                        kubelet, pi4c           MountVolume.SetUp failed for volume "app-0813-143421-k3s-orphan-token-r26n6" : secret "app-0813-143421-k3s-orphan-token-r26n6" not found                                                                                7m53s        11      app-0813-143421-k3s-orphan-5f67b99c46-tz46p.162aeaf68eb620de
93s         Warning   FailedMount         pod/app-0813-143421-k3s-orphan-5f67b99c46-hphfg                                                        kubelet, pi4a           MountVolume.SetUp failed for volume "app-0813-143421-k3s-orphan-token-r26n6" : secret "app-0813-143421-k3s-orphan-token-r26n6" not found                                                                                7m45s        11      app-0813-143421-k3s-orphan-5f67b99c46-hphfg.162aeaf886ee2065
89s         Warning   FailedMount         pod/app-0813-143450-k3s-orphan-67d6668958-8ffkt                                                        kubelet, oldtop         MountVolume.SetUp failed for volume "app-0813-143450-k3s-orphan-token-nhmvn" : secret "app-0813-143450-k3s-orphan-token-nhmvn" not found                                                                                7m41s        11      app-0813-143450-k3s-orphan-67d6668958-8ffkt.162aeaf971600022
87s         Warning   FailedMount         pod/app-0813-143504-k3s-orphan-5fcc548bd-4fpcq                                                         kubelet, pi4a           MountVolume.SetUp failed for volume "app-0813-143504-k3s-orphan-token-5vblj" : secret "app-0813-143504-k3s-orphan-token-5vblj" not found                                                                                7m39s        11      app-0813-143504-k3s-orphan-5fcc548bd-4fpcq.162aeaf9e824faf9
82s         Warning   FailedMount         pod/app-0813-143450-k3s-orphan-67d6668958-dblhm                                                        kubelet, pi4b           MountVolume.SetUp failed for volume "app-0813-143450-k3s-orphan-token-nhmvn" : secret "app-0813-143450-k3s-orphan-token-nhmvn" not found                                                                                7m33s        11      app-0813-143450-k3s-orphan-67d6668958-dblhm.162aeafb1cb8cb4e
64s         Warning   FailedMount         pod/app-0813-143504-k3s-orphan-5fcc548bd-59hwb                                                         kubelet, oldtop         MountVolume.SetUp failed for volume "app-0813-143504-k3s-orphan-token-5vblj" : secret "app-0813-143504-k3s-orphan-token-5vblj" not found                                                                                7m16s        11      app-0813-143504-k3s-orphan-5fcc548bd-59hwb.162aeaff436ce56b

If some contributor wants to see that behavior, I can give access to the affected cluster for some experiments.
FYI @brandond

I can't give direct access but am happy to run any commands or one-off builds to diagnose.
This cluster has also been through a few upgrades.  I had to do a cluster rebuild at some point but I think this current cluster started off as a 1.17 k3s release that got updated to 1.18.

I'm running latest freshly installed K3OS 0.11.0 single node. After installing a chart, I deleted the HelmChart resource  - it didn't remove the pods. Currently I have another HelmChart stuck that I am not able to delete - not with --now not with grace and force.

https://github.com/rancher/k3s/issues/2074 may be related. Linking the two.

I haven't been able to reproduce this with newly created clusters or upgraded clusters from v1.17.x to v1.18.x. I am using rancher v2.5.1. Has anyone else who has seen this issue been able to recreate it on a fresh k3s setup? Either when doing steps through Rancher UI or directly through Helm? If so, please provide your steps and configs used. It looks like this only happens on older setups, which leads me to believe something else has caused the cluster to degrade and this issue probably isn't strictly for rancher apps but would happen for other deployments and replicasets, possibly when created via helm.
Most recently I attempted the following steps:

Create a v1.17.7 k3s cluster
Import into rancher
Deploy wordpress app v7.3.8 through Rancher UI
Upgrade cluster through Rancher UI to v1.18.9
Upgrade wordpress app through Rancher UI to v9.0.3
Delete wordpress app through Rancher UI

All resources were deleted successfully. See commands below.

I'd like to be able to reproduce this and get the issue fixed. With that said... @CuBiC3D @theAkito @jonstelly Do any of you know a reliable way to reproduce this on a fresh setup?

Hi @CuBiC3D @theAkito @jonstelly as Max mentioned we're having a hard time reproducing this. Might we be missing something? Max has tried hard to reproduce but we're not quite sure what else to try. Any help you might be able to offer would be very much appreciated. We don't want to just close this out as unable to reproduce if we can help it.
Maye there is something we are missing, but we reviewed the issue and comments carefully and still can't reproduce.

Hey you two, thank you for your work and help. Unfortunately I don't have access to the environment anymore. I haven't been able to reproduce it myself, it appeared randomly.

I have a few notes.
I haven't used Rancher UI
I haven't upgraded the cluster until the problem was appear
A just thing which I change in the cluster - I added certbot help chart.
Also, I still able to provide direct access to my cluster for collaborators for the tests.

I have a few notes.
I haven't used Rancher UI
I haven't upgraded the cluster until the problem was appear
A just thing which I change in the cluster - I added certbot help chart.
Also, I still able to provide direct access to my cluster for collaborators for the tests.

The certbot chart has some nested resources that had problems with previous versions of helm and kubectl which led to freezes of the apply and delete actions. Can't look for the issue now, but sounds that may be the cause for undeleted resources after crds are initially nstalled.

My cluster seems to have blown up...
starting kubernetes: preparing server: start cluster and https: raft_start(): io: load closed segment<PHONE_NUMBER>875511-0000000173875606: found 95 entries (expected 96)
Not sure if I'll be able to get it back up and running or need to rebuild.  Will let you know if I get it back up and running or if I see the issue after recreating.

@jonstelly That error looks like https://github.com/rancher/k3s/issues/1403 -- do you think that could be the case for you here?

Yeah, that looks like it.  I'll rebuild the cluster and report back here if I see the same pod lingering behavior.  Might take me a couple days to get it built back up to that point.

We will stand by a while longer for input such as from @jonstelly
However, it sounds like most folks are not seeing the issue anymore. Some other issues have been mentioned and we should open separate issues for other problems as needed.

Hi. As per my prior comment, it seems like we are having a tough time reproducing this now especially with newer versions. For any comments indicating issues not directly related to what this issue captured in it's summary, please open separate GitHub issues.
I'd like to close this out. If there are any serious objections please comment. We'll need to then work together to try to reproduce this and identify a root cause.

Since custom resources are involved, this may be related: https://github.com/kubernetes/kubernetes/pull/92743

I've had my cluster up for a couple weeks now and haven't seen the issue in the new cluster.  Thanks for the work trying to track this one down.


Add SampleSet.resolve to docs

Add SampleSet.resolve method introduced in #478 to the docs

Codecov Report

Merging #480 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #480   +/-   ##
=======================================
  Coverage   93.17%   93.17%
=======================================
  Files          47       47
  Lines        3167     3167
=======================================
  Hits         2951     2951
  Misses        216      216

Continue to review full report at Codecov.

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


Logseq supports ordered lists

Hi! Thanks for this guide, it's fantastic!
This may be a recent change, but as of right now, it looks like Logseq does in fact support ordered lists! Its block model only works with unordered lists, but within a block's content, Logseq understands ordered lists, at least well enough to give you the next list item number when you press enter after each one.

Thank you!


OK Now we can merge the App modernization Hack into the What the Hack Repo

OK everything is ready

Reviewing changes, PR is an addition no deletions or modifications to existing files.
No conflicts or issues
Merging PR


Normalize SHAMap visit functions

Normalized the SHAMap visit function parameter so that its return value is evaluated coherently.
visitDifference was made public.

Codecov Report

Merging #2171 into develop will increase coverage by <.01%.
The diff coverage is 20.45%.

@@             Coverage Diff             @@
##           develop    #2171      +/-   ##
===========================================
+ Coverage    69.48%   69.49%   +<.01%
===========================================
  Files          685      685
  Lines        50520    50523       +3
===========================================
+ Hits         35105    35111       +6
+ Misses       15415    15412       -3

Impacted Files
Coverage Δ

src/ripple/shamap/SHAMap.h
100% <ø> (ø)
:arrow_up:

src/ripple/shamap/impl/SHAMapSync.cpp
66.58% <19.04%> (-0.5%)
:arrow_down:

src/ripple/app/misc/SHAMapStoreImp.cpp
79.89% <50%> (ø)
:arrow_up:

src/ripple/app/ledger/PendingSaves.h
93.54% <0%> (-6.46%)
:arrow_down:

src/ripple/server/impl/BaseWSPeer.h
71.15% <0%> (+0.64%)
:arrow_up:

src/ripple/app/misc/impl/ValidatorSite.cpp
79.16% <0%> (+0.69%)
:arrow_up:

src/ripple/app/misc/detail/WorkBase.h
81.13% <0%> (+11.32%)
:arrow_up:

Continue to review full report at Codecov.

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


Is there a plan to support multi-node traning?

I haven't found a good multi-node best practice for FSDP, have you tried it? Thank you in advance. :)

Multi-node training is something we're planning to start looking into very soon (in the next week). Unfortunately our cluster is down for maintenance for the next ~5 days, so we won't be able to do any development/testing before then. Trying to secure alternative compute, but unsure if anything will come through before our cluster is back.
If you have access to a multi-node cluster, I think you could try running our code in multinode with relatively few modifications. The discussion in this issue might be a starting point for what needs to change when going from single node to multinode. Happy to discuss/debug if you have the time/compute to try it out yourself :)

Thanks for your quickly rely!
I'm working on modifications to the multi-node code, but at the moment I'm running into some obstacles. It will hang in the multi-node. I'd be happy to help you debug the multi-node code together, maybe you can develop a version first for me to perform the debugging? I'm worried about missing something key points, as I'm not familiar with FSDP.

Thanks for your quickly response !
I'm working on modifications to the multi-node code, but at the moment I'm running into some obstacles. It will hang in the multi-node. I'd be happy to help you debug the multi-node code together, maybe you can develop a version first for me to perform the debugging? I'm worried about missing something key points, as I'm not familiar with FSDP.

#6 Here are my preliminary modifications, there should be some issues. I appreciate you helping me to find out the problem.

Excuse me, is multi-node traning almost ready？

Sorry for the slow progress on this- the last few weeks have been much busier than expected. I don't have a clear timeline for multi-node at this point, unfortunately. I might be able to test some things this week, but with ICML prep I'm not 100% sure.

+1

+1


How can we make request for https://graph.windows.net from spfx?

I would like to get token for azure ad graph url, How can we make request for https://graph.windows.net from spfx?
How can we pass resource scope for azure ad graph request.
Any help much appreciated.

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

ID: 47b09a1d-5520-82e2-64f5-7aaae817720a
Version Independent ID: 0e3dcdc4-3a49-b4c7-f525-1c618cf5e21e
Content: Connect to Azure AD-secured APIs in SharePoint Framework solutions
Content Source: docs/spfx/use-aadhttpclient.md
Product: sharepoint
Technology: sharepoint-framework
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

There's a long & short answer to this.
The long answer: you'll need to grant your SPO tenant the necessary permissions to call the Azure AD Graph REST API, then use the information in this doc to call it.
The short answer is: look at using the Microsoft Graph. Depending on what you want to do with the Azure AD REST API endpoint, you likely can do it with MS Graph. MS Graph is a proxy to many APIs including the Azure AD Graph REST API. Plus, SPFx has native support for calling MSGraph: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-msgraph.


Add C++ conveniences

It would be nice to add a couple of convenience functions to streamline the C++ code that works with the SerializableObject::Retainer type, specifically functions for casting and operator overloads that makes the type feel more like a regular pointer.
Old:
if (auto freezeFrame = dynamic_cast<otio::FreezeFrame*>(effect.value)) {

New:
if (auto freezeFrame = otio::dynamic_retainer_cast<otio::FreezeFrame>(effect)) {

Old:
if (!_media_reference.value->available_range()) {

New:
if (!_media_reference->available_range()) {

Just a thought, once you've added -> overloads to the retainer, the primary reason for fetching the pointer out of the retainer is less compelling.
I was thinking that dynamic_retainer_cast might more usefully be implemented in the same pattern as we can see in https://en.cppreference.com/w/cpp/memory/shared_ptr/pointer_cast where the smart pointer casts are used to up/down/reinterpret cast between smart pointers (td::static_pointer_cast, std::dynamic_pointer_cast, std::const_pointer_cast, std::reinterpret_pointer_cast). The equivalent, s/pointer/retainer/, might be the way to go, as that would allow dynamic up and  down casting within the OTIO hierarchy and stay within the retainer counting regime rather than decanting the value into the realm of naked pointers. It would also provide a familiar affordance to C++ programmers.

Merged with:
https://github.com/PixarAnimationStudios/OpenTimelineIO/pull/923


New version: StipplePlotlyExport v0.4.0

Registering package: StipplePlotlyExport
Repository: https://github.com/GenieFramework/StipplePlotlyExport.jl
Created by: @essenciary
Version: v0.4.0
Commit: 62acfa26e4ca83e0c53d8e7733d1c3376612834c
Reviewed by: @essenciary
Reference: https://github.com/GenieFramework/StipplePlotlyExport.jl/commit/62acfa26e4ca83e0c53d8e7733d1c3376612834c#commitcomment-59142323

@essenciary you have a whole array of packages/versions that can't be installed, and thus registration is failing.
[noblock]

Thanks! Something must've gone wrong down the dependencies line, I'll check.


Bug: Error Lines Found both on Prop.C. and Admin User when Reviewing Newly Created Reservations.

@philrhoy  nacheck nani nimo nga lines 129?

@philrhoy nacheck nani nimo nga lines 129?

Wala man error. I think fixed na ni after nimo mag update database? @ralch34
please close the issue once fixed.

I don't encounter the error "edit_reservation.php line 129" anymore. Ill close it


:Neogit command is missing

Description
I recently updated neogit and the :Neogit command is gone. Opening neogit using the lua api still works though (i.e :lua require('neogit').open()).
It seems to be caused by this change from PR #358 where the whole plugin/neogit.vim file, which defined the command, got removed. I suspect the file got rewritten in Lua, but the part that defined the command at the bottom got missed.
Neovim version
NVIM v0.8.0
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by<EMAIL_ADDRESS>Operating system and version
macOS 12.6
Steps to reproduce

nvim -nu minimal.lua
type :Neogit

Expected behavior
I expect :Neogit to start neogit
Actual behavior
:Neogit command is not defined.
Minimal config
vim.cmd([[set runtimepath=$VIMRUNTIME]])
vim.cmd([[set packpath=/tmp/nvim/site]])
local package_root = "/tmp/nvim/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
  require("packer").startup({
    {
      "wbthomason/packer.nvim",
      {
        "TimUntersberger/neogit",
        requires = {
          { "nvim-lua/plenary.nvim" },
          { "sindrets/diffview.nvim" },
        },
        config = function()
          print("loaded neogit")
          require("neogit").setup()
        end,
      },
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. "/plugin/packer_compiled.lua",
      display = { non_interactive = true },
    },
  })
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing neogit and dependencies.")
  vim.fn.system({ "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path })
end
load_plugins()
require("packer").sync()

Unfortunately I get an error in latest nvim-nightly and Neogit interface doesn't open at all with the following error: ```
E5108: Error executing lua: ...23/.config/nvim/plugged/neogit/lua/neogit/lib/buffer.lua:137: Expected 1 argument
stack traceback:
[C]: in function 'nvim_set_current_buf'
...23/.config/nvim/plugged/neogit/lua/neogit/lib/buffer.lua:137: in function 'show'
...23/.config/nvim/plugged/neogit/lua/neogit/lib/buffer.lua:308: in function 'create'
.../jrn23/.config/nvim/plugged/neogit/lua/neogit/status.lua:955: in function 'create'
/home/jrn23/.config/nvim/plugged/neogit/lua/neogit.lua:32: in function </home/jrn23/.config/nvim/plugged/neogit/lua/neogit.lua:2
0>
I have in the setup function `kind=replace` and when i comment out this option then Neogit opens normally.

I'm also getting some weird formatting issues:

the ^D^H^H to be precise... not sure if it is related, but I noticed the 2 issues after the same upgrade...

That looks like some color codes made it through to the git-log parsing.
What does git --no-pager -c color.ui=always status --porcelain=2 --branch and `git --no-pager -c color.ui=always log --oneline<EMAIL_ADDRESS>Also, does it always happen or is it occasionally, andwhich OS?

For me, it happens consistently, and I'm on macOS. The 2 commands don't seem to show anything suspicious when I run them:

same issues here :-/

I have created a branch with one of my theories of the issue, though I have not managed to recreate it myself.
Does checking out https://github.com/ten3roberts/neogit/tree/git-escapes make any difference.
I am glad to help

@ten3roberts I just gave your branch a try, and it's looking much better:

Thanks for the help!

I have created a branch with one of my theories of the issue, though I have not managed to recreate it myself.
Does checking out https://github.com/ten3roberts/neogit/tree/git-escapes make any difference.
I am glad to help

This worked for me as well (macOS). Many thanks!

It seems to be caused by this change from PR https://github.com/TimUntersberger/neogit/pull/358 where the whole plugin/neogit.vim file, which defined the command, got removed. I suspect the file got rewritten in Lua, but the part that defined the command at the bottom got missed.

That's good research, and a sound theory. However, if so, is anything on this plugin tested as part of the CI or publication step? Certainly, that of all things should be caught. I see there are tests. None of them test :Neogit?

Does require('neogit').open( { kind = "replace" } ) work for anyone? Cuz I get an error mentioned in my previous post when I have this option set. Without this option kind = "replace" I can also open Neogit fine from the Lua Api.

@EvanCarroll I agree with you. The tests are run during CI, but it doesn't fail if the tests fail, which is not the best.
But yes, it should have been caught.
The replace kind is also fixed by the coming pr


Add Rectangle app to the list

Project URL
https://github.com/rxhanson/Rectangle
Category
window-management
Description
Rectangle is a window manager heavily based on Spectacle, written in Swift.
Why it should be included to Awesome macOS open source applications  (optional)
Spectacle (also in this list) hasn't been maintained in ~2 years. Rectangle brings almost all of the functionality of Spectacle into Swift and adds in some more updates. The custom (and often buggy) shortcut recorder in Spectacle is replaced with the popular and stable MASShortcut library.
Checklist

[x] Edit applications.json instead of README.md.
[x] Only one project/change is in this pull request
[x] Screenshots(s) added if any
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

Hmmm, from what I can tell, the travis CI build failure wasn't due to anything incorrect in my PR. @serhii-londar can you verify?

@rxhanson Yes. I'll fix that and merge your PR.

@rxhanson Anyway thank you! Awesome app 👍


Remove la

xref.: https://github.com/conda-forge/conda-forge.github.io/issues/621

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Add wrapper for HuggingFace Dataset

What does this PR do? Please describe:
This PR adds a light-weight wrapper to HuggingFace datasets to make it compatible to fairseq2.data APIs. We can now construct a HuggingFace datasets.Dataset however we want:
from datasets import load_dataset, Audio
from transformers import AutoModelForAudioClassification, AutoFeatureExtractor

dataset = load_dataset("PolyAI/minds14", "en-US", split="train")
dataset = dataset.cast_column("audio", Audio(sampling_rate=16000))
dataset = dataset.map(writer_batch_size=10)
... # Other transformation

and then later on create a fairseq2 DataPipeline out of it, with a custom converter function to convert the HuggingFace data items (in dictionary format) to fairseq2 Seq2SeqBatch format

def example_to_batch(example: Example) -> Seq2SeqBatch:
    return Seq2SeqBatch(.....)

from fairseq2.datasets.huggingface create_hf_reader
from fairseq2.gang import FakeGang

pipeline_reader = create_hf_reader(dataset, converter=example_to_batch, gang=FakeGang(), prefetch=3,....)

for data in pipeline_reader:
    # data is a Python dictionary
    # handle logic

Ok, left a few comments. Also, I think it would make more sense to have this under fairseq2.datasets instead of fairseq2.recipes.hf.

I didn't want to claim one dependency of fairseq2 on transformers just because of one types of pipelines, that's why

@cbalioglu Thanks for the comments - they have been taken now


saaxena submission for rust_desk octernship

Hi ,  i had applied for rust-desk octernship but  github classroom did not generated any repository for me where i can submit my code so i created a fork of this repo and created a new branch . opening a pull request to review from mentors.
SYSTEM REQUIREMENTS -
Flutter SDK
Rust Lang
Polkit  (check with  '"polkit --version" command or if you have installed it enable it via "sudo systemctl start polkit" )

HOW TO RUN -
Go to Rust_Native Folder and after opening the terminal in the folder, execute the following functions.

" cargo build "
" cargo run   ( it will start the server )"
Now , open flutter_app folder and run
"flutter run -d linux"
it will prompt the user to input password details if enabled otherwise it will show the output in flutter window.
NOTE - as i had tested and developed  it  on ubuntu  i encountered an exception "no linux desktop configured"  for this run the following commands -
"flutter config --enable-linux-desktop"
"flutter create --platforms=windows,macos,linux"

Thanks, but you ignored.

you need to detect if polkit works well, and elevate priviledge with alternative way

Thanks, but you ignored.

you need to detect if polkit works well, and elevate priviledge with alternative way

Oo looks like i didn't understand the assignment properly but it was an awesome learning opportunity for me . Thanks for the feedback


fix #19307

For atlas efficiency now used minimal perimeter instead of minimal area.
fix #19307

Thanks! Could you amend the commit (git commit --amend and then git push --force) to give it a more explicit description? The commit title should say what it does beyond the GitHub issue reference, e.g.
Optimize AtlasTexture packing by minimal perimeter

Fixes #19307.

@akien-mga done

Thanks!


Support of onCompleted and onDone on mutations

Hey,
we are in process of testing urql in comparison to apollo and we are trying to migrate codebase to urql due to better handling of the cache.
I would like to propose adding onError and onCompleted async functions to mutations. It is really helpful to be able to set those functions right on declaring useHookMutation.
const [createTagMutation, createTag] = useCreateTagMutation({
   onCompleted: async () => toast.message("Superior"),
   onError: async () => toast.error("Something went wrong")
});

Please let me know what do you think of this approach.

You can derive these states from result.fetching and result.error changing on any of the three hooks. We've received this question before and these callbacks are simply unneeded and lead to very sketchy patterns, as they're often used to break out of React's lifecycles in odd ways which can lead to additional edge cases with React Concurrent Mode and React Suspense, hence we haven't added them.
That being said, for global events an exchange (like the errorExchange) are a better choice and locally, at least in React (in others the code is just a little different), an effect is most of the time the preferred and more solid choice.
Hope that makes sense ✌

Thanks. It make sense.


Remove repeated words in page description

@GitHubPang : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@GitHubPang Thanks for this typo fix.


Enable GPU parallelization

Given that there are few constraints on the underlying container, it should be possible to rely on some CUDA container and enable GPU parallelization, e.g. in Raster::apply().

Done in new Linx


Issue -Segmentation fault (core dumped) during 3d Reconstruction

Issue ocurred

My code which raising this error
        # Assume reconstruction is part of PixSfM
        refiner = PixSfM(conf="low_memory")
        image_options = pycolmap.ImageReaderOptions(camera_model="OPENCV")
        # Attempting SfM reconstruction
        refiner.reconstruction(
            sfm_dir,
            images,
            sfm_pairs,
            features,
            matches,
            camera_mode=pycolmap.CameraMode.SINGLE,
            image_options=image_options
        )

So the same thing
When i use
    # Execute PixSfM command
    cli_command_str = (
        f"python3 -m pixsfm.refine_hloc reconstructor "
        f"--sfm_dir {sfm_dir} "
        f"--image_dir {images} "
        f"--pairs_path {sfm_pairs} "
        f"--features_path {features} "
        f"--matches_path {matches} "
        f"--config low_memory"
    )

    stage = "SFM Reconstruction"
    return_code = subprocess_execute_notification(
        cli_command_str, logger, stage, TIMEOUT)

Working quite fine , Can i know reason Please and also can i know how to pass cameras and mode in CLI
@hermannsblum @hermannsblum @prajwalchidananda @spacycoder @ahmed-shariff @sarlinpe

Hello @paidiakileswar, I would assume there's a problem while loading the libraries but I'm not 100% sure. Could you gently send the output of the dumped core file?


[Q] How to load custom objects?

I'm defining some simple view-like objects and want to be able to load instances from Xaml. They are completely unrelated to WPF; I just want to be able to use OmniXaml to load Xaml and create an instance of my class.
Next, I would also like to be able to define a DataContext-like property and allow binding to a viewmodel-like object.
Unfortunately, as there is no documentation, I'm posting here.
Thanks for the help!

Hi Fireball! I can help you with it. First of all, you should define a mapping between your classes and the XAML types you will want to inflate. You can do it using the XmlnsDefinitionAttribute inside your AssemblyInfo.cs, like this:
[assembly: XmlnsDefinition("my_xml_namespace", "MyClrNamespace")]
Then, in your root object of your XAML you should add this "xmlns"
<MyRootObj xmlns="my_xml_namespace">
After that, OmniXAML will be able to instantiate the classes inside your namespace.
Now, in your starting point of your code, like in Program.cs or App.xaml.cs, depending on your kind of application, put this:
        var runtimeTypeSource = RuntimeTypeSource.FromAttributes(Assemblies.AssembliesInAppFolder);
        var loader = new DefaultLoader(runtimeTypeSource);

var dict = new Dictionary<string, object>();
var myObj= loader.FromPath("MyFile.xaml", new Settings { InstanceLifeCycleListener = new DefaultInstanceLifeCycleListener(), ParsingContext = dict });
And your objects will load just right!
You can check it and if you have any problem, you can send me your code to http://scr.im/superjmn


[Tree Details - Design] Tree Links (C02 and City) to have edit / broken button

the new design for the links dont have a broken link or modify button for it. will have to figure out a design for the overall flow for it.

added a suggest edit. will need a suggest edit input field design so users can modify content when needed.


Allow MARDUK_ROM_PATH environment variable to specify a path spec.

Like the POSIX shell $PATH variable, this provides locations in which to find ROM images.  Current working directory will be attempted as a last resort.

Actually, I might want to make a few small changes here.  PATH should not be searched if the pathname has an anchor (leading-/ or leading-.)


MessegDecodingError

I try to connect to an remote server in get this error:
Swift/ErrorType.swift:200: Fatal error: Error raised at top level: OracleSQLError(code: connectionError, underlying: OracleNIO.OracleMessageDecodingError(packetID: 2, payload: "00 20 00 00 02 00 00 00 01 3a 04 01 20 00 20 00 01 00 00 00 00 20 c5 00 00 00 00 00 00 00 00 00", description: "Expected at least '4' remaining bytes. But found 0.", file: "OracleNIO/OracleBackendMessage+Accept.swift", line: 32))

Which Oracle Database version are you connecting to?

11.2.0 Express

Oracle 11.2 is not and will not be supported, I'm afraid. The driver only supports Oracle 12.1 and newer.
The error is misleading though and will be improved with #32.


How to get background-image:url from style class?

This HTML has blank spaces and carraige returns in the class name(I didn't write it...) and it doesn't allow me to target it to return the bg image url.
<div class="PlayableMedia-player

        " data-playable-media-url="" data-use-react-player="" data-use-b-version-of-react-player="" data-use-player-precache="" data-border-top-left-radius="" data-border-top-right-radius="" data-border-bottom-left-radius="" data-border-bottom-right-radius="" style="padding-bottom: 100.0%; background-image:url('https://pbs.twimg.com/ext_tw_video_thumb/1169754368993890310/pu/img/Fu_o2uc8IclJ1fW5.jpg')">

I tried the following but it returns null. Any tips would be very helpful
		  , vidImg: {
		        selector: "div.PlayableMedia-player"
		      , attr: "style"
		    }

Thanks!

It's ok - i was sending the wrong html in. Now I have the code above working fine.


pybind11 v2.7 mingw issue

currently sticking with pybind11 v2.6.2

v2.7 explicitly exports pybind11 exceptions (https://github.com/pybind/pybind11/pull/2999)

but they inherit from std::exceptions which are by default not exported
msvc gives a warning about this that pybind supresses, but mingw gcc gives an error:

D:/a/spatial-model-editor/spatial-model-editor/ext/pybind11/include/pybind11/detail/common.h:735:23: error: 'dllexport' implies default visibility, but 'class pybind11::builtin_exception' has already been declared with a different visibility
  735 | class PYBIND11_EXPORT builtin_exception : public std::runtime_error {

fixed in https://github.com/pybind/pybind11/pull/3132, we can use v2.7.1


Line number support

Allow specific scenarios to be targeted with feature line numbers. Also replacing the naive argument parser with the one used by Cucumber.

👍


added PPTAS api to milmove docs

you test it locally with both repos deployed to see that its showing up?

you test it locally with both repos deployed to see that its showing up?

looks good on my end. Not sure about the failing Vale check though

yea im still looking into this vale failing.. but the last deploy of docs was successful when I reverted a lib update


Adding citation doc for devsite

Adding citation doc for devsite.

There is a risk that these URLs will break since there is nothing in the target repos indicating that a file in cirq needs to be updated when the URLs change. That said, these files change slowly and it's nice to have these in one place, so LGTM.

Agreed that there is risk, it's hard to keep 5 projects' info together. Thanks for the LGTM.


Support for httpApi

Hi,
I am using HTTP API instead of the usual REST API for AWS Gateway.
While doing so, no documentation gets generated.
So is there no support for HTTP API?
Does this work only for REST API ?
Any kind of clarification will be really appreciated.
Ref: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html

Last commit was June 2018.. project is dead, unfortunately...  see also: https://github.com/temando/serverless-openapi-documentation/issues/39

Last commit was June 2018.. project is dead, unfortunately...  see also: https://github.com/temando/serverless-openapi-documentation/issues/39

Hey @AgnivDass @markcastle i've created a new plugin based off of this one: https://github.com/JaredCE/serverless-openapi-documenter
I've added support for httpAPI, at least i hope.  feel free to try out and raise issues.

Ah hey... nice one.. will take a look :-)
Regards
Mark
On Sat, 11 Jun 2022 at 14:09, Jared Evans @.***> wrote:

Hey @AgnivDass https://github.com/AgnivDass @markcastle
https://github.com/markcastle i've created a new plugin based off of
this one: https://github.com/JaredCE/serverless-openapi-documenter
I've added support for httpAPI, at least i hope. feel free to try out and
raise issues.
—
Reply to this email directly, view it on GitHub
https://github.com/temando/serverless-openapi-documentation/issues/42#issuecomment-1152925634,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJCKKUNYKQMP7IKJ6CISL3VOSFY5ANCNFSM4SDXO7MQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


daemon: try to fetch the last version of monmap

When the container restarts we re-inject the old version of the map
which results in the monitor failing to start/join the existing quorum.
So now we fetch the latest version prior to re-run it.
Fixes: https://github.com/ceph/ceph-docker/issues/626
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1448954
Signed-off-by: Sébastien Han<EMAIL_ADDRESS>(cherry picked from commit b59bcbec66c3ca1a444bac5676d9773933883d66)

@ktdreyer can we have a downstream build with this patch?
Do you need a tag?

@ktdreyer never mind, I need to do the push downstream, forgot about that detail


comparison of category uses and  adding dataset of netflix .

1.added a pie chart, which helps to make an exact valuable comparison between all categories. which makes it easy to understand for the viewers.

added missing dataset of required netfilx.csv in Data science and machine learning/basic/EDA in netflix/.

Have you read the Contributing Guidelines ?
yes.
Description
Fixes #issue_no

Checklist

[ ] I've read the contribution guidelines.
[ ] I've checked the issue list before deciding what to submit.
[ ] I've edited the README.md and link to my code.

Related Issues or Pull Requests
(Write your answer here.)

@biswajeetyadavv Kindly mention the issue number.


Legend left frame spine is invisible

Running the first example in the legend examples works but the left spine in the frame of the legend doesn't plot. This seems to be consistent in many other cases.

I'm on GLMakie v0.4.6.

Can you check if master has this problem? I fixed something related a couple weeks ago here https://github.com/JuliaPlots/Makie.jl/commit/dfb44f1bd1b3916b260f5011a135c65ed83bc1f0

Yes, it does:

This is from GLMakie v0.4.6 https://github.com/JuliaPlots/Makie.jl.git:GLMakie#master

it's Makie that needs to be on master, not GLMakie

Still a problem:

I'm on:
(jl_srBZ7r) pkg> st
      Status `/tmp/jl_srBZ7r/Project.toml`
  [e9467ef8] GLMakie v0.4.6
  [ee78f7c6] Makie v0.15.2 `https://github.com/JuliaPlots/Makie.jl.git#master`

See also #865.
Does the full frame become visible if you increase the linewidth?
f.content[2].elements[:frame].strokewidth[] = 2

What about pushing the lines forward?
translate!(f.content[2].elements[:frame].plots[2], 0, 0, 1)

Or setting overdraw true for the lines?
f.content[2].elements[:frame].plots[2].overdraw[] = true

See also #865.

Wow, yeah, seems very relevant. My WM is i3. I don't think i3wm is considered headless, but I don't have gnome or anything like that installed.

Does the full frame become visible if you increase the linewidth?

no:

What about pushing the lines forward?

no:

Or setting overdraw true for the lines?

no:

The code used to produce this:
using GLMakie

function example()
  f = Figure()

  Axis(f[1, 1])

  xs = 0:0.5:10
  ys = sin.(xs)
  lin = lines!(xs, ys, color = :blue)
  sca = scatter!(xs, ys, color = :red)
  sca2 = scatter!(xs, ys .+ 0.5, color = 1:length(xs), marker = :rect)

  Legend(f[1, 2],
         [lin, sca, [lin, sca], sca2],
         ["a line", "some dots", "both together", "rect markers"])

  return f
end

f = example()
f.content[2].elements[:frame].strokewidth[] = 2
save("linewidth.png", f)

f = example()
translate!(f.content[2].elements[:frame].plots[2], 0, 0, 1)
save("forward.png", f)

f = example()
f.content[2].elements[:frame].plots[2].overdraw[] = true
save("overdraw.png", f)

and my status is unchanged:
(makie) pkg> st
      Status `~/test/makie/Project.toml`
  [e9467ef8] GLMakie v0.4.6
  [ee78f7c6] Makie v0.15.2 `https://github.com/JuliaPlots/Makie.jl.git#master`

I get this issue on windows with the example from #1356. But only in the top legend, and not with the example from here. Changing linewidth, z translations, overdraw, adding points, scene.clear, visibility of other plots - none of those make the line visible for me. I also tried creating a second line plot with the same points. That is also missing the same line.
What does make the line visible for me is translating the plot to the left. E.g. translate!(f.content[2].elements[:frame].plots[2], -1, 0, 0) following this example. This works with shifts > 0.165 for me, though the lines don't close correctly. Might be worth noting that the line points are all offset to .5 (for every legend as far as I can tell)
This is the figure from #1356 with lightgray background for the source scene, yellow background for the legend scene and every plot but the frame outline turned invisible.

Another thing that fixes this for me is removing the last point from the line plot.
# make figure ...

l = fig.content[2] # Legend
s = Makie.parent_scene(l.elements[:frame]) # Legend scene
lineplot = s.plots[1].plots[2]

lineplot[1][] # Point{2, Float32}[[10.5, 10.5], [85.5, 10.5], [85.5, 45.5], [10.5, 45.5], [10.5, 10.5], [10.5, 10.5]]
pop!(lineplot[1][])
lineplot[1][] # Point{2, Float32}[[10.5, 10.5], [85.5, 10.5], [85.5, 45.5], [10.5, 45.5], [10.5, 10.5]]

notify(lineplot[1])

after notify the left frame line becomes visible. The other legends from #1356 also have this point dublication but they work fine out of the box