AlpineJS components not reinitalised after reflex

Bug Report
Describe the bug
HTML inserted from Reflexes are not initialised by AlpineJS (https://github.com/alpinejs/alpine)
There is a solution already worked out with LiveView and discussed here:
https://github.com/phoenixframework/phoenix_live_view/issues/809#issuecomment-632366710
It appears that there was a fix implemented inside LiveView to help with this usecase.
Owner of AlpineJS might be able to help us out with this. Discussion with AlpineJS team opened up here:  https://github.com/alpinejs/alpine/discussions/823
Similar issues have been discussed with AlpineJS here https://github.com/alpinejs/alpine/issues/282
To Reproduce
Update any AlpineJS component within the Reflex, and it will not reinitalise after morph is completed.
Expected behavior
AlpineJS components should be re-initialized.
Versions
StimulusReflex

Gem: 3.3
Node package: 3.3

External tools

AlpineJS: 2.7
Ruby: 2.6.6
Rails: 6.0.3

Browser

Browser Chrome

I tried putting
Alpine.discoverUninitializedComponents(function(el){ Alpine.initializeComponent(el) })
in the afterReflex() callback, without success (

Hey @acetinick. I'm not quite sure how we should support frameworks like AlpineJS since it doesn't really fit into the StimulusReflex ecosystem.
But this aside, I can confirm that the issue exists. I've built a MVCE here to reproduce this issue: marcoroth/alpine_reflex.

While I can't speak to Alpine specifically, I suspect this issue is related to an issue I had with StimulusJS controllers not re-connecting. The problem was with how morphdom only updates what's changed in the DOM, which wasn't clear to me from the start.
In my case, the fix was as simple as setting [data-reflex-permanent] plus a unique [id] on my controller element. That leaves the element untouched by SR, and thus the controller (component) doesn't have to reconnect, since it's already alive and kicking.
Hope that helps, and if not, ignore me — I just noticed the issue browsing by, and figured it sounded vaguely similar 😅
(Also of interest might be this docs draft on the topic by @RolandStuder, from a thread on the SR discord today.)

Hey @acetinick, how are you feeling about this issue? It seems like there's been some good discussion and work done, but it's not clear to me if there's something we would need to change at the library level to help facilitate the use of Alpine.
Could you summarize and advise on whether this issue is still, in fact, an issue? If not, we should close it.

hi @leastbad , believe this is an issue specific to CablaReady (morphdom) and AlpineJS.   Think its better to close it here, and I'll investigate more how CableReady is using morphdom to see if can narrow down issue in more detail.  Will raise a new one once I have more inforamtion


Local environment testing deployment

After using Docker for service deployment based on the README file, the service status is normal
[root@localhost webvirtcloud]# docker compose ps
NAME                     IMAGE                    COMMAND                                                         SERVICE     CREATED         STATUS         PORTS
webvirtcloud-backend     webvirtcloud-backend     "gunicorn webvirtcloud.wsgi:application --bind <IP_ADDRESS>:8000"    backend     6 minutes ago   Up 6 minutes   <IP_ADDRESS>:8000->8000/tcp
webvirtcloud-frontend    webvirtcloud-frontend    "caddy run --config /etc/caddy/Caddyfile --adapter caddyfile"   frontend    6 minutes ago   Up 6 minutes   <IP_ADDRESS>:80->80/tcp, :::80->80/tcp, <IP_ADDRESS>:443->443/tcp, :::443->443/tcp, 443/udp, 2019/tcp
webvirtcloud-mariadb     mariadb:10.6.10          "docker-entrypoint.sh mariadbd"                                 mariadb     6 minutes ago   Up 6 minutes   3306/tcp
webvirtcloud-novnc       webvirtcloud-novnc       "python3 manage.py novncd --verbose"                            novnc       6 minutes ago   Up 6 minutes   <IP_ADDRESS>:6080->6080/tcp
webvirtcloud-rabbitmq    rabbitmq:3.10.13         "docker-entrypoint.sh rabbitmq-server"                          rabbitmq    6 minutes ago   Up 6 minutes   4369/tcp, 5671-5672/tcp, 15691-15692/tcp, 25672/tcp
webvirtcloud-scheduler   webvirtcloud-scheduler   "celery -A webvirtcloud beat -l info"                           scheduler   6 minutes ago   Up 6 minutes
webvirtcloud-worker      webvirtcloud-worker      "celery -A webvirtcloud worker -l info"                         worker      6 minutes ago   Up 6 minutes
[root@localhost webvirtcloud]#

However, I am unable to access my page
I see this configuration,But I don't have a domain name, I'm just testing it locally. How should I configure it
    environment:
      API_DOMAIN: "api.webvirt.cloud"
      ASSETS_DOMAIN: "assets.webvirt.cloud"
      CLIENT_DOMAIN: "client.webvirt.cloud"
      MANAGE_DOMAIN: "manage.webvirt.cloud"
      CONSOLE_DOMAIN: "console.webvirt.cloud"

I modified the configuration to the local IP address, but the front-end service cannot start
[root@localhost webvirtcloud]# docker compose ps
NAME                     IMAGE                    COMMAND                                                        SERVICE     CREATED              STATUS              PORTS
webvirtcloud-backend     webvirtcloud-backend     "gunicorn webvirtcloud.wsgi:application --bind <IP_ADDRESS>:8000"   backend     About a minute ago   Up About a minute   <IP_ADDRESS>:8000->8000/tcp
webvirtcloud-mariadb     mariadb:10.6.10          "docker-entrypoint.sh mariadbd"                                mariadb     About a minute ago   Up About a minute   3306/tcp
webvirtcloud-novnc       webvirtcloud-novnc       "python3 manage.py novncd --verbose"                           novnc       About a minute ago   Up About a minute   <IP_ADDRESS>:6080->6080/tcp
webvirtcloud-rabbitmq    rabbitmq:3.10.13         "docker-entrypoint.sh rabbitmq-server"                         rabbitmq    About a minute ago   Up About a minute   4369/tcp, 5671-5672/tcp, 15691-15692/tcp, 25672/tcp
webvirtcloud-scheduler   webvirtcloud-scheduler   "celery -A webvirtcloud beat -l info"                          scheduler   About a minute ago   Up About a minute
webvirtcloud-worker      webvirtcloud-worker      "celery -A webvirtcloud worker -l info"                        worker      About a minute ago   Up About a minute
[root@localhost webvirtcloud]#

The following is the log of the front-end service
[root@localhost webvirtcloud]# docker logs -f webvirtcloud-frontend
{"level":"info","ts":1699889236.6301916,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
Error: adapting config using caddyfile: ambiguous site definition: <IP_ADDRESS>:443
[root@localhost webvirtcloud]#

Hello,
We still working on deploy env. Can you try again and manage side? I added some fix but client app has some problem with API_DOMAIN settings (working on it).


Added Scala support for GDX Setup

Made it possible to generate Scala-based Gradle projects using the setup tool. Uses Scala 2.12.3, Scala Gradle plugin does not play nice with Android Gradle plugin so only Java support on that platform.

In order to support Android, Scala 2.11 will have to be used. Will fix shortly.

I don't think we are going to add Scala support to GDX Setup.


[Feature request] Markdown HTML syntax support

Is your feature request related to a problem? Please describe.
I'm using the app to work on existing markdown documentation for a project. Some HTML tags are used to be able to place bold text in a code block. However, HTML tags do not get parsed in the preview window, which is a bit annoying.
Describe the solution you'd like
HTML support like this.
Additional context

Preview should look like:

The markdown renderer Notepads currently uses is pretty basic and I have no plan or time to improve on it. I provided the markdown feature just for convince purposes and I am not actually trying to sell it as a markdown editor either..

If Someone was to add full Markdown support would you accept the Pull Request?


[Web] Expose API to force file system sync.

Mostly useful for modules and extensions that can't use FileAccess to write files.

Looks good. Can it be cherrypicked or will you make a 3.x PR?

I'll make a 3.x PR soon.


Automated updation of project structure in the readme file with workflow and python script

Sample:

@somyadipghosh Please assign me this issue.

@somyadipghosh Bro, Shouldn't this fetch atleast level 2? I could see other repos have given level 2 and level 3 for this.
Sample:

@J-B-Mugundh lvl 2 given


[BUG] Unused webhook and recovery backend deployment left in helm chart

Describe the bug (🐛 if you encounter this issue)
In longhorn/longhorn repo, we deleted the unused deployment templates
But in longhorn/chart repo, the templates got left
To Reproduce
X
Expected behavior
Should remove the deleted deployment in chart repo
Log or Support bundle
X
Environment

Longhorn version: v1.5.0
Installation method (e.g. Rancher Catalog App/Helm/Kubectl):
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:

Number of management node in the cluster:
Number of worker node in the cluster:

Node config

OS type and version:
CPU per node:
Memory per node:
Disk type(e.g. SSD/NVMe):
Network bandwidth between the nodes:

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal):
Number of Longhorn volumes in the cluster:

Additional context
https://github.com/longhorn/longhorn/issues/6246

The workaround has been provided at https://github.com/longhorn/longhorn/issues/6246#issuecomment-1625065311.

Just curious. After upgrade Longhorn helm chart from v1.4.2 to v1.5.0, I can actually see longhorn-recovery-backend and longhorn-admission-webhook being terminated and there will be no these pods in v1.5.0:
$ helm upgrade longhorn longhorn/longhorn --namespace longhorn-system --version 1.5.0
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/yang/Code/automation/terraform/aws/ubuntu/k3s.yaml
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/yang/Code/automation/terraform/aws/ubuntu/k3s.yaml
kubectl get pods -n longhorn-system -w
Release "longhorn" has been upgraded. Happy Helming!
NAME: longhorn
LAST DEPLOYED: Fri Jul  7 17:48:51 2023
NAMESPACE: longhorn-system
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
Longhorn is now installed on the cluster!

Please wait a few minutes for other Longhorn components such as CSI deployments, Engine Images, and Instance Managers to be initialized.

Visit our documentation at https://longhorn.io/docs/
$ kubectl get pods -n longhorn-system -w
NAME                                                  READY   STATUS              RESTARTS     AGE
engine-image-ei-f9e7c473-jg4fk                        1/1     Running             0            2m
engine-image-ei-f9e7c473-t2zlg                        1/1     Running             0            2m
engine-image-ei-f9e7c473-lcnhx                        1/1     Running             0            2m
longhorn-manager-k4s9h                                1/1     Running             0            14s
longhorn-manager-st6lt                                1/1     Running             0            14s
longhorn-manager-b7ppp                                1/1     Running             0            14s
longhorn-ui-545c67448b-2gmjg                          1/1     Running             0            12s
longhorn-ui-566c4798dc-qbc59                          1/1     Terminating         0            2m13s
longhorn-ui-545c67448b-rhv68                          1/1     Running             0            11s
longhorn-ui-566c4798dc-xrfdq                          1/1     Terminating         0            2m13s
longhorn-admission-webhook-8dccbf689-bl9jb            0/1     Terminating         0            10s
longhorn-recovery-backend-dbfbf95b7-h89g7             1/1     Terminating         0            2m13s
longhorn-recovery-backend-dbfbf95b7-nhqq7             1/1     Terminating         0            2m13s
csi-snapshotter-59ff78b47b-wlrvl                      1/1     Running             1 (5s ago)   108s
csi-attacher-689fdb475f-jhxpw                         1/1     Running             1 (5s ago)   110s
csi-resizer-847d645569-6n7ks                          1/1     Running             1 (5s ago)   109s
csi-provisioner-65dd48db7b-hr2r9                      1/1     Running             1 (5s ago)   109s
instance-manager-8d36d0b33fc982babdcb5b026ab6b76d     1/1     Running             0            4s
csi-resizer-847d645569-9vp42                          1/1     Running             1 (5s ago)   109s
csi-attacher-689fdb475f-q5wch                         1/1     Running             1 (5s ago)   110s
engine-image-ei-d911131c-2jmq4                        0/1     Running             0            4s
instance-manager-8a842a3ebe8f82d9d0d5245eafae4638     1/1     Running             0            4s
csi-provisioner-65dd48db7b-8sd84                      1/1     Running             1 (5s ago)   110s
csi-snapshotter-59ff78b47b-sk4hp                      1/1     Running             1 (5s ago)   108s
engine-image-ei-d911131c-s47xx                        0/1     Running             0            4s
csi-resizer-847d645569-2zjt2                          1/1     Running             1 (5s ago)   109s
csi-attacher-689fdb475f-69z4r                         1/1     Running             1 (5s ago)   110s
csi-snapshotter-59ff78b47b-mkjnk                      1/1     Running             1 (5s ago)   108s
csi-provisioner-65dd48db7b-pdn6m                      1/1     Running             1 (5s ago)   109s
engine-image-ei-d911131c-njrvp                        0/1     Running             0            4s
instance-manager-7e14f88043889e45483365083f21337d     0/1     ContainerCreating   0            1s
discover-proc-kubelet-cmdline                         0/1     ContainerCreating   0            1s
instance-manager-r-b951ab647a386ebec94c66261ccba1df   1/1     Terminating         0            2s
instance-manager-e-b951ab647a386ebec94c66261ccba1df   1/1     Terminating         0            2s
longhorn-driver-deployer-7df9d6c594-sfgww             1/1     Running             0            14s
longhorn-driver-deployer-5475b956b5-bhcv4             1/1     Terminating         0            2m13s
discover-proc-kubelet-cmdline                         1/1     Running             0            2s
longhorn-driver-deployer-5475b956b5-bhcv4             0/1     Terminating         0            2m14s
instance-manager-7e14f88043889e45483365083f21337d     1/1     Running             0            2s
instance-manager-r-b951ab647a386ebec94c66261ccba1df   0/1     Terminating         0            3s
instance-manager-e-b951ab647a386ebec94c66261ccba1df   0/1     Terminating         0            3s
longhorn-driver-deployer-5475b956b5-bhcv4             0/1     Terminating         0            2m14s
longhorn-driver-deployer-5475b956b5-bhcv4             0/1     Terminating         0            2m14s
longhorn-driver-deployer-5475b956b5-bhcv4             0/1     Terminating         0            2m14s
discover-proc-kubelet-cmdline                         0/1     Completed           0            2s
instance-manager-e-b951ab647a386ebec94c66261ccba1df   0/1     Terminating         0            3s
instance-manager-r-b951ab647a386ebec94c66261ccba1df   0/1     Terminating         0            3s
instance-manager-r-b951ab647a386ebec94c66261ccba1df   0/1     Terminating         0            3s
instance-manager-r-b951ab647a386ebec94c66261ccba1df   0/1     Terminating         0            3s
instance-manager-e-b951ab647a386ebec94c66261ccba1df   0/1     Terminating         0            3s
instance-manager-e-b951ab647a386ebec94c66261ccba1df   0/1     Terminating         0            3s
engine-image-ei-d911131c-s47xx                        1/1     Running             0            5s
engine-image-ei-d911131c-2jmq4                        1/1     Running             0            5s
engine-image-ei-d911131c-njrvp                        1/1     Running             0            5s
discover-proc-kubelet-cmdline                         0/1     Completed           0            3s
discover-proc-kubelet-cmdline                         0/1     Terminating         0            4s
discover-proc-kubelet-cmdline                         0/1     Terminating         0            4s
discover-proc-k3s-cmdline                             0/1     Pending             0            0s
discover-proc-k3s-cmdline                             0/1     Pending             0            0s
discover-proc-k3s-cmdline                             0/1     ContainerCreating   0            0s
discover-proc-k3s-cmdline                             1/1     Running             0            1s
discover-proc-k3s-cmdline                             0/1     Completed           0            2s
discover-proc-k3s-cmdline                             0/1     Completed           0            3s
discover-proc-k3s-cmdline                             0/1     Terminating         0            4s
discover-proc-k3s-cmdline                             0/1     Terminating         0            4s
csi-attacher-689fdb475f-69z4r                         1/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-jhxpw                         1/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-q5wch                         1/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-69z4r                         0/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-q5wch                         0/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-jhxpw                         0/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-jhxpw                         0/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-jhxpw                         0/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-jhxpw                         0/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-69z4r                         0/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-69z4r                         0/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-69z4r                         0/1     Terminating         1 (13s ago)   118s
csi-attacher-689fdb475f-q5wch                         0/1     Terminating         1 (14s ago)   119s
csi-attacher-689fdb475f-q5wch                         0/1     Terminating         1 (14s ago)   119s
csi-attacher-689fdb475f-q5wch                         0/1     Terminating         1 (14s ago)   119s
csi-attacher-f98ff75fb-kj4lx                          0/1     Pending             0             0s
csi-attacher-f98ff75fb-8zmzw                          0/1     Pending             0             0s
csi-attacher-f98ff75fb-ln5xr                          0/1     Pending             0             0s
csi-attacher-f98ff75fb-8zmzw                          0/1     Pending             0             0s
csi-attacher-f98ff75fb-kj4lx                          0/1     Pending             0             0s
csi-attacher-f98ff75fb-ln5xr                          0/1     Pending             0             0s
csi-attacher-f98ff75fb-kj4lx                          0/1     ContainerCreating   0             0s
csi-attacher-f98ff75fb-ln5xr                          0/1     ContainerCreating   0             0s
csi-attacher-f98ff75fb-8zmzw                          0/1     ContainerCreating   0             0s
csi-attacher-f98ff75fb-kj4lx                          1/1     Running             0             1s
csi-provisioner-65dd48db7b-8sd84                      1/1     Terminating         1 (16s ago)   2m1s
csi-provisioner-65dd48db7b-pdn6m                      1/1     Terminating         1 (16s ago)   2m
csi-provisioner-65dd48db7b-hr2r9                      1/1     Terminating         1 (16s ago)   2m
csi-attacher-f98ff75fb-ln5xr                          1/1     Running             0             1s
csi-provisioner-65dd48db7b-8sd84                      0/1     Terminating         1 (16s ago)   2m1s
csi-provisioner-65dd48db7b-pdn6m                      0/1     Terminating         1 (16s ago)   2m
csi-provisioner-65dd48db7b-hr2r9                      0/1     Terminating         1             2m
csi-provisioner-65dd48db7b-pdn6m                      0/1     Terminating         1 (16s ago)   2m
csi-provisioner-65dd48db7b-pdn6m                      0/1     Terminating         1 (16s ago)   2m
csi-provisioner-65dd48db7b-pdn6m                      0/1     Terminating         1 (16s ago)   2m
csi-attacher-f98ff75fb-8zmzw                          1/1     Running             0             1s
csi-provisioner-65dd48db7b-8sd84                      0/1     Terminating         1 (17s ago)   2m2s
csi-provisioner-65dd48db7b-8sd84                      0/1     Terminating         1 (17s ago)   2m2s
csi-provisioner-65dd48db7b-8sd84                      0/1     Terminating         1 (17s ago)   2m2s
csi-provisioner-65dd48db7b-hr2r9                      0/1     Terminating         1             2m1s
csi-provisioner-65dd48db7b-hr2r9                      0/1     Terminating         1             2m1s
csi-provisioner-65dd48db7b-hr2r9                      0/1     Terminating         1             2m1s
csi-provisioner-65cb5cc4ff-m6j8p                      0/1     Pending             0             0s
csi-provisioner-65cb5cc4ff-jthw6                      0/1     Pending             0             0s
csi-provisioner-65cb5cc4ff-m6j8p                      0/1     Pending             0             0s
csi-provisioner-65cb5cc4ff-wmlcw                      0/1     Pending             0             0s
csi-provisioner-65cb5cc4ff-jthw6                      0/1     Pending             0             0s
csi-provisioner-65cb5cc4ff-wmlcw                      0/1     Pending             0             0s
csi-provisioner-65cb5cc4ff-m6j8p                      0/1     ContainerCreating   0             0s
csi-provisioner-65cb5cc4ff-jthw6                      0/1     ContainerCreating   0             0s
csi-provisioner-65cb5cc4ff-wmlcw                      0/1     ContainerCreating   0             0s
csi-provisioner-65cb5cc4ff-m6j8p                      1/1     Running             0             1s
csi-resizer-847d645569-6n7ks                          1/1     Terminating         1 (19s ago)   2m3s
csi-resizer-847d645569-9vp42                          1/1     Terminating         1 (19s ago)   2m3s
csi-resizer-847d645569-2zjt2                          1/1     Terminating         1 (19s ago)   2m3s
csi-provisioner-65cb5cc4ff-wmlcw                      1/1     Running             0             1s
csi-resizer-847d645569-6n7ks                          0/1     Terminating         1             2m3s
csi-resizer-847d645569-2zjt2                          0/1     Terminating         1 (19s ago)   2m3s
csi-resizer-847d645569-9vp42                          0/1     Terminating         1 (19s ago)   2m3s
csi-resizer-847d645569-2zjt2                          0/1     Terminating         1 (19s ago)   2m3s
csi-resizer-847d645569-2zjt2                          0/1     Terminating         1 (19s ago)   2m3s
csi-resizer-847d645569-2zjt2                          0/1     Terminating         1 (20s ago)   2m4s
csi-provisioner-65cb5cc4ff-jthw6                      1/1     Running             0             2s
csi-resizer-847d645569-9vp42                          0/1     Terminating         1 (20s ago)   2m4s
csi-resizer-847d645569-9vp42                          0/1     Terminating         1 (20s ago)   2m4s
csi-resizer-847d645569-9vp42                          0/1     Terminating         1 (20s ago)   2m4s
csi-resizer-847d645569-6n7ks                          0/1     Terminating         1             2m4s
csi-resizer-847d645569-6n7ks                          0/1     Terminating         1             2m4s
csi-resizer-847d645569-6n7ks                          0/1     Terminating         1             2m4s
csi-resizer-77cddbfc7c-gwnlb                          0/1     Pending             0             0s
csi-resizer-77cddbfc7c-2td48                          0/1     Pending             0             0s
csi-resizer-77cddbfc7c-mgzv7                          0/1     Pending             0             0s
csi-resizer-77cddbfc7c-gwnlb                          0/1     Pending             0             0s
csi-resizer-77cddbfc7c-2td48                          0/1     Pending             0             0s
csi-resizer-77cddbfc7c-mgzv7                          0/1     Pending             0             0s
csi-resizer-77cddbfc7c-gwnlb                          0/1     ContainerCreating   0             0s
csi-resizer-77cddbfc7c-2td48                          0/1     ContainerCreating   0             0s
csi-resizer-77cddbfc7c-mgzv7                          0/1     ContainerCreating   0             0s
csi-resizer-77cddbfc7c-gwnlb                          1/1     Running             0             1s
csi-snapshotter-59ff78b47b-sk4hp                      1/1     Terminating         1 (22s ago)   2m5s
csi-snapshotter-59ff78b47b-wlrvl                      1/1     Terminating         1 (22s ago)   2m5s
csi-snapshotter-59ff78b47b-mkjnk                      1/1     Terminating         1 (22s ago)   2m5s
csi-resizer-77cddbfc7c-mgzv7                          1/1     Running             0             1s
csi-snapshotter-59ff78b47b-sk4hp                      0/1     Terminating         1 (22s ago)   2m5s
csi-snapshotter-59ff78b47b-wlrvl                      0/1     Terminating         1 (22s ago)   2m5s
csi-snapshotter-59ff78b47b-mkjnk                      0/1     Terminating         1 (22s ago)   2m5s
csi-snapshotter-59ff78b47b-mkjnk                      0/1     Terminating         1 (22s ago)   2m5s
csi-resizer-77cddbfc7c-2td48                          1/1     Running             0             2s
csi-snapshotter-59ff78b47b-mkjnk                      0/1     Terminating         1 (23s ago)   2m6s
csi-snapshotter-59ff78b47b-mkjnk                      0/1     Terminating         1 (23s ago)   2m6s
csi-snapshotter-59ff78b47b-sk4hp                      0/1     Terminating         1 (23s ago)   2m6s
csi-snapshotter-59ff78b47b-sk4hp                      0/1     Terminating         1 (23s ago)   2m6s
csi-snapshotter-59ff78b47b-sk4hp                      0/1     Terminating         1 (23s ago)   2m6s
csi-snapshotter-59ff78b47b-wlrvl                      0/1     Terminating         1 (23s ago)   2m6s
csi-snapshotter-59ff78b47b-wlrvl                      0/1     Terminating         1 (23s ago)   2m6s
csi-snapshotter-59ff78b47b-wlrvl                      0/1     Terminating         1 (23s ago)   2m6s
csi-snapshotter-78cb65cc4f-74nwf                      0/1     Pending             0             0s
csi-snapshotter-78cb65cc4f-74nwf                      0/1     Pending             0             0s
csi-snapshotter-78cb65cc4f-9x6r8                      0/1     Pending             0             0s
csi-snapshotter-78cb65cc4f-6jvx8                      0/1     Pending             0             0s
csi-snapshotter-78cb65cc4f-9x6r8                      0/1     Pending             0             0s
csi-snapshotter-78cb65cc4f-6jvx8                      0/1     Pending             0             0s
longhorn-csi-plugin-fdxpq                             0/3     Pending             0             0s
csi-snapshotter-78cb65cc4f-74nwf                      0/1     ContainerCreating   0             0s
csi-snapshotter-78cb65cc4f-9x6r8                      0/1     ContainerCreating   0             0s
csi-snapshotter-78cb65cc4f-6jvx8                      0/1     ContainerCreating   0             0s
longhorn-csi-plugin-fdxpq                             0/3     Pending             0             0s
longhorn-csi-plugin-q8k4b                             0/3     Pending             0             0s
longhorn-csi-plugin-h648x                             0/3     Pending             0             0s
longhorn-csi-plugin-q8k4b                             0/3     Pending             0             0s
longhorn-csi-plugin-h648x                             0/3     Pending             0             0s
longhorn-csi-plugin-fdxpq                             0/3     ContainerCreating   0             0s
longhorn-csi-plugin-q8k4b                             0/3     ContainerCreating   0             0s
longhorn-csi-plugin-h648x                             0/3     ContainerCreating   0             0s
longhorn-ui-566c4798dc-qbc59                          0/1     Terminating         0             2m32s
longhorn-ui-566c4798dc-qbc59                          0/1     Terminating         0             2m33s
longhorn-ui-566c4798dc-qbc59                          0/1     Terminating         0             2m33s
longhorn-ui-566c4798dc-qbc59                          0/1     Terminating         0             2m33s
csi-snapshotter-78cb65cc4f-74nwf                      1/1     Running             0             1s
longhorn-ui-566c4798dc-xrfdq                          0/1     Terminating         0             2m33s
csi-snapshotter-78cb65cc4f-6jvx8                      1/1     Running             0             1s
longhorn-csi-plugin-fdxpq                             3/3     Running             0             1s
csi-snapshotter-78cb65cc4f-9x6r8                      1/1     Running             0             2s
longhorn-csi-plugin-q8k4b                             3/3     Running             0             2s
longhorn-ui-566c4798dc-xrfdq                          0/1     Terminating         0             2m34s
longhorn-csi-plugin-h648x                             3/3     Running             0             2s
longhorn-ui-566c4798dc-xrfdq                          0/1     Terminating         0             2m34s
longhorn-ui-566c4798dc-xrfdq                          0/1     Terminating         0             2m34s
longhorn-recovery-backend-dbfbf95b7-h89g7             0/1     Terminating         0             2m38s
longhorn-admission-webhook-8dccbf689-bl9jb            0/1     Terminating         0             35s
longhorn-recovery-backend-dbfbf95b7-nhqq7             0/1     Terminating         0             2m38s
longhorn-recovery-backend-dbfbf95b7-h89g7             0/1     Terminating         0             2m39s
longhorn-recovery-backend-dbfbf95b7-h89g7             0/1     Terminating         0             2m39s
longhorn-recovery-backend-dbfbf95b7-h89g7             0/1     Terminating         0             2m39s
longhorn-admission-webhook-8dccbf689-bl9jb            0/1     Terminating         0             36s
longhorn-admission-webhook-8dccbf689-bl9jb            0/1     Terminating         0             36s
longhorn-admission-webhook-8dccbf689-bl9jb            0/1     Terminating         0             36s
longhorn-recovery-backend-dbfbf95b7-nhqq7             0/1     Terminating         0             2m39s
longhorn-recovery-backend-dbfbf95b7-nhqq7             0/1     Terminating         0             2m39s
longhorn-recovery-backend-dbfbf95b7-nhqq7             0/1     Terminating         0             2m39s

So in which situation we will encounter longhorn-recovery-backend and longhorn-admission-webhook still remain in v1.5.0 and start crashing with errors?

Just for information. longhorn-recovery-backend and longhorn-admission-webhook can be terminated automatically during upgrade from v1.4.2 to v1.5.0. Probably need to figure out what triggers the situation that they still exist after upgrade and start crashing with errors.

@yangchiu
Maybe is a flaky case?
I did add the deletion in upgrade path to delete these service deployments
But maybe helm apply the templates after longhorn-manager finished upgrade path?

@ChanYiLin Can u reproduce this as well?

I'm seeing Error: UPGRADE FAILED: release longhorn failed, and has been rolled back due to atomic being set: deployments.apps "longhorn-recovery-backend" not found when upgrading to v1.5.0. Is that related to this issue?

Tried the deletion of Deployments as hinted at in this comment and the workaround mentioned in #6246, the original post was also needed. However, the update still did not go through before the Helm upgrade command timed out. Had to use --force on the helm rollback cmd for things to back in a working state for the Longhorn system.

Tested on:
v1.27.1+k3s1 + helm v3.8.0
v1.27.1+k3s1 + helm v3.21.1
v1.24.7+k3s1 + helm v3.8.0
v1.24.7+k3s1 + helm v3.21.1
didn't encounter errors during upgrade yet. It would be helpful if users can provide more about the environment setup.

Some user encountered the issue because they use GitOps tools with Helm to deploy the system
https://github.com/longhorn/longhorn/issues/6246#issuecomment-1626398449
And the tools might try to recreate those deployments declared in the Chart
cc @innobead @yangchiu

Verified pass in

longhorn/chart v1.5.x 8771f2
longhorn-manager v1.5.x 2c5b62

Precondition

Deploy Longhorn v1.4.2 by helm chart
2 deployments with RWO and RWX volume, create backup for each volume.
1 Ophaned replica
concurrent-automatic-engine-upgrade-per-node-limit = 1

After upgrade Longhorn to v1.5.x by helm

longhorn-conversion-webhook, longhorn-admission-webhook, longhorn-recovery-backend pod terminated.
Deployment data intact.
Restore volume worked properly.


FR: Add support for aac audio.

I store most of my recordings in aac so it would be nice if this extension could support that. m4a files can already be played inside Obsidian by itself. Would it be possible for this extension to work with m4a files? I understand if it is not feasible

I just made a new version that should support m4a files. I'm going to close this issue, but let me know if it isn't working for you.


Rebalance the game

My current thoughts on rebalancing:
The Player

Decrease the initial amount of bullets you get. You should start with a really low amount, so each new heart you get from an enemy feels valuable, and feel like you're getting stronger, even with just this short demo level.
Until such a time we can implement the leveling-up system, make the heart-bar extend to fit your max-heartage. This means every heart you pick up is added to a max-heart variable, and every time you lose one forever (by getting hit by an enemy), the max-heart variable is decremented. The heart-bar class will need to be updated to read from the player's max-heart variable, instead of from a constant.

The Baddies

Increase the range of their bullets.
Decrease the firing rate of their bullets to, like, 500 ms.
Make their bullets bigger, so you can really see them.
Add more baddies.

Done! Would recommend we consider some binding-of-isaac style controls in addition to these changes, though. The aiming is really really hard in the heat of battle.


#1183 add note to staticsitegen documentation

add note to staticsitegen documentation about temporarily using fork https://github.com/ctxis/django-medusa to generate static versions of sites that contain Documents

Thanks! Will hopefully have Wagtail working on vanilla django-medusa before 1.0

:+1:

This can now be worked around by setting the SENDFILE_BACKEND setting to sendfile.backends.simple.
https://github.com/torchbox/wagtail/blob/40092e18526d59c8ca0966743de7f93d14a8304c/docs/contrib/staticsitegen.rst#installing-django-medusa


right x debt

Hi! I love how the paper is evolving! Concerning my changes: I switched gift to right, wrote a little under that and made a few corrections. Will keep working tomorrow and on the next few days. Let me know your thoughts so I can help you better! Best,
Paula

Hi Paula, wont be able to merge this one (i did merge the addition of Right vs Debt tho). It is best practice to do 1 pull request per change so it's easier to review. Amazing work btw.

No worries. I am still finding my way around github and haven't figured how to edit a patch after I made the pull request, is that possible?


fix(ib): Fix Inline HTML tags and add support for sub, sup.

Fixes #103
Describe the changes you have made in this PR -

Added Inline HTML Syntax
Added Subscript and Superscript markdown builder

Note: To be merged after #115

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

33 of 127 (25.98%)  changed or added relevant lines in 12 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.2%) to 74.468%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/utils/unicode_map.dart
0
1
0.0%

lib/ui/views/ib/syntaxes/ib_md_tag_syntax.dart
0
3
0.0%

lib/ui/views/ib/builders/ib_pop_quiz_builder.dart
1
6
16.67%

lib/ui/views/ib/syntaxes/ib_inline_html_syntax.dart
1
6
16.67%

lib/ui/views/ib/builders/ib_subscript_builder.dart
0
6
0.0%

lib/ui/views/ib/builders/ib_superscript_builder.dart
0
6
0.0%

lib/ui/views/ib/components/ib_pop_quiz.dart
0
28
0.0%

lib/ui/views/ib/components/ib_pop_quiz_button.dart
0
40
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-1.2%

Covered Lines:
3885

Relevant Lines:
5217

💛  - Coveralls


Relative time ambiguity across DST adjustments

Current behavior 😯
When gix-date::date time::parse::relative::various is run in an environment that uses local time in a time zone that has daylight savings clock adjustments, it fails in the two weeks after daylight saving time changes. All other gix-date tests pass.
For example, my time zone is Eastern Time, which had a DST clock adjustment from EDT (UTC-4) to EST (UTC-5) on 3 November 2024. Since then, and until two weeks later, the test failed when I ran it locally. Here's a run from 9 November 2024:
        FAIL [   0.310s] gix-date::date time::parse::relative::various

--- STDOUT:              gix-date::date time::parse::relative::various ---

running 1 test
test time::parse::relative::various ... FAILED

failures:

failures:
    time::parse::relative::various

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 27 filtered out; finished in 0.31s

--- STDERR:              gix-date::date time::parse::relative::various ---
thread 'time::parse::relative::various' panicked at gix-date/tests/time/parse.rs:195:9:
assertion `left == right` failed: relative times differ
  left: 2024-10-26T20:22:51Z
 right: 2024-10-26T19:22:51Z
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

------------
     Summary [   0.325s] 29 tests run: 28 passed, 1 failed, 0 skipped
        FAIL [   0.310s] gix-date::date time::parse::relative::various
error: test run failed

Under those conditions, the time is off by one hour, due to ambiguity of phrases like 2 weeks ago. If there was a recent daylight savings adjustment to local time, then was 2 weeks ago the current time minus the usual 336 hours? Or was 2 weeks ago the time, fourteen calendar days prior, at which local clocks showed the time that local clocks show now? Often these two interpretations of relative times coincide, but they do not always.
The test failed on GNU/Linux, macOS, and Windows, and at least on GNU/Linux and macOS, it went away when TZ=UTC is set. With no change to the code, the test started passing again, on all systems, on 17 November 2024, but the bug is still present.
This bug has not been detected automatically on CI, because the environment on GitHub Actions runners uses UTC rather than local time.
(This is the bug that the mention of TZ=UTC in d74e919 (#1652) alludes to.)
Expected behavior 🤔
I am uncertain whether it is the code under test, or the test itself, that should be changed. But if we want to interpret relative times like "2 weeks ago" in the same way GNU/Linux date -d does, and in the way I think Git does (see below for details), then the code under test would have to be changed.
Either way, the bug is not specific to 2-week intervals. if the code is wrong, then the test's use of 2 weeks ago is merely a limitation in when the test is able to identify the code as wrong. If the test is wrong, then while the failure only occurs under limited conditions, the interpretation of relative time that it expresses is still broader.
This is to say that even if it is (only) the test that should change, I think making the interval shorter so that it fails less often would not be the right way to go about it.
Also, either way, we should probably make the test check multiple relative time strings representing intervals of widely varying length.
Git behavior
I don't know if I'm looking at the most relevant Git behavior, but the easiest to examine are the tests in t0006-date.sh. If I understand correctly, relative date strings represent exact numbers of seconds elapsed:
check_relative() {
	t=$(($GIT_TEST_DATE_NOW - $1))
	echo "$t -> $2" >expect
	test_expect_${3:-success} "relative date ($2)" "
	test-tool date relative $t >actual &&
	test_cmp expect actual
	"
}

check_relative 5 '5 seconds ago'
check_relative 300 '5 minutes ago'
check_relative 18000 '5 hours ago'
check_relative 432000 '5 days ago'
check_relative 1728000 '3 weeks ago'
check_relative 13000000 '5 months ago'
check_relative 37500000 '1 year, 2 months ago'
check_relative 55188000 '1 year, 9 months ago'
check_relative 630000000 '20 years ago'
check_relative 31449600 '12 months ago'
check_relative 62985600 '2 years ago'

Those tests pass when run today, on an Arch Linux system set to America/New York and using local time, including when the script is run directly. If git behaved analogously to the current behavior of gix-date, then I would expect the 3 weeks ago and 5 months ago cases, as well as some others, to have failed. I ran that test script at the tip of the master branch, with:
make -j10
cd t
./t0006-date.sh

So that would agree with what gix-date's test suite is asserting, while disagreeing with the current gix-date behavior. It seems to me that this may be a reason to consider our existing test in gix-date correct, and the current behavior of the gix-date being tested as incorrect.
Steps to reproduce 🕹
Although the tests don't fail in my time zone anymore, because 2 weeks ago is now after the DST adjustment, there are a few approaches that may reproduce it.
One is to use a tool like faketime. This carries some subtleties, though, since accesses to date and time information are not always guaranteed to go through the functions it patches, and since cursory experimentation with faketime and the date command suggests that locale-sensitive interpretation of strings like EST and EDT as time zone offsets does not always behave the way it did at the date and time faketime attempts to fake it to.
Another is to set the clock back. This will carry fewer subtleties but may be undesirable.
Instead, assuming one's time zone has DST adjustments, I suggest reproducing this by modifying the interval in the test from 2 weeks ago to an interval that refers to a date where local time used a different UTC offset than currently.
5 months ago would be nearly ideal, but cannot be used because we don't yet parse months or years, so that would give InvalidDateString { input: "5 months ago" }. (The absence of parsing of months or years might be considered a bug, but it is not this bug.)
A sufficient number of weeks will work, though. For example, starting in the top-level gitoxide directory, the interval can be changed from 2 to 20 weeks, which is approximately 5 months and should produce the bug at most (though not all) times of the year in most time zones where DST adjustments are made:
cd gix-date
sed -i.orig 's/two_weeks_ago/twenty_weeks_ago/; s/2\.weeks/20.weeks/; s/2 weeks ago/20 weeks ago/' tests/time/parse.rs
git --no-pager diff
cargo nextest run time::parse::relative::various

Edit: If #1697 is merged then the procedure here with sed -i will no longer be correct or needed, and the bug will automatically be observable at any time of year if it could be observed before at some time of year.
Running those commands on the test system produces the bug as intended:
ek in 🌐 catenary in gitoxide on  main is 📦 v0.38.0 via 🦀 v1.82.0
❯ cd gix-date

ek in 🌐 catenary in gitoxide/gix-date on  main is 📦 v0.9.1 via 🦀 v1.82.0
❯ sed -i.orig 's/two_weeks_ago/twenty_weeks_ago/; s/2\.weeks/20.weeks/; s/2 weeks ago/20 weeks ago/' tests/time/parse.rs

ek in 🌐 catenary in gitoxide/gix-date on  main [!?] is 📦 v0.9.1 via 🦀 v1.82.0
❯ git --no-pager diff
diff --git a/gix-date/tests/time/parse.rs b/gix-date/tests/time/parse.rs
index 545fbb7fc..8b0475c1d 100644
--- a/gix-date/tests/time/parse.rs
+++ b/gix-date/tests/time/parse.rs
@@ -179,9 +179,9 @@ mod relative {
     #[test]
     fn various() {
         let now = SystemTime::now();
-        let two_weeks_ago = gix_date::parse("2 weeks ago", Some(now)).unwrap();
-        assert_eq!(Sign::Plus, two_weeks_ago.sign);
-        assert_eq!(0, two_weeks_ago.offset);
+        let twenty_weeks_ago = gix_date::parse("20 weeks ago", Some(now)).unwrap();
+        assert_eq!(Sign::Plus, twenty_weeks_ago.sign);
+        assert_eq!(0, twenty_weeks_ago.offset);
         let expected = Zoned::try_from(now)
             .unwrap()
             // account for the loss of precision when creating `Time` with seconds
@@ -191,9 +191,9 @@ mod relative {
                     .mode(jiff::RoundMode::Trunc),
             )
             .unwrap()
-            .saturating_sub(2.weeks());
+            .saturating_sub(20.weeks());
         assert_eq!(
-            jiff::Timestamp::from_second(two_weeks_ago.seconds).unwrap(),
+            jiff::Timestamp::from_second(twenty_weeks_ago.seconds).unwrap(),
             expected.timestamp(),
             "relative times differ"
         );

ek in 🌐 catenary in gitoxide/gix-date on  main [!?] is 📦 v0.9.1 via 🦀 v1.82.0
❯ cargo nextest run time::parse::relative::various
   Compiling gix-date v0.9.1 (/home/ek/repos/gitoxide/gix-date)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.92s
------------
 Nextest run ID 55a072b6-40a8-4bd9-b177-58e4158ce1fe with nextest profile: default
    Starting 1 test across 2 binaries (28 tests skipped)
        FAIL [   0.014s] gix-date::date time::parse::relative::various

--- STDOUT:              gix-date::date time::parse::relative::various ---

running 1 test
test time::parse::relative::various ... FAILED

failures:

failures:
    time::parse::relative::various

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 27 filtered out; finished in 0.01s

--- STDERR:              gix-date::date time::parse::relative::various ---
thread 'time::parse::relative::various' panicked at gix-date/tests/time/parse.rs:195:9:
assertion `left == right` failed: relative times differ
  left: 2024-07-05T18:55:17Z
 right: 2024-07-05T17:55:17Z
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

  Cancelling due to test failure
------------
     Summary [   0.015s] 1 test run: 0 passed, 1 failed, 28 skipped
        FAIL [   0.014s] gix-date::date time::parse::relative::various
error: test run failed

Although less reproducible, it may be more intuitive to use a shorter interval. At the moment, 3 weeks is sufficient. A run changing 2 weeks to 3 (rather than 20) weeks can be seen  here.

Thanks so much for the detailed report.
I understand that Git interprets 2 weeks ago as the amount of seconds passed, whereas gix-date thanks to jiff now considers it to be 14 calendar days passed, which correctly incorporates the local time as affected by the TZ environment variable.
The dependence on the TZ environment variable was surprising to me and usually gitoxide crates make that explicit and/or overridable, but the way it's currently implemented here (or how jiff is used) makes this implicit.
Is it correct to say that in theory, if that time computation would be using UTC always without implicitly picking up the local time, it should work as expected?
If that's true, then using a jiff API that doesn't rely on the system timezone should constitute a fix.
Let me CC @BurntSushi here just so that he is informed, and might be able to share ideas on how to deal with this as well.
On another note

5 months ago would be nearly ideal, but cannot be used because we don't yet parse months or years, so that would give InvalidDateString { input: "5 months ago" }. (The absence of parsing of months or years might be considered a bug, but it is not this bug.)

I wasn't aware actually, and am surprised this is the case as it should be trivial to support. But maybe it wasn't done yet as with time, nothing truly is trivial 😅.

Let me CC @BurntSushi here just so that he is informed, and might be able to share ideas on how to deal with this as well.

Good idea. #1474 seems relevant, and especially this part, which I should've mentioned in the issue description, though I don't feel that I have a good handle on what ought to be done:
https://github.com/GitoxideLabs/gitoxide/blob/438ee4718b67d0eba8f4c6ebdfac64bd39f68ec7/gix-date/src/parse.rs#L134-L144
This is discussed at https://github.com/GitoxideLabs/gitoxide/pull/1474#discussion_r1694769209, which I hadn't noticed before.

Some other discussion in #1474 is relevant to:

5 months ago would be nearly ideal, but cannot be used because we don't yet parse months or years [...]

I wasn't aware actually, and am surprised this is the case as it should be trivial to support. But maybe it wasn't done yet as with time, nothing truly is trivial 😅.

Per https://github.com/GitoxideLabs/gitoxide/pull/1474#discussion_r1694769988, it looks like parsing months and years just never ended up being added, but that it is expected to work since #1474.

Thanks for digging that out!
The code example seems to show that it already attempts to be timezone independent, but it might not be working as expected? Something there must read TZ even though it shouldn't?
It feels we are onto something here.

Is it correct to say that in theory, if that time computation would be using UTC always without implicitly picking up the local time, it should work as expected?

Yes. In the UTC "time zone," there are zero time zone transitions. So days are always 24 hours.

The code example seems to show that it already attempts to be timezone independent, but it might not be working as expected? Something there must read TZ even though it shouldn't?

It looks like it's the test itself?
https://github.com/BurntSushi/gitoxide.git/blob/cb3149fec63dc9e366baf0399040d20161616b22/gix-date/tests/time/parse.rs#L202-L214
That Zoned::try_from will automatically use the system time zone.

I wasn't aware actually, and am surprised this is the case as it should be trivial to support. But maybe it wasn't done yet as with time, nothing truly is trivial 😅.

When I worked on the patch to add Jiff support, I didn't do months/years because that wasn't supported before. So I didn't want to add anything more than needed. But yes, Jiff should handle it fine. Jiff should make it trivial (assuming you give it a relative date, which I believe you do), but lots of things get this wrong. For example:
https://github.com/tailhook/humantime/blob/12ce6f50894a56a410b390e5608ac9db8afe2407/src/duration.rs#L305-L307

If the goal is to match git's behavior here, then yeah, I think you need to interpret 2 weeks ago as a fixed amount of time that never changes due to time zone transitions. I would personally argue that git is wrong here, or at least, git's behavior is questionable.

Thanks so much for chiming in!
And thanks for the hint about the test - it seems the code itself uses UTC, so it will produce 'flat' time, but the test asserts with timezoned time. A fix should thus be in the test itself, it should use UTC, at least if it wants to match Git.

I would personally argue that git is wrong here, or at least, git's behavior is questionable.

Probably the way these relative dates are used in is so fuzzy that humans also don't have a clue if it's right or wrong, so nobody filed a bug-report for this yet.
Something I'd be afraid of is people comparing both implementations, and mismatches will then be reported here. That seems like a good reason to match Git even though one could be more correct.

When I worked on the patch to add Jiff support, I didn't do months/years because that wasn't supported before. So I didn't want to add anything more than needed.

Yes, I remember that, but don't remember who did what and why to which extend. This is to say I my note wasn't meant as criticism, just genuine surprise.
In any case, I think now we seem to know how to proceed here, which could be…

fix the test to not rely on the system timezone
(optionally) add the remaining conversions for months and years for completeness

And that should fix this issue if I am not missing something.

That sounds right to me!

(optionally) add the remaining conversions for months and years for completeness

I've done just this part in #1702, since it seems like it's been wanted for some time and there's no strong reason to put it off. That PR does not fix this issue, however. It actually exacerbates it, in that the ambiguity described in this issue will apply not just to "days" and "weeks" but also to the newly recognized "months" and "years". However, the changes to the test that seem natural to do alongside recognizing those units (and that test that they are recognized) also make the contours of this issue clearer.


Add callback to primitive interface

Summary
Allow users to specify a callback function to stream interim results, such as error mitigation progress, of primitives.
Details and comments
Fixes #504

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.3%

Covered Lines:
3321

Relevant Lines:
5111

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.3%

Covered Lines:
3321

Relevant Lines:
5111

💛  - Coveralls


Use -fprint-unicode-syntax when --use-unicode is enabled

This allows GHC to render * as its Unicode representation, among other
things.

Merged with 1ee7e9a058f035926ef9d37ef58af409e0c3c998.


Taproot: Create & Import Wallet UX

Task Description
As we're introducing Taproot wallets from this release, we'll need the option to select the purpose(Native Segwit or Taproot) on the Add New Wallet screen(similar to how we've provided during the import flow, not on an independent screen tho?).

Note:

It should be an advanced(optional) thing.
The path is going to be read-only; determined by the purpose.

TBD:
Do we also want to give Legacy and Wrapped Segwit as an option while creating a new wallet? @antuz123
They are currently available during import.

https://xd.adobe.com/view/f1543c84-c25a-4ad6-81ca-1e0c540e956e-a407/screen/1ed8e52f-3216-4994-bd50-7e48d9f09054/

Verified in live app


How can i deal with repeat logs

When I try to post a large of same logs to platform.  I noticed that some logs was repeat and become one.How canI do something to make my platform to set logs not repeat? thanks sir

Are you referring to you have stacks of logs based on the log source? Or are you referring to you are seeing duplicate log messages because you have your program running on multiple machines?

@786744873 can you please respond to the questions above.


identical filter are only once allowed in the filter-container

if the users does try to add the same filter again, please fire an event (ideally with the id or a uniquie way to select the already existing data-filter)

This issue was moved to zazuko/zack-search#12


[Feature Request] Type parameters for Classes

Type parameters are only allowed in standard library

But why?

Generics add a lot of complexity to the language, and is hard to get right. This is something we would like to add to the language at some point, but I would say that we're not close yet.
For example, one thing to consider is how to implement [variance](https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science). Today, Pkl does not perform subtype checking.
We also have some bugs with type parameters in the core language that will need to be fixed before we can start to consider something like this.


clicking on timestamp doesn't focus on video

Can we have it when we click on timestamp that the video gets focus. This behaviour is normal with using general comments in YouTube but not in YCS. thanks for consideration

I don't want this, at all! If this is implemented, it should be an optional opt-in setting, not something default.
This would totally destroy the extension user experience while watching videos in PiP.

I don't want this, at all! If this is implemented, it should be an optional opt-in setting, not something default.
This would totally destroy the extension user experience while watching videos in PiP.

I didn't realise this could cause an issue with pip. have you tested with normal timeline links to see if it affects it? if it does then allowing it as an option would be cool

I'm not a coder but if it can detect it's in pip then you can alter the behaviour so it takes focus if not in pip and doesn't take focus if in pip

Yeah, it's an issue with normal comments, it scrolls to the top, massively annoying! I converted this extension to an userscript that fixes it here:
https://gist.github.com/NewsGuyTor/ff655400ff400d192de7e83759386971
BTW, I recommend that you install an embedded PIP extension (like Enhancer) installed instead, I don't get why you'd ever prefer to lose context of where you are in a comment thread. It's a much more pleasant experience (vid has no sound):
https://github.com/pc035860/YCS-cont/assets/19603024/fec39f6e-4cbc-452d-8b13-f0db9eae22b8

I can highly recommend this chrome addon that shows timestamped comments at the appropriate time on the upper-corner of the YouTube video: Timestamped YouTube Comments

Features:

Pause to persist a comment
Hover over a comment to see its replies
Click the Comments icon in the video bar to toggle comments on/off
Click on a comment to open a new tab with that comment at the top of the comment section (useful for replying to comments)

Yeah, it's an issue with normal comments, it scrolls to the top, massively annoying! I converted this extension to an userscript that fixes it here: https://gist.github.com/NewsGuyTor/ff655400ff400d192de7e83759386971
BTW, I recommend that you install an embedded PIP extension (like Enhancer) instead, I don't get why you'd ever prefer to lose context of where you are in a comment thread. It's a much more pleasant experience (vid has no sound):
ScreenFlow.mp4

I tested myself and can see how annoying this is. But can you also see how annoying it could be for those that don't use pip?
I've used enhancer before for that pip functionality. I found I liked video being paused when viewing comments.
but I found a nice extension that "Comments - Scroll to comment (after clicking on a timestamp or changing fullscreen mode)"
it's called Tweaks, it's a bloody amazing extension. you can set a shortcut for that action. so I click on a timestamp. video takes focus. then I can click the shortcut so it goes exactly back to where I clicked the timeline.
If you don't use pip, can you see I have to scroll up to watch the video and I lose focus on the comment anyway

I can highly recommend this chrome addon that shows timestamped comments at the appropriate time on the upper-corner of the YouTube video: Timestamped YouTube Comments
Features:

Pause to persist a comment
Hover over a comment to see its replies
Click the Comments icon in the video bar to toggle comments on/off
Click on a comment to open a new tab with that comment at the top of the comment section (useful for replying to comments)

that's actually cool thanks

@NewsGuyTor if you want more information on tweaks. let me know.


Hackathon hyperbolic trig functions

This PR was created by cherry picking the following commit: https://github.com/apavlo/terrier/commit/e13a2c3098c8a76eef15a6c649d3b39a9a964c73 and then manually resolving conflicts, updating certain sections, and converting the JUnit tests to SQL trace tests.
The original PR can be found here: https://github.com/apavlo/terrier/pull/4
This works towards resolving #1001

This is likely blocked due to a precision issue causing incorrect results of cosh, sinh, and tanh


fix(app): Do not override existing moz:firefoxOptions

As with other PR, I have trouble running the tests. I get green 0 passing.

Let's make sure we have this also ported to v5 before we merge and release it.

https://github.com/webdriverio/webdriverio/pull/2957

released with v0.1.3


Encapsulate SceneHistory. A little.

This makes sense. Thanks for the PR Kent. Looking forward to you future contributions :).


In Postgres, wait until ParseComplete before we cache the query

Net result right now is if there is a syntax error in the SQL query, we cache it but postgres throws it out and you get a bunch of inane errors like __sqlx_statement_N does not exist.
So first execution of syntax error query returns the syntax error as expected.
After that, no matter how you swing it, all executions of that query will return a useless error like "__sqlx_statement_2 does not exist".

I believe I had this fixed on a branch which must have gotten lost or overwritten.

I remember you talking about working on it.


add --authentication-type none for kfk users --alter like it is for authorization type

Won't do - since authentication-type is mandatory


i18n "Clean water and wastewater infrastructure" sidepanel title is no longer translated in Spanish version

In the Spanish version of the map, on the side panel, the title "Clean water and wastewater infrastructure" is no longer shown in Spanish. I believe this may have been a recent regression. If I encounter any additional recent regressions I'll add to this ticket if it's still in progress.

[ ] make sure that that "Cleanwater and wastewater infrastructure" on the side panel in Spanish is shown in Spanish: "Infraestructura crÍtica paraa aguaa no contaminada y residuos"

Include CICD


User Consent UI wireframe

@HunnySajid please provide an updated screen capture for this issue and a link to the figma.

that's already merged


about the additive Gaussian noise removal

Thanks for your interesting work! I want to ask about the task of additive Gaussian noise removal. Are the different levels of noise dataset ( i.e., 30, 50, 70) trained in a model together or trained separately for each level?

Thank you for your interest in our work!
The three levels of noise are used together for training a single model.
A level of noise is randomly chosen to generate noise added to a batch of inputs in each forward.


Update install, release instructions for COPR/PPA

This commit

updates install instructions to rely on Fedora COPR
packages and Ubuntu Launchpad PPA packages where applicable.
adds additional compile from source instructions for
recent Fedora and OpenSuSE distributions.
updates release instructions to account for the new COPR/PPA
packages that need to be confirmed to be successfully built.
Cleans up recent Fedora/CentOS/RHEL build from source command
with a small enhancement to the Makefile.

Once this passes CI, it can be squashed and merged.


Create and implement scenario for load testing of the webapp

Requirement

The platform can support 200 concurrent voters over multiple days

Testing Scenarios:

Emulate voting of all the delegates and alternates, and check for success or report failure. Important consideration: - all delegates (65) and all alternates (65) try to vote at the same time. Non-active voters should fail but the overall voting should be successful
-Emulate ~200 concurrent users (viewers is sufficient) to check if the platform is supporting the load

ToDo:

[x] Decide on the tool to use for load testing scenario
[ ] Implement load testing scenario.

Sample stress test result is available at

https://cardanoapi.github.io/ccv-test-reports/stress-tests/


Fix hard-coded corner radii

Problem
Two widgets had hard-coded corner radius instead of using the WidgetVisuals value.
Solution
Remove the hard-coded values and use the style instead.
Context
I tried to make a style with non rounded corners and noticed that certain widgets kept their roundness.
It turned out that there were two widgets with hard-coded values. This PR uses the value from the WidgetVisual which seems like the right thing to do. Maybe there's a reason not to but it seems to fix my problem with no apparent downsides.
Check.sh Issues
Note that I tried running check.sh but it fails to compile 'speech-dispatcher'. Most likely because the version on libspeechd I installed on my machine (latest on Arch linux) is too new and doesn't work with the existing crate.

Look good, but needs cargo fmt.
Please file an issue about check.sh and what line in it fails, and with what message!

Look good, but needs cargo fmt.
Please file an issue about check.sh and what line in it fails, and with what message!

Done and done


Invite Campaigns limits [GOVERNANCE Referendum #4]

II. SEEDS Meta-Agreements
A. Campaigns funds are released only as Invite Campaigns with the following parameters: - Maximum limit for invite campaigns 333k per Campaign and max 1000 Seeds per invite INCLUDING any rewards & other costs;

Introduce escrow accounts for invite campaigns (so campaign runners can’t be hacked or otherwise spend/lose these Seeds);
All invite Seeds are automatically planted and you need to be a resident to unplant these Seeds.

Done


Cannot compile the firmware with Esphome 2023.11.6

Getting the following error during the compile:
src/main.cpp: In function 'void setup()':
src/main.cpp:651:44: error: invalid new-expression of abstract class type 'esphome::esp_adf::ESPADFSpeaker'
   box_speaker = new esp_adf::ESPADFSpeaker();
                                            ^
In file included from src/esphome.h:28,
                 from src/main.cpp:3:
src/esphome/components/esp_adf/speaker/esp_adf_speaker.h:20:7: note:   because the following virtual functions are pure within 'esphome::esp_adf::ESPADFSpeaker':
 class ESPADFSpeaker : public ESPADFPipeline, public speaker::Speaker, public Component {
       ^~~~~~~~~~~~~
In file included from src/esphome/components/esp_adf/speaker/esp_adf_speaker.h:10,
                 from src/esphome.h:28,
                 from src/main.cpp:3:
src/esphome/components/speaker/speaker.h:21:16: note: 	'virtual bool esphome::speaker::Speaker::has_buffered_data() const'
   virtual bool has_buffered_data() const = 0;

I got this error as well at first, but after re-compiling it seems to work.

Having the same issue did you resolve ?

Strange, but true, recompiling  solved it.

Can’t reproduce anymore


Integrate LLamaSharp project

https://github.com/SciSharp/LLamaSharp
You need to create a separate LangChain.Providers.LLamaSharp provider and add a minimal implementation of things from LangChain.Providers.Abstractions.

accordind to their github, as llama progresses it looses compatibility with old models.
i was able to run v0.3.0 together with matching model. The latest version is 0.7.0(which has different API) but there is no clear instructions on how to run it.
Also there is different backends avaliable(CPU, Cuda, Mac)
What i suggest is to implement v0.3.0 without any backend included. Then user would have to add a reference to required backend during usage. In this was we would have something working.

I haven't used it, so if you think so and want to do it, then that's ok for me.
Now we are better off having something than having nothing. We may fix this in the future if necessary.

Hi @TesAnti ,
I have some suggestions and requests.

0.7.0 model conversion method: https://github.com/ggerganov/llama.cpp#prepare-data--run or https://github.com/SciSharp/LLamaSharp/blob/master/docs/LLamaModel/quantization.md
Embeddings: https://github.com/SciSharp/LLamaSharp/blob/master/docs/LLamaModel/embeddings.md
Tokenization: https://github.com/SciSharp/LLamaSharp/blob/master/docs/LLamaModel/tokenization.md


New METS structure for audio and video ingests (File Group and Usage Attributes)

Background
Audio and video ingests can have 1) multiple audio or video files, 2) transcripts, and or 3) poster images.
To handle multiple files or transcripts, the item used to be ingested into Goobi (via an old workflow we're no longer using) as a multiple manifestation so each file or transcript had its own METS and they were tied together by an anchor file. The poster image was picked up from a local network drive.
This no longer works for us for two reasons:

For the storage service migration, the poster images for the audio and video ingests were included in the bag and are now served from the Storage Service. The local network drive for poster images should no longer be used but we have no way to add the poster images into the bag through Goobi.
We no longer want to create multiple manifestations for audio and video ingests because they are not true multiple manifestations. We instead want everything together in the same ingest.

New A/V Ingest Workflow and METS
Working with Intranda, we have re-created our entire A/V workflow in staging Goobi to allow for multiple audio or video files, transcripts, and poster images to be ingested together through Goobi and be stored in one bag in the Storage Service.
This change means that the METS for audio and video ingests has had to be re-written as well. It now includes file groups with use attributes for DDS to use. DDS needs to be updated to be able to understand and use the FileGroups in the new METS.
File Group and Use Explanations:
File Group: Masters, Use: Preservation
This file group will only be seen in the METS for ingests that include an MXF file. The MXF is too large to use so DDS should ignore this file in the METS and the MXF will be sent to Deep Store in the Storage Service.
File Group: Objects, Use: Access
This file group will contain files like MP4s (which will be bagged with an MXF), and MPGS for video ingests and WAVS and MP3s for audio ingests.
These are the files that DDS/DLCS should use to serve the file to the user.
File Group: Poster Image, Use: Poster
This file group will contain JPG poster images (for now it will be JPG) for audio or video ingests. DDS should apply this JPG to the audio or video file as a place holder image before the file is played.
File Group: Transcript, Use: Transcript
This file group will contain the PDF transcript (for now it will be PDF) for audio or video ingests. DDS should display the PDF transcript alongside the audio or video file for the user.
File Ingest Combinations
Ingests will vary depending on what is available for the audio or video file at the time. While all ingests will have the Object File Group, some may not have the Transcript File Group and/or the Poster Image File Group. Only MXF ingests will have the Masters File Group.
XML Samples
I have attached samples of different METS File Group combinations below:
Film
b30496160.xml = MXF, MP4, JPG, PDF (Filegroups: Master, Objects, Poster, Transcript)
b30496160.txt
b30496020.xml = MPG, JPG, PDF (Filegroups: Objects, Poster, Transcript)
b30496020.txt
Audio
b30655729.xml= WAV, PDF (Filegroups: Objects, Transcript)
b30655729.txt
b31630327.xml = 2 WAV, PDF, docstruct labels in the Logical metadata (Filegroups: Objects, Transcript)
b31630327.txt
b22488522.xml = 7 WAV, PDF (Filegroups: Objects, Transcript)
b22488522.txt
b30655730.xml = WAV, PDF =(Filegroups: Objects, Transcript)
b30655730.txt
b32494361.xml = WAV, JPG (Filegroups: Objects, Poster)
b32494361.txt
b2914615x.xml = 2 MP3, docstruct labels in the Logical metadata (Filegroups: Objects)
b2914615x.txt
Notes
We are testing some structural metadata labels for the audio files in the Logical section of the METS. We are waiting to see what the audio looks like on DDS before deciding if a change is needed for those.
And these METS do not have the width, height, nor parsed duration times in them yet as being discussed in #4777

@aray-wellcome do you plan to retrospectively apply this to existing AV, replacing the old METS with things that look like this?
I want to get the existing AV working in new IIIF Builder as a baseline, to verify we've got the logic we need out of old DDS, before handling the new model. But it would be nice if everything used the new model.
Would any AV still be a Multiple Manifestation in the new model? I know most things wouldn't be, but would there ever be a complex film or set of films that have one b number but would still make sense as a IIIF Collection? (I suspect not).
At the moment, the naive METS to IIIF mapping has to be stopped from building a IIIF Collection for Video+Transcript MMs; we go back and gather up the outputs and build a single IIIF Manifest with a single Canvas.

We have no plans at this moment to retrospectively apply this to the ~1000 AV items we already have in there. This would be for moving forward (though, if we ever had to re-ingest an old item, we'd re-ingest it via the new METS). As such, we'd need support for the old AV METS and the new AV METS, which is almost definitely not what you didn't want to hear!
But we don't foresee any reason in the future with the new A/V workflow where we'd have a MM. Everything that should be together should be together in the bag.

For MMs, they'd still be together in the bag but described in more than one METS/Anchor file.
So we do need to support old and new.
Now that we have examples available in staging, I think we do want to build in support for this before we finish the DDS migration project, so that in a big initial population, this model is supported.
In the current chunk of work, we should get existing AV working (as in the correct IIIF built).
I think we should get the new flow working as the first task in the next chunk.

Update: Goobi now uses MediaInfo to analyze the a/v files and write the duration, width, and height in a consistent way. The duration is in the format seconds.milliseconds and height and width just gives the number of pixels, no suffix. These can be adjusted if necessary.
Example:
b2923721x (wav files)
b2923721x.txt
b3216273x (mxf and mp4)
b3216273x.txt

Morning @aray-wellcome
Some questions about the new workflow and its DDS/IIIF-Builder implementation

Will the previous test approach to MXF files, from back in April, be used at all? This is where the MXF file, the MPEG and the poster image are all separate entries in the METS physical files section, rather than the new approach where there is a single entry in physical files, which points to more than one mets:File, differentiated by USE="xxx" attributes. There is a fair amount of complexity that could be eliminated if that previous additional model was not supported - just the new model and the original Multiple Manifestation approach.
Are any of these in production storage? Can they be? Not essential but handy to test.
The ones in staging storage don't quite match the examples given as text attachments above. They are all there (same b numbers) but they don't show the same arrangement of files. E.g., b30496160 in the test one above has a full house of Master, Access, Poster and Transcript but the METS file in storage for b30496160 only has Access and Transcript. I can test many aspects of this using the the above test fixtures in isolation but some tests need to pull from storage; it would be good to have at least one in staging or production storage with the full house of files.
It would be handy to have a safe way of quickly identifying a METS file as one that uses the new workflow. I think the presence of USE="ACCESS" on the filegroup that contains the access copy is a way of doing this (old workflows have USE="OBJECTS"). Does this sound right?

Morning @aray-wellcome
Some questions about the new workflow and its DDS/IIIF-Builder implementation

Will the previous test approach to MXF files, from back in April, be used at all? This is where the MXF file, the MPEG and the poster image are all separate entries in the METS physical files section, rather than the new approach where there is a single entry in physical files, which points to more than one mets:File, differentiated by USE="xxx" attributes. There is a fair amount of complexity that could be eliminated if that previous additional model was not supported - just the new model and the original Multiple Manifestation approach.
Are any of these in production storage? Can they be? Not essential but handy to test.
The ones in staging storage don't quite match the examples given as text attachments above. They are all there (same b numbers) but they don't show the same arrangement of files. E.g., b30496160 in the test one above has a full house of Master, Access, Poster and Transcript but the METS file in storage for b30496160 only has Access and Transcript. I can test many aspects of this using the the above test fixtures in isolation but some tests need to pull from storage; it would be good to have at least one in staging or production storage with the full house of files.
It would be handy to have a safe way of quickly identifying a METS file as one that uses the new workflow. I think the presence of USE="ACCESS" on the filegroup that contains the access copy is a way of doing this (old workflows have USE="OBJECTS"). Does this sound right?

Morning, @tomcrane

The test approach with all the items as separate entities in the METS physical files section will not be used. Moving forward will will only use the METS with the usage attributes USE="xxx" for ingests. The MM approach needs to be retained as we've used it to ingest 1200 items previously and it will allow us to update these as necessary.
We don't have any of the new a/v ingests in production, no. I can get Intranda to install the new film workflow on production if you need this, though.
We tested these items over and over so I think they've gotten a little out of sync of what we wanted to show you. That said, I can ingest an MXF ingest and and MP2 ingest with all of the files present for you. As far as I'm aware we're only moving forward with the films to be put on old DDS as the audio is too complicated to deal with right now. If you need audio now though, please let me know. I'll let you know which bnumbers I've ingested with all the files ASAP as I need to get the info from Harkiran.
Yes, that sounds right to me. The usage attribute on the new METS for a/vfileswill not have use=objects but use=access and in this way we'll know it's the new METS.

Morning, @tomcrane

The test approach with all the items as separate entities in the METS physical files section will not be used. Moving forward will will only use the METS with the usage attributes USE="xxx" for ingests. The MM approach needs to be retained as we've used it to ingest 1200 items previously and it will allow us to update these as necessary.
We don't have any of the new a/v ingests in production, no. I can get Intranda to install the new film workflow on production if you need this, though.
We tested these items over and over so I think they've gotten a little out of sync of what we wanted to show you. That said, I can ingest an MXF ingest and and MP2 ingest with all of the files present for you. As far as I'm aware we're only moving forward with the films to be put on old DDS as the audio is too complicated to deal with right now. If you need audio now though, please let me know. I'll let you know which bnumbers I've ingested with all the files ASAP as I need to get the info from Harkiran.
Yes, that sounds right to me. The usage attribute on the new METS for a/vfileswill not have use=objects but use=access and in this way we'll know it's the new METS.

Thanks @aray-wellcome !
That's good to know. This allows us to remove some over-complex code, as there are only 2 patterns to support, not 3  - and the new pattern is an extension of the original one (ALTOs are referenced in a similar way) rather than an alternative approach with some Physical files that need to be ignored. It feels nicer for sure, the model for ALTO just clicks into place with the MXF/Poster/Transcript use.
I need a word to describe these variants. The one we are interested in in the DDS is the access copy, which for old workflow is the only one present. What do we call the files that sit alongside? Derivative is the wrong word - the MXF is not a derivative of the MPEG. Variant isn't right either. We need a term that will make sense in the code, and I've picked adjunct - but if there is a better term that you might use in a preservation context I'll use that.

Thanks @aray-wellcome !
That's good to know. This allows us to remove some over-complex code, as there are only 2 patterns to support, not 3  - and the new pattern is an extension of the original one (ALTOs are referenced in a similar way) rather than an alternative approach with some Physical files that need to be ignored. It feels nicer for sure, the model for ALTO just clicks into place with the MXF/Poster/Transcript use.
I need a word to describe these variants. The one we are interested in in the DDS is the access copy, which for old workflow is the only one present. What do we call the files that sit alongside? Derivative is the wrong word - the MXF is not a derivative of the MPEG. Variant isn't right either. We need a term that will make sense in the code, and I've picked adjunct - but if there is a better term that you might use in a preservation context I'll use that.

@tomcrane I have got an MXF ingest and an MPG ingest with full file loads making their way into the storage staging system. I'll let you know when they are available.
I'm glad the method we fixed clicks in well!
As for the the variants, do you mean you need a word for, say, what the MXF, poster image, and transcript are collectively compared to the MP4 for access? These would collectively be called adjuncts?
We have just been calling the MXF a master file and then hand waving at the poster image and transcript to include them in a conversation, no real terms yet haha.

@tomcrane I have got an MXF ingest and an MPG ingest with full file loads making their way into the storage staging system. I'll let you know when they are available.
I'm glad the method we fixed clicks in well!
As for the the variants, do you mean you need a word for, say, what the MXF, poster image, and transcript are collectively compared to the MP4 for access? These would collectively be called adjuncts?
We have just been calling the MXF a master file and then hand waving at the poster image and transcript to include them in a conversation, no real terms yet haha.

I'll stick with adjunct. It's so that code makes sense...
foreach (var adjunct in physicalFile.GetAdjuncts())...

I'll stick with adjunct. It's so that code makes sense...
foreach (var adjunct in physicalFile.GetAdjuncts())...

@tomcrane Sorry for the delay but we got two clean ingests through overnight.
b32248398 has the mxf, mp4, pdf, and jpg
b32248398.txt
b30496111 has the mpg, pdf, and jpg
b30496111.txt
Both are now in the wellcomecollection-storage-staging bucket
Would you like me to kick off more ingests with the complete file sets to use? When did you need an example on prod? Intranda says it'll take a day or two to get the new a/v workflows on prod so just trying to figure out timing among our other work

@tomcrane Sorry for the delay but we got two clean ingests through overnight.
b32248398 has the mxf, mp4, pdf, and jpg
b32248398.txt
b30496111 has the mpg, pdf, and jpg
b30496111.txt
Both are now in the wellcomecollection-storage-staging bucket
Would you like me to kick off more ingests with the complete file sets to use? When did you need an example on prod? Intranda says it'll take a day or two to get the new a/v workflows on prod so just trying to figure out timing among our other work

Don't worry about getting it on prod yet, I'll develop and test against these ones (and the existing ones) in the staging environment. The only reason to have some on prod too was to be able to test old and new things side by side - regression testing of the new sync/dashboard/iiif-generation code - and I think stage storage was cleared of old stuff.
An alternative would be to replicate a few example audio, video, book and archive items on stage-storage alongside these new workflow examples.

Don't worry about getting it on prod yet, I'll develop and test against these ones (and the existing ones) in the staging environment. The only reason to have some on prod too was to be able to test old and new things side by side - regression testing of the new sync/dashboard/iiif-generation code - and I think stage storage was cleared of old stuff.
An alternative would be to replicate a few example audio, video, book and archive items on stage-storage alongside these new workflow examples.

We do have a few things in staging-storage for you:
Book from Internet Archive: b19677911
Archive item: sa_eug_c_172_box_17_b16232665 (on its way to the storage service, at least, currently)
Manuscript: ms_4263_b19367454
We don't have any audio or video that's from the old workflow, though.

We do have a few things in staging-storage for you:
Book from Internet Archive: b19677911
Archive item: sa_eug_c_172_box_17_b16232665 (on its way to the storage service, at least, currently)
Manuscript: ms_4263_b19367454
We don't have any audio or video that's from the old workflow, though.

Morning @aray-wellcome and sorry for labouring this point, just want to be 100% sure before I start merrily ripping out code on Monday.
Is it true to say that there are NEVER entries in the METS physical files list that should be ignored by the DDS?
In the older first-attempt MXF workflow, MXF files had their own entries in the physical files list. The DDS ignored these physical file entries.
Now, in the new version, MXF files are one of the set of file pointers for a physical file entry. The DDS ignores that particular pointer, but doesn't ignore the physical file element itself because one of the other pointers is the mpeg, and (sometimes) one is the transcript.
So now, some of the actual files pointed at from a physical file element can be ignored by the DDS (like MXF), and/or not sent to DLCS (like ALTO), but there will always be at least one mets:filePtr that needs to be sent to the DLCS, in the 1,2,3 or 4 file pointers in any give physical file element - either a JP2, or an mpeg|wav|etc, or a transcript.
I'm 99.9% sure this is true, just quadruple-checking.
Why this is a nice simplification will become more apparent when you see the dashboard UI.

Morning @aray-wellcome and sorry for labouring this point, just want to be 100% sure before I start merrily ripping out code on Monday.
Is it true to say that there are NEVER entries in the METS physical files list that should be ignored by the DDS?
In the older first-attempt MXF workflow, MXF files had their own entries in the physical files list. The DDS ignored these physical file entries.
Now, in the new version, MXF files are one of the set of file pointers for a physical file entry. The DDS ignores that particular pointer, but doesn't ignore the physical file element itself because one of the other pointers is the mpeg, and (sometimes) one is the transcript.
So now, some of the actual files pointed at from a physical file element can be ignored by the DDS (like MXF), and/or not sent to DLCS (like ALTO), but there will always be at least one mets:filePtr that needs to be sent to the DLCS, in the 1,2,3 or 4 file pointers in any give physical file element - either a JP2, or an mpeg|wav|etc, or a transcript.
I'm 99.9% sure this is true, just quadruple-checking.
Why this is a nice simplification will become more apparent when you see the dashboard UI.

Hi @tomcrane Had to read this a few times but what you're saying is correct here and will be the only way we're moving forward on this:

Now, in the new version, MXF files are one of the set of file pointers for a physical file entry. The DDS ignores that particular pointer, but doesn't ignore the physical file element itself because one of the other pointers is the mpeg, and (sometimes) one is the transcript.

So now, some of the actual files pointed at from a physical file element can be ignored by the DDS (like MXF), and/or not sent to DLCS (like ALTO), but there will always be at least one mets:filePtr that needs to be sent to the DLCS, in the 1,2,3 or 4 file pointers in any give physical file element - either a JP2, or an mpeg|wav|etc, or a transcript.

The DDS should ignore any file under the Masters pointer in the Physical file element. In this case, the masters pointer points to the MXF file but in the distant future or in a different workflow could be another type of file.
I hope that helped confirm and didn't confuse you more...!

Hi @tomcrane Had to read this a few times but what you're saying is correct here and will be the only way we're moving forward on this:

Now, in the new version, MXF files are one of the set of file pointers for a physical file entry. The DDS ignores that particular pointer, but doesn't ignore the physical file element itself because one of the other pointers is the mpeg, and (sometimes) one is the transcript.

So now, some of the actual files pointed at from a physical file element can be ignored by the DDS (like MXF), and/or not sent to DLCS (like ALTO), but there will always be at least one mets:filePtr that needs to be sent to the DLCS, in the 1,2,3 or 4 file pointers in any give physical file element - either a JP2, or an mpeg|wav|etc, or a transcript.

The DDS should ignore any file under the Masters pointer in the Physical file element. In this case, the masters pointer points to the MXF file but in the distant future or in a different workflow could be another type of file.
I hope that helped confirm and didn't confuse you more...!


Allow a custom binary name instead of "rkd" - step one

The proposal:

Make possible to distribute rkd as part of other project eg. "harbor" with predefined tasks, predefined makefile and different binary name

Why?
For simplicity, the user could be less confused if a custom binary could be installed via pip and used without need to create a makefile

Added and documented.


Check README attributions

Module version(s) affected
4.x, 5.x, 6.x
Description
The README has an Attributions section in it, which hasn't been updated for quite some time. Either we should remove this, or update it to reference what we actually use. I don't think we use the icon set anymore, perhaps since v2 days, though I could be wrong?
How to reproduce
Just view the README file 😉
Possible Solution
No response
Additional Context
Closest other issue is a comment from Dan on https://github.com/silverstripe/silverstripe-framework/pull/6756 back in 2017 but this was missed as the PR was already merged and closed.
Validations

[X] Check that there isn't already an issue that reports the same bug
[X] Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

Just view the README file

But I don't know which icons it's referring to. :p

I mean it links here - not sure we've used any of these icons in the past decade? :p
https://p.yusukekamiyamane.com/

Looks like blue-folder-horizontal in silverstripe/cms (yes I know, that's not this repo) is used from that website.
I'm not sure where the images in silverstripe/admin (again not this repo) came from, but some of them share a similar style to that website so may have originated from there. Many of them are bundled in spritesheets so I can't search for them by name like I could the folder.
So - yes, probably remove from this repo's readme, but looks like we need to add it to at least the cms readme and maybe the admin readme.

Huh - okay well if it's still relevant then we should keep it. I can't say I've seen any of those icons in a long time heh. The curse of long-term support strikes again ;)


Make the find method private

Let it live in the closure.

Hahahaha nope. I need it sometimes outside: will be a static method instead =)

So I will have to:

[ ] Add tests


Scrutinizer Auto-Fixes

@alphadevx requested this pull request.
It consists of patches automatically generated for this project on Scrutinizer:
https://scrutinizer-ci.com/g/alphadevx/alpha/

Coverage decreased (-5.6%) to 65.477% when pulling fe499432f57fa0db159ad846903354d7193b8594 on scrutinizer-patch-1 into 18786c5bb3f660deb351b8b228148449b3534df1 on develop.


GitHub Billing for enterprises

I just discovered that GitHub has given their billing and cost management platform an upgrade.
It looks like a very suitable platform to be added to this plugin.

API Documentation

GitHub Announcement

Hi @O5ten, that's great to hear. Thanks for the pointers! We will check it out :)


[BUG] Get-PnPSiteTemplate: -Configuration option is ignored

Not sure if this is belongs here or to Provisioning Engine, but I try here first.
Reporting an Issue or Missing Feature
When using Get-PnPSiteTemplate with -Configuration option, the configuration is ignored
Expected behavior
config.json:
{
    "$schema":"https://aka.ms/sppnp-extract-configuration-schema",
    "handlers": [
        "Lists"
    ]
}

Get-PnPSiteTemplate -Configuration .\config.json -Out .\template.xml

Result:
A xml document containing lists only will be exported.
Actual behavior
Same exact behavior as:
Get-PnPSiteTemplate -Out .\template.xml

Steps to reproduce behavior
Connect-PnPOnline <site>
Get-PnPSiteTemplate -Configuration .\config.json -Out .\template.xml

What is the version of the Cmdlet module you are running?
1.2.4-nightly
Which operating system/environment are you running PnP PowerShell on?

[x] Windows
[ ] Linux
[ ] MacOS
[ ] Azure Cloud Shell
[ ] Azure Functions
[ ] Other : please specify

Hi! This was actually an issue in the underlying PnP Framework. We fixed it and the fix will be available in the upcoming nightly build of PnP PowerShell : 1.2.6-nightly.

Hi! This was actually an issue in the underlying PnP Framework. We fixed it and the fix will be available in the upcoming nightly build of PnP PowerShell : 1.2.6-nightly.


UnderKeyboardLayoutConstraint memory leak

Hello,
There is a memory leak in UnderKeyboardLayoutConstraint.swift, due to a circular reference to self, found here: https://github.com/evgenyneu/UnderKeyboard/blob/master/UnderKeyboard/UnderKeyboardLayoutConstraint.swift#L22-L23 . This leak also causes the viewToAnimate to leak.
It can easily be fixed by replacing the above two lines with
    keyboardObserver.willAnimateKeyboard = { [weak self] height in
        self?.keyboardWillAnimate(height)
    }
    keyboardObserver.animateKeyboard = { [weak self] height in
        self?.animateKeyboard(height)
    }

I am happy to submit a pull request, if needed.
Thank you,
Dan

Thanks for finding this, you are right. A pull request is welcome. 👍

Done, thank you!

Thank you, I've released your changes in version 10.0.0.


[terra-clinical-header] Accessibility Updates

Feature Request
Description
As a consumer of Terra-Clinical-Header, I would like to the user to be able to select a heading level, so that it does not have accessibility assumptions or defaults that create incorrect context for users and my application meets WCAG Success Criterion 1.3.1 (Info and Relationships) plus Success Criterion 1.3.2 (Meaningful Sequence).
When headings reflect page organization, they should be given ‘id’s and used with ‘aria-labelledby’ to associate headings with the corresponding page region
example: https://www.w3.org/WAI/tutorials/page-structure/example/
Additional Context / Screenshots

@ Mentions

Tech Design
Summary:
Add level, text and id props to terra-clinical-header to enhance the accessibility across ultiple browser-screenreader combos.
Requirements and Accessibility:
As a consumer of Terra-Clinical-Header, I would like to the user to be able to select a heading level, so that it does not have accessibility assumptions or defaults that create incorrect context for users and my application meets WCAG Success Criterion 1.3.1 (Info and Relationships) plus Success Criterion 1.3.2 (Meaningful Sequence).
When headings reflect page organization, they should be given ‘id’s and used with ‘aria-labelledby’ to associate headings with the corresponding page region
React Props:
Terra-clinical-header

Prop
Type
isRequired
Default
Description

text
string
required
N/A
Text to be displayed as the title in the header bar

level
enum:[1, 2, 3, 4, 5, 6]
optional
undefined
Sets the heading level. One of 1, 2, 3, 4, 5, 6. This helps screen readers to announce appropriate heading levels. Changing 'level' will not visually change the style of the content.

id
String
optional
undefined
IDs should be used with ‘aria-labelledby’ to associate headings with the corresponding page region.

Usage Example
    const header= ;
    <ContentContainer aria-labelledby="Header" id="content-container" header={header}>

content
;
    </ContentContainer>

Fixed by #792