VM stuck on Pending

This a BUG REPORT:
/kind bug
What happened:
Similar to #4748
NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
default       virt-launcher-testvm-dr6gs         0/2     Pending   0          9m17s

38s         Warning   FailedScheduling          pod/virt-launcher-testvm-dr6gs   0/1 nodes are available: 1 Insufficient devices.kubevirt.io/kvm.

What you expected to happen:
VM should start
How to reproduce it (as minimally and precisely as possible):
Fresh minikube install (script in install tools)
Anything else we need to know?:
Capacity:
  cpu:                            2
  devices.kubevirt.io/kvm:        1k
  devices.kubevirt.io/tun:        1k
  devices.kubevirt.io/vhost-net:  1k
  ephemeral-storage:              17784752Ki
  hugepages-2Mi:                  0
  memory:                         4029232Ki
  pods:                           110
Allocatable:
  cpu:                            2
  devices.kubevirt.io/kvm:        0
  devices.kubevirt.io/tun:        1k
  devices.kubevirt.io/vhost-net:  1k
  ephemeral-storage:              17784752Ki
  hugepages-2Mi:                  0
  memory:                         4029232Ki
  pods:                           110

ls -l
crw-rw----+ 1 root kvm 10, 232 Sep 13 17:39 /dev/kvm
lsmod | grep kvm
kvm_intel             233472  4
kvm                   757760  1 kvm_intel
irqbypass              16384  6 kvm

I have (offline) existing libvirt VM's
Environment:

KubeVirt version (use virtctl version):

Client Version: version.Info{GitVersion:"v0.45.0", GitCommit:"c9e87c4cb6292af33ccad8faa5fb9bf269c0fbf4", GitTreeState:"clean", BuildDate:"2021-09-08T14:05:28Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{GitVersion:"v0.45.0-dirty", GitCommit:"c9e87c4cb6292af33ccad8faa5fb9bf269c0fbf4", GitTreeState:"dirty", BuildDate:"2021-09-08T14:30:14Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.1", GitCommit:"632ed300f2c34f6d6d15ca4cef3d3c7073412212", GitTreeState:"clean", BuildDate:"2021-08-19T15:45:37Z", GoVersion:"go1.16.7", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.1", GitCommit:"632ed300f2c34f6d6d15ca4cef3d3c7073412212", GitTreeState:"clean", BuildDate:"2021-08-19T15:39:34Z", GoVersion:"go1.16.7", Compiler:"gc", Platform:"linux/amd64"}

VM or VMI specifications:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        resources:
          requests:
            memory: 512M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGkuXG4=

Cloud provider or hardware configuration:
Intel i5-10600KF
16GB RAM

OS (e.g. from /etc/os-release):
Debian GNU/Linux 10 (buster)

Kernel (e.g. uname -a):
Linux intel-deb 4.19.0-17-amd64 # 1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux

Install tools:
script
Minikube; Kubectl; Krew; Virtcl

Could you please provide logs of your virt-handler pods.

virt handler pod
{"component":"virt-handler","hostname":"minikube","level":"info","pos":"virt-handler.go:194","timestamp":"2021-09-17T13:22:25.252189Z"}
W0917 13:22:25.253042    6940 client_config.go:614] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
{"component":"virt-handler","level":"info","node-labeller is disabled, cannot work without KVM device.":"(MISSING)","pos":"virt-handler.go:322","timestamp":"2021-09-17T13:22:26.852494Z"}
{"component":"virt-handler","level":"info","msg":"Starting domain stats collector: node name=minikube","pos":"prometheus.go:446","timestamp":"2021-09-17T13:22:26.853048Z"}
{"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:450","timestamp":"2021-09-17T13:22:26.853205Z"}
{"component":"virt-handler","level":"info","msg":"setting rate limiter to 5 QPS and 10 Burst","pos":"virt-handler.go:459","timestamp":"2021-09-17T13:22:26.853229Z"}
{"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:450","timestamp":"2021-09-17T13:22:26.853057Z"}
{"component":"virt-handler","level":"info","msg":"STARTING informer vmiInformer-targets","pos":"virtinformers.go:264","timestamp":"2021-09-17T13:22:26.853200Z"}
{"component":"virt-handler","level":"info","msg":"STARTING informer extensionsKubeVirtCAConfigMapInformer","pos":"virtinformers.go:264","timestamp":"2021-09-17T13:22:26.853343Z"}
{"component":"virt-handler","level":"info","msg":"STARTING informer configMapInformer","pos":"virtinformers.go:264","timestamp":"2021-09-17T13:22:26.853403Z"}
{"component":"virt-handler","level":"info","msg":"STARTING informer CRDInformer","pos":"virtinformers.go:264","timestamp":"2021-09-17T13:22:26.853509Z"}
{"component":"virt-handler","level":"info","msg":"STARTING informer kubeVirtInformer","pos":"virtinformers.go:264","timestamp":"2021-09-17T13:22:26.853563Z"}
{"component":"virt-handler","level":"info","msg":"STARTING informer vmiInformer-sources","pos":"virtinformers.go:264","timestamp":"2021-09-17T13:22:26.853633Z"}
{"component":"virt-handler","level":"info","msg":"certificate with common name 'kubevirt.io:system:node:virt-handler' retrieved.","pos":"cert-manager.go:198","timestamp":"2021-09-17T13:22:26.854130Z"}
{"component":"virt-handler","level":"info","msg":"metrics: max concurrent requests=3","pos":"virt-handler.go:468","timestamp":"2021-09-17T13:22:26.853294Z"}
{"component":"virt-handler","level":"info","msg":"certificate with common name 'kubevirt.io:system:client:virt-handler' retrieved.","pos":"cert-manager.go:198","timestamp":"2021-09-17T13:22:26.853527Z"}
{"component":"virt-handler","level":"info","msg":"Updating cluster config from KubeVirt to resource version '819'","pos":"config-map.go:580","timestamp":"2021-09-17T13:22:26.872138Z"}
{"component":"virt-handler","level":"info","msg":"setting rate limiter to 5 QPS and 10 Burst","pos":"virt-handler.go:459","timestamp":"2021-09-17T13:22:26.872166Z"}
{"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:450","timestamp":"2021-09-17T13:22:26.872184Z"}
{"component":"virt-handler","level":"info","msg":"Starting virt-handler controller.","pos":"vm.go:1358","timestamp":"2021-09-17T13:22:26.988615Z"}
{"component":"virt-handler","level":"info","msg":"refreshed device plugins for permitted/forbidden host devices","pos":"device_controller.go:235","timestamp":"2021-09-17T13:22:26.988783Z"}
{"component":"virt-handler","level":"info","msg":"enabled device-plugins for: []","pos":"device_controller.go:236","timestamp":"2021-09-17T13:22:26.988871Z"}
{"component":"virt-handler","level":"info","msg":"disabled device-plugins for: []","pos":"device_controller.go:237","timestamp":"2021-09-17T13:22:26.988930Z"}
{"component":"virt-handler","level":"info","msg":"refreshed device plugins for permitted/forbidden host devices","pos":"device_controller.go:235","timestamp":"2021-09-17T13:22:26.988994Z"}
{"component":"virt-handler","level":"info","msg":"enabled device-plugins for: []","pos":"device_controller.go:236","timestamp":"2021-09-17T13:22:26.989054Z"}
{"component":"virt-handler","level":"info","msg":"disabled device-plugins for: []","pos":"device_controller.go:237","timestamp":"2021-09-17T13:22:26.989117Z"}
{"component":"virt-handler","level":"info","msg":"Starting a device plugin for device: tun","pos":"device_controller.go:94","timestamp":"2021-09-17T13:22:26.989125Z"}
{"component":"virt-handler","level":"info","msg":"Starting a device plugin for device: vhost-net","pos":"device_controller.go:94","timestamp":"2021-09-17T13:22:26.989363Z"}
{"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:450","timestamp":"2021-09-17T13:22:27.005218Z"}
{"component":"virt-handler","level":"info","msg":"setting rate limiter to 5 QPS and 10 Burst","pos":"virt-handler.go:459","timestamp":"2021-09-17T13:22:27.005345Z"}
{"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:450","timestamp":"2021-09-17T13:22:27.005417Z"}
{"component":"virt-handler","level":"info","msg":"setting rate limiter to 5 QPS and 10 Burst","pos":"virt-handler.go:459","timestamp":"2021-09-17T13:22:27.005484Z"}
{"component":"virt-handler","level":"info","msg":"Starting a device plugin for device: kvm","pos":"device_controller.go:94","timestamp":"2021-09-17T13:22:27.005715Z"}
{"component":"virt-handler","level":"info","msg":"tun device plugin started","pos":"generic_device.go:180","timestamp":"2021-09-17T13:22:27.007075Z"}
{"component":"virt-handler","level":"info","msg":"device '/dev/net/tun' is present.","pos":"generic_device.go:320","timestamp":"2021-09-17T13:22:27.007175Z"}
{"component":"virt-handler","level":"info","msg":"kvm device plugin started","pos":"generic_device.go:180","timestamp":"2021-09-17T13:22:27.008702Z"}
{"component":"virt-handler","level":"warning","msg":"device '/dev/kvm' is not present, the device plugin can't expose it.","pos":"generic_device.go:317","timestamp":"2021-09-17T13:22:27.008760Z"}
{"component":"virt-handler","level":"info","msg":"device '/dev/kvm' is present.","pos":"generic_device.go:320","timestamp":"2021-09-17T13:22:27.009575Z"}
{"component":"virt-handler","level":"info","msg":"vhost-net device plugin started","pos":"generic_device.go:180","timestamp":"2021-09-17T13:22:27.012799Z"}
{"component":"virt-handler","level":"info","msg":"device '/dev/vhost-net' is present.","pos":"generic_device.go:320","timestamp":"2021-09-17T13:22:27.012865Z"}
W0917 13:22:40.176866    6940 client_config.go:614] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
{"component":"virt-handler","level":"info","msg":"Updating cluster config from KubeVirt to resource version '1006'","pos":"config-map.go:580","timestamp":"2021-09-17T13:22:56.816036Z"}
{"component":"virt-handler","level":"info","msg":"refreshed device plugins for permitted/forbidden host devices","pos":"device_controller.go:235","timestamp":"2021-09-17T13:22:56.816567Z"}
{"component":"virt-handler","level":"info","msg":"enabled device-plugins for: []","pos":"device_controller.go:236","timestamp":"2021-09-17T13:22:56.816581Z"}
{"component":"virt-handler","level":"info","msg":"disabled device-plugins for: []","pos":"device_controller.go:237","timestamp":"2021-09-17T13:22:56.816746Z"}
{"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:450","timestamp":"2021-09-17T13:22:56.816917Z"}
{"component":"virt-handler","level":"info","msg":"setting rate limiter to 5 QPS and 10 Burst","pos":"virt-handler.go:459","timestamp":"2021-09-17T13:22:56.816938Z"}
{"component":"virt-handler","level":"info","msg":"Updating cluster config from KubeVirt to resource version '1015'","pos":"config-map.go:580","timestamp":"2021-09-17T13:23:01.829277Z"}
{"component":"virt-handler","level":"info","msg":"refreshed device plugins for permitted/forbidden host devices","pos":"device_controller.go:235","timestamp":"2021-09-17T13:23:01.829322Z"}
{"component":"virt-handler","level":"info","msg":"enabled device-plugins for: []","pos":"device_controller.go:236","timestamp":"2021-09-17T13:23:01.829387Z"}
{"component":"virt-handler","level":"info","msg":"disabled device-plugins for: []","pos":"device_controller.go:237","timestamp":"2021-09-17T13:23:01.829416Z"}
{"component":"virt-handler","level":"info","msg":"set verbosity to 2","pos":"virt-handler.go:450","timestamp":"2021-09-17T13:23:01.829472Z"}
{"component":"virt-handler","level":"info","msg":"setting rate limiter to 5 QPS and 10 Burst","pos":"virt-handler.go:459","timestamp":"2021-09-17T13:23:01.829518Z"}
{"component":"virt-handler","level":"info","msg":"resyncing virt-launcher domains","pos":"cache.go:384","timestamp":"2021-09-17T13:27:26.872455Z"}

$ kubectl describe nodes

Name:               minikube
Roles:              control-plane,master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    cpumanager=false
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=minikube
                    kubernetes.io/os=linux
                    kubevirt.io/schedulable=true
                    minikube.k8s.io/commit=5931455374810b1bbeb222a9713ae2c756daee10
                    minikube.k8s.io/name=minikube
                    minikube.k8s.io/updated_at=2021_09_17T10_18_56_0700
                    minikube.k8s.io/version=v1.23.0
                    node-role.kubernetes.io/control-plane=
                    node-role.kubernetes.io/master=
                    node.kubernetes.io/exclude-from-external-load-balancers=
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    kubevirt.io/heartbeat: 2021-09-17T13:23:48Z
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Fri, 17 Sep 2021 10:18:44 -0300
Taints:             <none>
Unschedulable:      false
Lease:
  HolderIdentity:  minikube
  AcquireTime:     <unset>
  RenewTime:       Fri, 17 Sep 2021 10:24:52 -0300
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Fri, 17 Sep 2021 10:22:37 -0300   Fri, 17 Sep 2021 10:18:44 -0300   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Fri, 17 Sep 2021 10:22:37 -0300   Fri, 17 Sep 2021 10:18:44 -0300   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Fri, 17 Sep 2021 10:22:37 -0300   Fri, 17 Sep 2021 10:18:44 -0300   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Fri, 17 Sep 2021 10:22:37 -0300   Fri, 17 Sep 2021 10:18:55 -0300   KubeletReady                 kubelet is posting ready status
Addresses:
  InternalIP:  <IP_ADDRESS>
  Hostname:    minikube
Capacity:
  cpu:                            2
  devices.kubevirt.io/kvm:        1k
  devices.kubevirt.io/tun:        1k
  devices.kubevirt.io/vhost-net:  1k
  ephemeral-storage:              17784752Ki
  hugepages-2Mi:                  0
  memory:                         4029248Ki
  pods:                           110
Allocatable:
  cpu:                            2
  devices.kubevirt.io/kvm:        0
  devices.kubevirt.io/tun:        1k
  devices.kubevirt.io/vhost-net:  1k
  ephemeral-storage:              17784752Ki
  hugepages-2Mi:                  0
  memory:                         4029248Ki
  pods:                           110
System Info:
  Machine ID:                 6454a021733a4f64875cdf575b000658
  System UUID:                6454a021-733a-4f64-875c-df575b000658
  Boot ID:                    9e9fff16-ac7d-4344-9e05-baee9bb2367a
  Kernel Version:             4.19.202
  OS Image:                   Buildroot 2021.02.4
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  docker://20.10.8
  Kubelet Version:            v1.22.1
  Kube-Proxy Version:         v1.22.1
PodCIDR:                      <IP_ADDRESS>/24
PodCIDRs:                     <IP_ADDRESS>/24
Non-terminated Pods:          (14 in total)
  Namespace                   Name                                CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------                   ----                                ------------  ----------  ---------------  -------------  ---
  kube-system                 coredns-78fcd69978-2wn56            100m (5%)     0 (0%)      70Mi (1%)        170Mi (4%)     5m49s
  kube-system                 etcd-minikube                       100m (5%)     0 (0%)      100Mi (2%)       0 (0%)         6m14s
  kube-system                 kube-apiserver-minikube             250m (12%)    0 (0%)      0 (0%)           0 (0%)         6m15s
  kube-system                 kube-controller-manager-minikube    200m (10%)    0 (0%)      0 (0%)           0 (0%)         6m12s
  kube-system                 kube-proxy-mswhw                    0 (0%)        0 (0%)      0 (0%)           0 (0%)         5m50s
  kube-system                 kube-scheduler-minikube             100m (5%)     0 (0%)      0 (0%)           0 (0%)         6m8s
  kube-system                 storage-provisioner                 0 (0%)        0 (0%)      0 (0%)           0 (0%)         6m2s
  kubevirt                    virt-api-5477b6554f-6qw8x           5m (0%)       0 (0%)      150Mi (3%)       0 (0%)         4m39s
  kubevirt                    virt-api-5477b6554f-d928n           5m (0%)       0 (0%)      150Mi (3%)       0 (0%)         4m39s
  kubevirt                    virt-controller-6c96dc799c-9bdmf    10m (0%)      0 (0%)      150Mi (3%)       0 (0%)         3m52s
  kubevirt                    virt-controller-6c96dc799c-nfh85    10m (0%)      0 (0%)      150Mi (3%)       0 (0%)         3m52s
  kubevirt                    virt-handler-7x58t                  10m (0%)      0 (0%)      230Mi (5%)       0 (0%)         3m52s
  kubevirt                    virt-operator-5fbd9484d4-7pnp7      10m (0%)      0 (0%)      150Mi (3%)       0 (0%)         5m38s
  kubevirt                    virt-operator-5fbd9484d4-t8zx5      10m (0%)      0 (0%)      150Mi (3%)       0 (0%)         5m38s
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                       Requests      Limits
  --------                       --------      ------
  cpu                            810m (40%)    0 (0%)
  memory                         1300Mi (33%)  170Mi (4%)
  ephemeral-storage              0 (0%)        0 (0%)
  hugepages-2Mi                  0 (0%)        0 (0%)
  devices.kubevirt.io/kvm        0             0
  devices.kubevirt.io/tun        0             0
  devices.kubevirt.io/vhost-net  0             0
Events:
  Type    Reason                   Age                    From     Message
  ----    ------                   ----                   ----     -------
  Normal  NodeHasSufficientMemory  6m29s (x8 over 6m30s)  kubelet  Node minikube status is now: NodeHasSufficientMemory
  Normal  NodeHasNoDiskPressure    6m29s (x8 over 6m30s)  kubelet  Node minikube status is now: NodeHasNoDiskPressure
  Normal  NodeHasSufficientPID     6m29s (x7 over 6m30s)  kubelet  Node minikube status is now: NodeHasSufficientPID
  Normal  Starting                 6m6s                   kubelet  Starting kubelet.
  Normal  NodeHasSufficientMemory  6m6s                   kubelet  Node minikube status is now: NodeHasSufficientMemory
  Normal  NodeHasNoDiskPressure    6m6s                   kubelet  Node minikube status is now: NodeHasNoDiskPressure
  Normal  NodeHasSufficientPID     6m6s                   kubelet  Node minikube status is now: NodeHasSufficientPID
  Normal  NodeAllocatableEnforced  6m6s                   kubelet  Updated Node Allocatable limit across pods
  Normal  NodeReady                6m6s                   kubelet  Node minikube status is now: NodeReady

Well from the output it seems  that there are no allocatable kvm devices available on the worker node.
Allocatable:
  cpu:                            2
  devices.kubevirt.io/kvm:        0

Please check if it is a nested virtualization issue, If your minikube cluster runs on a virtual machine consider enabling nested virtualization.
Also you can  restart the virt-handler - it should re-register the device plugins.


Add Nodepool monitoring to data dog

Currently need to know if nodepool is running or not. Nodepool provides monitoring data via statsd. We don't yet know what additional monitoring data we want.
Addtionally: are nodepool images building?

#64 covers some of the statsd part of this as it's basically the same as zuul. For additional monitoring it looks like there is a nodepool webapp status at http://locahost:8005/image-list and /dib-image-list. This port or bind ip is not configurable and we should fix that upstream. Also the response is exactly the same as the PrettyTable formatted "nodepool image-list" which is annoying to parse from a web request but would give us a request based handler like the ZuulCheck.

Working on getting a local hoist VM spun up so I can work on this

VM thing is not happening so just working on adding the role and following the pattern for the dd-zuul stuff.

I have changes for this I will push when I get a chance. I still need to test it on a working VM.

This issue was moved to BonnyCI/projman#32


Update How Build Server progress is reported.

Buildserver progress, as reported in the progress bar during a build,
used to work by having the client poll the App Inventor server, which
would in turn poll the buildserver to learn the progress of the build.
However this code would only work properly if there was only one
buildserver and only one build in progress. In reality we handle dozens
of builds simultaneously via a number of independent buildservers. So
the progress being returned to the user was the progress of some build
in the system, most likely not theirs!
The constant polling by the App Inventor server also causes problems
with the load balancer in front of the buildservers. This is because
most “jobs” are not real build jobs, but just polls for progress. This
may result in a non-optimal distribution of jobs between the various
buildservers.
This code changes things so that the buildserver does a callback to the
App Inventor server when appropriate milestones are reached in the
build job. The client still polls to App Inventor server for progress,
but the App Inventor server no longer polls the buildserver. This should
result in a better distribution of build jobs on the buildservers and
also returns to the end user the correct status of their build.
We also removed some obsolete code that attempts to generate the Yail
within the Buildserver. We always generate the yail in the client now
and it is sent to the buildserver.
Change-Id: Ibaa9a7e3ff6576335d5ab6261a4121f27a1daf1d

@halatmit @ewpatton You can test this code locally. I'm also planning on putting it up on ai2-test over the weekend.

Is there a way we can test this?
== Hal
Hal Abelson
<EMAIL_ADDRESS>Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
On Fri, May 25, 2018 at 4:38 PM Jeffrey Schiller<EMAIL_ADDRESS>wrote:

Buildserver progress, as reported in the progress bar during a build,
used to work by having the client poll the App Inventor server, which
would in turn poll the buildserver to learn the progress of the build.
However this code would only work properly if there was only one
buildserver and only one build in progress. In reality we handle dozens
of builds simultaneously via a number of independent buildservers. So
the progress being returned to the user was the progress of some build
in the system, most likely not theirs!
The constant polling by the App Inventor server also causes problems
with the load balancer in front of the buildservers. This is because
most “jobs” are not real build jobs, but just polls for progress. This
may result in a non-optimal distribution of jobs between the various
buildservers.
This code changes things so that the buildserver does a callback to the
App Inventor server when appropriate milestones are reached in the
build job. The client still polls to App Inventor server for progress,
but the App Inventor server no longer polls the buildserver. This should
result in a better distribution of build jobs on the buildservers and
also returns to the end user the correct status of their build.
We also removed some obsolete code that attempts to generate the Yail
within the Buildserver. We always generate the yail in the client now
and it is sent to the buildserver.
Change-Id: Ibaa9a7e3ff6576335d5ab6261a4121f27a1daf1d
You can view, comment on, or merge this pull request online at:
https://github.com/mit-cml/appinventor-sources/pull/1239
Commit Summary

Update How Build Server progress is reported.

File Changes

M
appinventor/appengine/src/com/google/appinventor/server/ReceiveBuildServlet.java
https://github.com/mit-cml/appinventor-sources/pull/1239/files#diff-0
(5)
M
appinventor/appengine/src/com/google/appinventor/server/project/youngandroid/YoungAndroidProjectService.java
https://github.com/mit-cml/appinventor-sources/pull/1239/files#diff-1
(37)
M
appinventor/appengine/src/com/google/appinventor/server/storage/ObjectifyStorageIo.java
https://github.com/mit-cml/appinventor-sources/pull/1239/files#diff-2
(19)
M
appinventor/appengine/src/com/google/appinventor/server/storage/StorageIo.java
https://github.com/mit-cml/appinventor-sources/pull/1239/files#diff-3
(22)
M
appinventor/buildserver/src/com/google/appinventor/buildserver/BuildServer.java
https://github.com/mit-cml/appinventor-sources/pull/1239/files#diff-4
(75)
M
appinventor/buildserver/src/com/google/appinventor/buildserver/Compiler.java
https://github.com/mit-cml/appinventor-sources/pull/1239/files#diff-5
(54)
M
appinventor/buildserver/src/com/google/appinventor/buildserver/Main.java
https://github.com/mit-cml/appinventor-sources/pull/1239/files#diff-6
(2)
M
appinventor/buildserver/src/com/google/appinventor/buildserver/ProjectBuilder.java
https://github.com/mit-cml/appinventor-sources/pull/1239/files#diff-7
(101)
M
appinventor/buildserver/tests/com/google/appinventor/buildserver/CompilerTest.java
https://github.com/mit-cml/appinventor-sources/pull/1239/files#diff-8
(14)

Patch Links:

https://github.com/mit-cml/appinventor-sources/pull/1239.patch
https://github.com/mit-cml/appinventor-sources/pull/1239.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mit-cml/appinventor-sources/pull/1239, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAwLt8PWOtb6h1-FxATI5jqstEaFpoUnks5t2GusgaJpZM4UOjAF
.

@halatmit Just build with the development server as you usually would. Then run a local buildserver in another window (ant RunLocalBuildServer). And then build a project. You can also look at the log (in the window of the dev_server) and see it reporting the progress.

Thanks.
== Hal
Hal Abelson
<EMAIL_ADDRESS>Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
On Fri, May 25, 2018 at 4:43 PM Jeffrey Schiller<EMAIL_ADDRESS>wrote:

@halatmit https://github.com/halatmit Just build with the development
server as you usually would. Then run a local buildserver in another window
(ant RunLocalBuildServer). And then build a project. You can also look at
the log (in the window of the dev_server) and see it reporting the progress.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mit-cml/appinventor-sources/pull/1239#issuecomment-392180057,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwLt0JZygVajLayiLPCZ76hzXfrMuJPks5t2G0EgaJpZM4UOjAF
.

@halatmit P.S. I have tested this code, including running it in the dev server with memcache disabled. In this case the progress bar just reports 50% until the build is finished (which interestingly enough isn't much different then when there is real progress, most stages of the build happen quickly. Now in production when things slow down, people may see more stages). I chose this fallback approach rather then storing the status in the datastore or someplace else where it will cost us $$ :-)

I tried this and it seems to work -- or at least the buildserver log
generates a lot of output, and finishes.  And the devserver log shows
doPosts from the buildserver
LGTM
== Hal
Hal Abelson
<EMAIL_ADDRESS>Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
On Fri, May 25, 2018 at 4:43 PM Jeffrey Schiller<EMAIL_ADDRESS>wrote:

@halatmit https://github.com/halatmit Just build with the development
server as you usually would. Then run a local buildserver in another window
(ant RunLocalBuildServer). And then build a project. You can also look at
the log (in the window of the dev_server) and see it reporting the progress.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mit-cml/appinventor-sources/pull/1239#issuecomment-392180057,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwLt0JZygVajLayiLPCZ76hzXfrMuJPks5t2G0EgaJpZM4UOjAF
.


Create AutoEncoder_StandardScaler.ipynb

smart changes required:
This code :
outer_units = 32
inner_units = x_train.shape[1]
better to utilize:
outer_units = x_train.shape[1]
inner_units = round(x_train.shape[1]/2)
Reason:
AutoEncoder should have a architecture like hourglass, because it try to regenerate data after understanding the pattern.
and input neuron should not be less then the number of features.
the above change makes it generic and easy neuron shitfer.

Thanks for the suggestions, I've made the appropriate changes

Thanks for the suggestions, I've made the appropriate changes

👍


[vue-tsc] Cannot find module 'typescript/lib/tsc'

I was trying reinstall typescript also all node_modules folder, but it dont help
$ vue-tsc --noEmit
internal/modules/cjs/loader.js:905
  throw err;
  ^

Error: Cannot find module 'typescript/lib/tsc'
Require stack:
- C:\Users\Александр\AppData\Roaming\npm\node_modules\vue-tsc\bin\vue-tsc.js
←[90m    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15)←[39m
←[90m    at Function.resolve (internal/modules/cjs/helpers.js:99:19)←[39m
    at Object.<anonymous> (C:\Users\Александр\AppData\Roaming\npm\node_modules\←[4mvue-tsc←[24m\bin\vue-tsc.js:5:25)
←[90m    at Module._compile (internal/modules/cjs/loader.js:1085:14)←[39m
←[90m    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)←[39m

←[90m    at Module.load (internal/modules/cjs/loader.js:950:32)←[39m
←[90m    at Function.Module._load (internal/modules/cjs/loader.js:790:12)←[39m
←[90m    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:76:12)←[39m
←[90m    at internal/main/run_main_module.js:17:47←[39m {
  code: ←[32m'MODULE_NOT_FOUND'←[39m,
  requireStack: [
    ←[32m'C:\\Users\\Александр\\AppData\\Roaming\\npm\\node_modules\\vue-tsc\\bin\\vue-tsc.js'←[39m
  ]
}

Can you provide me a reproduction repo？

Can you provide me a reproduction repo？

I'm solved problem this error, now my console see like:

@xiaoxiangmoe i send invite to repo

It would be great if you can reproduce it in https://github.com/johnsoncodehk/volar-starter

@xiaoxiangmoe do you mean i clone and run that?

Yes

Yes

It's work, but why my past don't work?

Can you try to reproduce it in new repo? Copy some code that may cause error, and run it.


Update client info

Selam,
Why is the lib folder part of your pr? It should be only includes for builds and published assets.
And... Could your shortly describe the sense of your changes in client.ts.. Why did you switched the url, version and android to ios?
Saygılar
Selcuk

Is this PR duplicating some of the changes here https://github.com/DiaKEM/libre-link-up-api-client/pull/20? It seems more useful to make the clientVersion configurable by the caller than hardcode the version updates every time they need to change?


How to use Flask-Restful with this structure

I'm using Flask-Restful for my API but how would I use api.add_resource similar to how you did route?
Also I want to add some wrappers for app and api. Where is the best place to have these wrappers?

I have the same question


Add Lighthouse tests to CI/CD after deploying to production

We'd like to be able to run Lighthouse on our production website after each deployment, so that we can test the following:

Performance / web vitals
Accessibility
Best practices
SEO

Requirements

Create a new reusable GitHub Actions workflow which runs the appropriate tests in the production environment
Publish the Lighthouse HTML report as an artifact so it can be reviewed
Publish results in other helpful locations:  on the main README as a badge?  As a comment in the PR which was merged to main (or at least a link to the artifact)?

Future
We may also want to run tests on PRs before they're merged to main, but this requires separate staging environments for each PR, which we currently don't have.

Calling bankruptcy on all discussions and issues today. Going to start revamping the direction of this project, so stay tuned 🚀


Horizontal scroll not working

... or I did something wrong:
largeElement := OBlElement new
	size: 1000 asPoint;
	background: (BlRadialGradientPaint new
		stops: { 0 -> Color green . 1 -> Color red};
		center: 500 asPoint;
		radius: 500;
		yourself);
	yourself.
scrollableElement := largeElement asScrollableElement.

hBar :=
	OBlHorizontalScrollbarElement new
		constraintsDo: [ :c |
			c ignoreByLayout.
			c ignored vertical alignBottom ];
		attachTo: scrollableElement;
		yourself.

scrollPane :=
	BlElement new
		addChild: scrollableElement;
		addChild: hBar;
		constraintsDo: [ :c |
			c horizontal matchParent.
			c vertical matchParent ];
		yourself.

space := OBlSpace new.
space root
	layout: BlLinearLayout new;
	padding: (BlInsets all: 10);
	background: Color blue muchDarker;
	addChild: scrollPane.
space
	extent: 500@500;
	show.

It was the same in Bloc-Pac (removing the O prefix)

https://github.com/plantec/OnBloc/assets/3044265/d874a5ff-5209-4cd1-bcac-ca6e7a92b0a7

same result here.
did you tried with a BlElement in a BlSpace ?

yes https://github.com/pharo-graphics/bloc-pac/issues/15

I'm touching scroll so can PR a fix, I guess!

maybe related
Alain
https://github.com/feenkcom/gtoolkit/issues/2917￼
[Brick] Add horizontal scrollbar · Issue #2917 · feenkcom/gtoolkit
github.com

Le 12 mai 2023 à 22:14, Martín Dias @.***> a écrit :
I'm touching scroll so can PR a fix, I guess!
—
Reply to this email directly, view it on GitHub https://github.com/plantec/OnBloc/issues/3#issuecomment-1546241239, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADKIFKJ5NWX3S4TMCN63BTXF2K2ZANCNFSM6AAAAAAX76JW2A.
You are receiving this because you commented.

Now fixed, and tested in OBlScrollBarTest


Report HTML from CI to Bitbucket PR page

Question and feature request
What did you do?
ℹ Please replace this with what you did.
Run danger at CI
What did you expect to happen?
ℹ Please replace this with what you expected to happen.
Submit an HTML formatted content/comment to Bitbucket PR page from the generated HTML file during build at CI
Your Environment

Which CI are you running on? Bitrise
Are you running the latest version of Danger? 7.0.1

Question
Is there any plugin or anyway for me to submit an HTML formatted content into Bitbucket PR page based on my HTML content generated from the CI?
Thank you

Markdown allows for arbitrary HTML, but I don't know if bitbucket allows that in their markdown renderer - GitHub doesn't for example.

Pretty sure Atlassian doesn't support that functionality.
https://support.atlassian.com/bitbucket-cloud/docs/markup-comments/

We don't support arbitrary HTML in Markdown...

I'm also curious as to why you want HTML specifically instead of the already present Markdown?


Compatibility with Rails 7 (breaking change in dependency management with Zeitwerk)

Environment

Ruby 3.0.0
Rails 7.0.0-alpha (after 14d4edd7c3b06e82e1fcef54fa0b4453315c35fd)
Devise 4.7.3

Current behavior
The Rails application doesn't boot anymore, with this error : undefined method 'reference' for ActiveSupport::Dependencies:Module
The method has been removed and Devise has to change its integration with Rails.
I've reported this in the Rails Issue tracker : https://github.com/rails/rails/issues/41706

Duplicate of #5357. Sorry!

Thanks @jlecour.


[th2-5226] Added rabbitMQManagement.cleanUpOnStart option

This change doesn't look like a hot FIX because includes library updates


Implement Reflect for tuples up to length 12

Implements Reflect and List for tuples with 0-12 elements (#1022). Since traits in the standard library are only implemented for tuples up to length 12, I figured that the same restriction could apply here.
Open questions:

Should tuples implement List? serde_json serializes tuples as arrays, so it might make sense to follow that precedent. The downside is that List::push can't be implemented for tuples, so it must panic.
Should Reflect::apply ensure that the other value has the same length as the tuple, or is it safe to allow values with fewer elements for a partial apply? Currently, it will only panic if the incoming value has more elements than the tuple supports.

For the second point, unless a use case comes up, I would expect that requiring the lengths to be the same is a sensible restriction.

For the second point, unless a use case comes up, I would expect that requiring the lengths to be the same is a sensible restriction.

Should tuples implement List? serde_json serializes tuples as arrays, so it might make sense to follow that precedent. The downside is that List::push can't be implemented for tuples, so it must panic.

Yeah the fact that you can't push to tuples means they aren't a List imo. And given that bevy_reflect aims to be a "rusty" reflection crate, I think it makes sense to add a new Tuple trait to represent tuples (which would also get added to ReflectRef / ReflectMut). Tuple-ness is semantically useful information to have. And serializers can still choose to serialize tuples as lists if that makes sense.

Should Reflect::apply ensure that the other value has the same length as the tuple, or is it safe to allow values with fewer elements for a partial apply? Currently, it will only panic if the incoming value has more elements than the tuple supports.

Tough call. Reflect::apply is intentionally a bit "fuzzy" to allow "patching" scenarios. So we have to decide if it makes sense to "patch" (A, B, C) with (A, B). I think its probably safe to fail in that case for now. I can't think of a scenario where that would be desirable.

Should tuples implement List? serde_json serializes tuples as arrays, so it might make sense to follow that precedent. The downside is that List::push can't be implemented for tuples, so it must panic.

Yeah the fact that you can't push to tuples means they aren't a List imo. And given that bevy_reflect aims to be a "rusty" reflection crate, I think it makes sense to add a new Tuple trait to represent tuples (which would also get added to ReflectRef / ReflectMut). Tuple-ness is semantically useful information to have. And serializers can still choose to serialize tuples as lists if that makes sense.

Should Reflect::apply ensure that the other value has the same length as the tuple, or is it safe to allow values with fewer elements for a partial apply? Currently, it will only panic if the incoming value has more elements than the tuple supports.

Tough call. Reflect::apply is intentionally a bit "fuzzy" to allow "patching" scenarios. So we have to decide if it makes sense to "patch" (A, B, C) with (A, B). I think its probably safe to fail in that case for now. I can't think of a scenario where that would be desirable.

Yeah the fact that you can't push to tuples means they aren't a List imo

Hmm maybe that isn't true. I would probably impl List for arrays and they can't be pushed to.

Yeah the fact that you can't push to tuples means they aren't a List imo

Hmm maybe that isn't true. I would probably impl List for arrays and they can't be pushed to.

Yeah the fact that you can't push to tuples means they aren't a List imo. And given that bevy_reflect aims to be a "rusty" reflection crate, I think it makes sense to add a new Tuple trait to represent tuples (which would also get added to ReflectRef / ReflectMut). Tuple-ness is semantically useful information to have. And serializers can still choose to serialize tuples as lists if that makes sense.

I agree with this. Semantically, tuples are not lists. Tuples aren't designed as collections the same way that lists, sets, and maps are. That being said, tuples have been shown to hold similarities to lists in dynamic languages (for instance Python). I think that if we were to create a new Tuple trait, we would find that there are a lot of similarities between it and the List trait. Additionally, it would be very similar to how we would handle arrays, which also have a fixed size and are essentially n-tuples of a single type (although not semantically, but in terms of how they are used).
At the very least, if we were to create a Tuple trait, I think that we would need to change some of the interface for it. For instance, you don't "push" to a tuple, but rather set a value in it. It would make sense in that instance to remove the push method and favor get_mut instead for updating the fields. Additionally, it might not make sense to have the iter function on the tuple either. Each field could potentially be a different type, and semantically tuples aren't intended to be iterated over since they are not collections.
I don't mind creating a new Tuple trait with these changes and implementing that instead. It would also work better with serialization since some serializers don't turn tuples into list (for example RON). Do you think we should go this route instead, and if so do you have any suggestions for the functions that should exist on the Tuple trait?

Yeah the fact that you can't push to tuples means they aren't a List imo. And given that bevy_reflect aims to be a "rusty" reflection crate, I think it makes sense to add a new Tuple trait to represent tuples (which would also get added to ReflectRef / ReflectMut). Tuple-ness is semantically useful information to have. And serializers can still choose to serialize tuples as lists if that makes sense.

I agree with this. Semantically, tuples are not lists. Tuples aren't designed as collections the same way that lists, sets, and maps are. That being said, tuples have been shown to hold similarities to lists in dynamic languages (for instance Python). I think that if we were to create a new Tuple trait, we would find that there are a lot of similarities between it and the List trait. Additionally, it would be very similar to how we would handle arrays, which also have a fixed size and are essentially n-tuples of a single type (although not semantically, but in terms of how they are used).
At the very least, if we were to create a Tuple trait, I think that we would need to change some of the interface for it. For instance, you don't "push" to a tuple, but rather set a value in it. It would make sense in that instance to remove the push method and favor get_mut instead for updating the fields. Additionally, it might not make sense to have the iter function on the tuple either. Each field could potentially be a different type, and semantically tuples aren't intended to be iterated over since they are not collections.
I don't mind creating a new Tuple trait with these changes and implementing that instead. It would also work better with serialization since some serializers don't turn tuples into list (for example RON). Do you think we should go this route instead, and if so do you have any suggestions for the functions that should exist on the Tuple trait?

I noticed there's a TupleStruct trait as well. Could we use this instead of List somehow? The only issue I see is that DynamicTupleStruct requires a name.

I noticed there's a TupleStruct trait as well. Could we use this instead of List somehow? The only issue I see is that DynamicTupleStruct requires a name.

I think it probably makes sense to use TupleStruct as a base, but I think it should be a new Tuple type (without the name).
I'm also totally fine with adding an iterator over tuple values. While that wouldn't normally make sense in a static language, one of the goals of bevy_reflect is to enable dynamic interactions with data.

I think it probably makes sense to use TupleStruct as a base, but I think it should be a new Tuple type (without the name).
I'm also totally fine with adding an iterator over tuple values. While that wouldn't normally make sense in a static language, one of the goals of bevy_reflect is to enable dynamic interactions with data.


Chjange

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:
Break down in numbered steps
Expected Result:
Describe what you think should've happened
Actual Result:
Describe what actually happened
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number:
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation:
View all open jobs on GitHub

Triggered auto assignment to @conorpendergrast (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.


SAP OData Connector Troubleshooting Guide

Original word document proofread and converted into documentation for docs site

Approved by Nidhi over Slack


Actor Reminders": Use a standard time span format like ISO8601 for dueTime and Period

/area runtime
Currently Dapr runtime expect Golang style of time formatting https://golang.org/pkg/time/#ParseDuration
It should accept a standard way of specifying timespan as its meant for cross language usage, like ISO8601.
Same for timers.

After discussing with @amanbha this is not necessary.  3 SDKs have implemented the current format, and the time format is not something that will interact with other systems/technologies..

Closing this issue as accepting Golang style of time formatting https://golang.org/pkg/time/#ParseDuration is fine. Its communicaiton between Dapr and Actor SDKs.


Include DbClusterResourceId as accessible attribute of DbCluster

(This issue duplicates https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/192, as I'm interpreting the contribution guidelines in this way; if that is incorrect, please let me know.)
This attribute is needed for some specific circumstances, and cannot currently be retrieved through GetAttr.

This attribute was added to the resource and rolled out in all AWS regions. Closing this issue for now.


falco is terminated abnormally in GKE.

Hi, I am verifying falco in GKE environment.
There are times when falco is terminated with following message.
Runtime error: Socket handler (k8s_deployment_handler_event) an error occurred while connecting to https://kubernetes.default: Connection timed out. Exiting.

I think that GKE's master node may not be responsive to scaling or upgrading by Google.
Is it difficult to create code that assumes that the master node will not respond?

What deployment method are you using, DaemonSet or Helm chart?
We recently changed the daemonSet to use the environment variable for the kubernetes master, but it looks like the Helm chart didn't get this change.

I am using Helm chart.
I'll try changing args!

It seems that I fixed it when I took in the update.
Thanks!


📊 User Metrics

User Story
As a… Cloud Ops Engineer
I need/want/expect to… understand how many users have logged into the portal in the last day/week/month/year
So that… we can better understand the use of the portal / liaise with the rest of the business with this information
Value / Purpose
As per the recent road shows the business expects teams / products to be data driven, this metric will tie in with that.
Useful Contacts
NA
Additional Information
NA
Definition of Done (DoD)
As part of refinement it should be decided if the metrics should appear on the port under a new route e.g. /metrics or /stats OR the data should appear in a Grafana dashboard. It should also be decided if this should be viewable by all users or just the admin if added to a route.
Checklist for definition of done and acceptance criteria, example below (optional).

Hey team! Please add your planning poker estimate with ZenHub @ASTRobinson @bagg3rs @kyphutruong @mitchdawson1982 @moontune @mTouhid @wanieldilson


[CDataTable] Add row css class on row click

    "@coreui/coreui": "3.0.0",
    "@coreui/icons": "1.0.1",
    "@coreui/vue": "3.0.0",

When I click on a row, the row-clicked event is fired. I would like the clicked row to have a different background color, so the current clicked row can be made visible to the end-user. Maybe a css class can be added to the clicked row, which can then be styled.
Could be like this (just the visual feedback):
http://tabulator.info/examples/4.5#selectable

Hi! Thank you for the idea!
For now, it is possible to do this like this:
In template
<CDataTable add-table-classes="table-class">

in styles
.table-class tr:focus {
  background-color: blue !important;
}

Nevertheless, this idea is worth thinking about, especially if we will decide to introduce the multi-select feature that you have proposed.
We will also consider adding default styling to the row on focus.

For now I added the code below this in my custom .scss:
@import "~@coreui/coreui/scss/variables/components/tables";

.table-class tr:focus {
  background-color: $table-accent-bg !important;
}

The only downside is that when focus is lost the background color is lost as well. But this is a valid workaround in the meantime.
Thank you for your suggestion!

CSS class 'table-selected' is now available in coreui-pro  (3.2.0 version)
:focus style is applied automatically, and have the same visual effect


Change scope separator to the correct one for pnut (comma)

That one is enough to at least make the module work if one knows how to configure passport-oauth. Previously, a user was forced to set scopeSeparator in the options hash  (who would want to have a configurable scope separator anyway? Seriously, I can't even think of a reason to have alternative / configurable separators in the auth URL o_O)

Oh, just noticed, we don't have any genders.


[HOW-TO] Start and stop preview for a photobooth

I would like to have a photobooth take 4 pictures. But often people get confused if I start a preview and the image freezes to take the still then preview starts moving again and then freezes for the next photo.
I wanted to make a gap... to allow the person to get info that the picture was taken and they need to get ready for the next shot.
My thought was the code would work like this
picam2.start_preview(True)
time.sleep(5)
picam2.capture_file("test1.jpg")
picam2.stop_preview()
print("Next shot coming up")(I use pygame to display an image on screen to say...next shot)
time.sleep(3)
picam2.start_preview(True)
time.sleep(5)
picam2.capture_file("test2.jpg")
picam2.stop_preview()

But when I code something like this the preview works for the 1st time shot, but does not show up for the second time...
Thing is I might be approaching this issue totally wrong but I can't see what to do to make this work

Hi, thanks for the question. I wasn't sure if you were starting the camera - start_preview only opens a preview window but doesn't start the camera. This would be one way:
from picamera2 import Picamera2
import time

picam2 = Picamera2()
picam2.start_preview(True)
picam2.start()
time.sleep(2)
picam2.stop_preview()
time.sleep(2)
picam2.start_preview(True)
time.sleep(2)
picam2.stop()
picam2.stop_preview()

It leaves the camera running even while the preview is stopped, and then restarts the preview window.

When I run your code this is what I get in the shell... should add I am running this on Raspberry OS lite (no X env)
python3 cam2.py 520-SBGGR12_1X12 - Selected unicam format: 2028x1520-pBCC [41:10:51.407248886] [7712]  INFO Camera camera_manager.cpp:293 libcamera v0.0.1+54-d528119fpykms.Connect[41:10:51.582558277] [7713]  INFO RPI raspberrypi.cpp:1414 Registered camera /base/soc/i2c0mux/i2c@1/imx477@1a to Unicam device /dev/media3 and ISP device /dev/media0Manager object at 0xb3bcf440> <pykms.Connect<pykms.pykms.Card object at 0xb3b9f300> <pykms.pykms.ResourceManager object at 0xb3b9f280> <pykms.Connector 32> <pykms.Crtc 89>.py [41:10:51.688662514] [7712]  INFO Camera camera.cpp:1026 configuring streams: (0) 640x480-XBGR8888 [41:10:51.692192522] [7713]  INFO RPI raspberrypi.cpp:800 Sensor: /base/soc/i2c0mux/i2c@1/imx477@1a - Selected sensor format: 2028x1520-SBGGR12_1X12 - Selected unicam format: 2028x1520-pBCC <pykms.pykms.Card object at 0xb3b9f6e0> <pykms.pykms.ResourceManager object at 0xb3b9f340> <pykms.Connector 32> <pykms.Crtc 89> commit failed commit failed
I see the 1st preview and when it stops its not restarting - I get the commit failed error

should add... I thought I was missing something to restart the preview... maybe something with resources like the preview was not fully closed/stopped? or that restarting it did not work with the auto detecting the mode (which would be DRM for me)
commit failed is just not enough to google

Ah, sorry, didn't realise you were using DRM. Indeed, some resources got added which it doesn't appear to be releasing. Are you running from source code? If so I could send you a patch, otherwise it's a question of waiting for a new release.

I am not running from source but I can, I need this booth up for the 14th (office party) so that would help me out a lot thanks mate

Sure, here are some instructions.
Firstly, clone the repository, for example
cd /home/pi
git clone https://github.com/raspberrypi/picamera2

Next add this to your PYTHONPATH variable. Easiest thing is probably to add /home/pi/picamera2 (or wherever you cloned it) to your /home/pi/.bashrc file by adding this line to the bottom:
export PYTHONPATH=/home/pi/picamera2

and start a new terminal window if you want to try it right away (or log out and back in again).
Finally, add the patch to the file picamera2/previews/drm_preview.py in the /home/pi/picamera2 folder. You need to add these lines
        self.fd = None
        self.mem = None
        self.fb = None

to the end of the stop function which is right at the bottom of the file.

Perfect thats working you are a lifesaver!

We've merged the patch into our code so it will be in the next release. In the meantime I'll close this issue. Thanks!


implement from import/import except, fix declared

My best attempt at good enough looking code, open to suggestions

Merging to avoid conflicts, worst case can be cleaned up later


export support

If the export annotation doesn't exist, we should apply the following heuristics that generate a bag of files consisting of:
Round 1:

[x] add export button based on the export annotation

Round 2:

[x] csv file for the main entity
[x] csv file for all the related tables (whether in-line or not)
single hop : the fk to the main entity should be there already
multi-hops: add fk to the main entity as an extra column
[x] fetch output for all the columns that have asset annotation

Round 3:

[ ] Apply max limit for recordset export or throw a warning when total records to be exported is large (e.g. 1M row?)
[x] Apply hueristics to handle outbound fk appropriately e.g. add "title'/"name" along with the outbound fks that link to an "RID" or "id" (for vocab tables).
[ ] handle iobox not installed.

Round 4:

[x] contextualize export. See issue informatics-isi-edu/chaise/issues/1621

Policy Question/Assumptions: We have made some assumptions about how we're interpreting the annotation and where we're getting the list of columns from.

Fetch assets

We are only adding asset columns that are visible in detailed context for both the main table and related tables in the record page. We could remove the context check and add any asset column that is defined on the schema document.
Only include asset columns that have all the asset related columns (byte_count, file_name, and md5/sha256). Should we relax this requirements and let ioboxd handle those?

@hongsudt
There are only two tasks remaining in this issue which I'm not sure if these are still relevant. Even if these are relevant, we don't need this epic anymore and we can move them to their own separate issues.  The issues are

[ ]  handle iobox not installed.
[ ]  Apply max limit for recordset export or throw a warning when total records to be exported is large (e.g. 1M row?)

Moved the remaining issues to #944.


[HW]

Name:  Robert Brahmane
Email<EMAIL_ADDRESS>Linkedin Profile: < https://www.linkedin.com/in/robertbrahmane >
Attach the homework screenshots below for both step II and step III:

Hey Robert Brahmane, great job! Congrats! Here is your badge! https://api.badgr.io/public/assertions/va2VfAoEQmqwSxu4WbQJbQ


style: goals | syling goals page

Fixes Issue
https://github.com/thecyberworld/TheCyberHUB/issues/760
Changes proposed
styling of the goal card and the goal input field , changing the add goal button to "+"
Screenshots

Note to reviewers

Code of Conduct

[ ] By submitting this pull request, I confirm I've read and complied with the CoC 🖖

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] My change requires changes to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

You can also join our Discord community.
Feel free to check out other cool repositories of the Thecyberworld.
Join the Thecyberworld GitHub Organisation by raising an issue (you will be sent an invitation).

@Salem-Bourguiba Looks Great 💯 I have only two minor comments.

align the '+' button it in center or make the height to be as of the input box

2. when I have one sentence or less words it looks a little bit weird too far from the 'x', add min-height for the content box.

done


Minor build env extensions

git ignores of built files
clean in top level makefile
allow environmental overrides in deploy.sh
Nothing major, just figured I'd send them.

Thanks!


Chat rolling maybe broken since 0.8.11

Since updating to 0.8.11 we are unable to do the /r /roll command. Screenshot provided by @Onlinemph on Discord, who replicated this issue.
Reference: https://discord.com/channels/228546929494065152/788878698349723669/807120762308919296

Yep... my bad.   My fancy schmancy chat handler was getting in the way of regular chat messages.
Fixed in 0.8.12.    It still isn't perfect, but at least now, it stays out of the way if you aren't invoking one of our special commands.


Multiple missing eventsub messages (not beta)

Description
Several message types are missing from eventsub. These were all added in the past few months.

https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelchannel_points_automatic_reward_redemptionadd
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelmoderate-v2
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelunban_requestcreate
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelunban_requestresolve
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelsuspicious_usermessage
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelsuspicious_userupdate
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelvipadd
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelvipremove
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelwarningacknowledge
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#channelwarningsend
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#conduitsharddisabled
https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#userwhispermessage

this is non exhaustive. I may have missed some

Most of these are adressed with #457, also we have a handy tracker in the documentation showing what's missing ;)
Conduit Shard Disabled is implemented
Going to close this issue as it's not very interesting to keep open. But thank you for the effort! Feel free to make a pr to implement https://dev.twitch.tv/docs/eventsub/eventsub-subscription-types/#userwhispermessage as that's the only one on your list that's missing and is useful


dts: edtlib: Support giving missing properties a default value

First commit implements default:, the rest first change some stuff to be able to sanity check bindings in a robust way, and then adds sanity checking for default:.
See the binding-template.yaml changes for documentation.
Fixes https://github.com/zephyrproject-rtos/zephyr/issues/17829.
dts: edtlib: Support giving missing properties a default value

For optional properties, it can be handy to generate a default value
instead of no value if the property is missing, to cut down on #ifdefs.

Allow a default value to be specified in the binding, via a new
'default: <default value>' key on properties in 'properties:'.

Suggested by Peter A. Bigot in
https://github.com/zephyrproject-rtos/zephyr/issues/17829.

The documentation changes in binding-template.yaml explain the syntax.

Fixes: #17829

dts: edtlib: Check the final merged binding instead of each file

It's currently impossible to check that 'type:' is consistent with
'default:' in a robust way, as they might come from different !included
files and be overridden.

Instead of checking each !included file, have _check_binding() check the
final merged binding. This should also make it possible to move some
other checks there.

dts: edtlib: Improve naming in _check_binding()

'keys' is really a dictionary of settings (like {"type": "int", ...})
for a property. Calling it 'settings' makes it clearer.

dts: edtlib: Check that 'default:' values are okay

'default:' values for properties in bindings need to match the 'type:'
setting.

The check is done in a new _check_prop_type_and_default() helper
function that's called from _check_binding(). The 'type:' value check is
moved there as well.

This relies on that we now only check the final merged binding. It
wouldn't be robust otherwise, since types and defaults might get added
in different files that then get merged.

dts: edtlib: Make _init_props() naming consistent with _check_binding()

_check_binding() calls the per-property settings dict 'settings'. Call
it that in _init_props() too, instead of 'options'.

@galak
It's best to think of this as just an output control setting.
If you have properties like foo-pin = <123> or buf-size = <123> that only apply in some cases, and the code happens to use e.g. -1 as a flag value for foo-pin in cases where it does not apply, then it's nicer to have default: -1 than to force nodes to set foo-pin = <(-1)>.
It avoids exposing code internals in the device tree. The default: is just between the binding and the code.

Another way to think of it: in "real" device tree descriptions that are processed at runtime you can detect presence/absence of a property and do the right thing with respect to default behavior.
Because Zephyr needs to do some of that presence reaction at compile time this flexibility is lost, so we need a way to restore it that doesn't involve horrific preprocessor macro manipulation (or more horrific than we already have).
The real killer application of this is devices with multiple instances, of which there aren't a lot now, but I have one that needs this.  I'll try to get it into a proof-of-concept stage so people can see where it's needed.

@galak
Discovered that dt-schema actually seems to support this by the way. See this in example-schema.yaml:
  clock-frequency:
    # The type is set in the core schema. Per device schema only need to set
    # constraints on the possible values.
    minimum: 100
    maximum: 400000
    # The value that should be used if the property is not present
    default: 200

Nice that it's there to get things moving, but more generally I think we should ignore what the "other guys" are doing except as inspiration, and judge things on their own. Maybe dt-schema is horrible. Maybe it's more complex than what we need, or adapted for different needs.
I don't think "dt-schema does this or that" should ever be a deciding factor on its own ("dt-schema does this, and I like it" is better).
There are lots of little improvements that could be made to the existing format, and it'll be really frustrating for me if they're blocked because "it's either dt-schema or no change". :/

I'm on the exact opposite side.  If there's a standard that seems to have traction, frameworks should have a very strong reason for deciding to dismiss it and create a similar but incompatible solution.  Especially if, as I understand it, a driving reason for Zephyr's use of YAML devicetree schemas is compatibility with other systems.
As I understand it dt-schema comes from the same people who define the devicetree standard.  As such we should use it, or we should stop claiming that we're using devicetree.
We also could re-use the existing tooling already provided by dt-schema to handle the parsing and validation, and instead focus effort on expressing the bindings in ways that make sense in Zephyr.  The evolution of the last year has come closer to a consistent and usable capability, but I still find it pretty limited and frustrating to use.

@pabigot
I said that we shouldn't refrain from improving on what we have unless it's an instant switch to dt-schema, not that we should never switch to dt-schema.
We must also be able to point at something and says "this sucks, and we won't be doing it", even if it's "the standard". Standards are only worth so much.
(FWIW, I suspect dt-schema is pretty nice, but it's the mindset that matters.)

Replaced with https://github.com/zephyrproject-rtos/zephyr/pull/18788.


change http to https for disqus

Changed to secure protocol for the call to http://disqus.com (https)

Again, thank you Etienne! I hope that you are enjoying both Pelican and mg and that I will see more of your contributions in the future.

My pleasure ! mg and Pelican make it very easy to focus on writing instead of managing a blog. Thank you for mg.


feat(apps/prod/tekton/setup): bump tekton-operator to v0.60.0

It bump these components:

hub: v1.8.0
dashboard: v0.27.0
pipeline: v0.37.0
chains: v0.9.0

/approve


ProvideOptional utility function makes it easy to fx.Provide NewOption wrappers

What does this PR do?
Creates a fxutil.ProvideOptional utility to wrap types in an optional.Option and fx.Provide them.
Motivation
ProvideComponentConstructor cannot be modified to return optional wrappers for the Component it handles.
The reason is that ProvideComponentConstructor uses reflection to build fx-aware struct types from regular (non-fx) struct types, at runtime. However, generics in golang are a compile-time feature, meaning they must be given a concrete type when the compiler resolves a usage site. This is a consequence of generic's design, the GCShape can only be built at compile-time, so it isn't possible for ProvideComponentConstructor to create the optional.Option[T] from a reflect.Type as we would prefer.
So as a work-around, this PR defines a generic utility function fxutil.ProvideOptional[T] that does what we want. Although this doesn't provide automatic creation of an optional wrapper, this is nicer in one particular way: we get to be explicit about what types are allowed to be used as optionals.
Additional Notes
Possible Drawbacks / Trade-offs
Describe how to test/QA your changes
Functionality already covered by existing tests.

/merge


update unit tests to cleanup tmp files

src/test/java/emissary/place/MultiFileUnixCommandPlaceTest.java still needs an update but submitting this w/o that change


RGB to YUV420p ?

hi, have a problem. I want to draw in RGB24 pixel format.
But libx264 expects YUV420p.
FFMPEG can do the conversion by itself but i did not found in the documentation how to actually do it with in this library.

Hi @void-dragon! As with the ffmpeg libraries themselves, you need to use the scaler to transform your frames from one pixel format to another: https://docs.rs/ac-ffmpeg/0.18.1/ac_ffmpeg/codec/video/scaler/struct.VideoFrameScaler.html

Thx, for removing the obvious splinter from my eye.
This works like a charm.
    let mut scaler = video::VideoFrameScaler::builder()
        .source_pixel_format(pixel_format_rgb)
        .source_width(width)
        .source_height(height)
        .target_pixel_format(pixel_format)
        .target_width(width)
        .target_height(height)
        .build()?;
    ...
    let conv_frame = scaler.scale(&frame.freeze())?;
    ...

Good! I'm closing the issue then.


Simulator steer_ratio is incorrect. It should be 18.3345

The evidence for this is related to issue #110.
The /vehicle/steering_report returns the steering angle in radians, based upon the range of these values being [-0.447241, 0.447241] which is close to 25.62 degrees. I assume this is the correct maximum steering angle that can be actuated as most cars would have a ~40 degree steering angle.
If the above assumption is true, the SteeringCmd.steering_wheel_angle_cmd values are about ~18.33x the values output by SteeringReport.steering_wheel_angle_cmd. I've tested this with a few different values and it holds true for all valid steering angles.

Responded on #110.


How about update hapi-sequelize to hapi 17 ?

I've been thinking about update this package to work with hapi 17, but it'll be maintainded?
I see that the last commit was in 2016 and want to know for sure if I use the same code style or move to Standart... anyways, waiting for a discussion before jump right in to it, but thanks anyway for made this.

Hi @mundodehads
I have a fork with major fixes, and support for the latest hapi and sequelize versions.
Please have a look at https://github.com/valtlfelipe/hapi-sequelizejs.
I'm doing my best to maintain it updated.

@valtlfelipe Olá, vi que você é brasileiro, estava cogitando refazer esse pacote, vou dar uma olhada no seu e ver se atende minha necessidade, qualquer posso tentar contribuir ou até mesmo compartilhar minhas ideias com você em uma issue no seu projeto.
Obrigado pela resposta.

@mundodehads Opa! Vamos conversar sim! Abre uma issue lá ou um PR 😄
Abraços

#86 sorry about the inactivity thanks @valtlfelipe for his continued efforts. I'm going to start working on an update

Updated docs to refer users to hapi-sequelizejs thanks for the great work on the fork !


Stable version anytime soon ?

Back again about versioning of ZF2 modules :)
Dear @Ocramius, as the 1.0.0-RC1 tagged version has been done beginning of October, and considering we are hundreds (thousands?) of daily users of this module since... years !
It would be formidable if you could create a stable version (1.0 ?)
I fully understand why modules can stay marked as unstable sometimes, but I feel it's also a bad practice when it's too long while many users do use the module and consider it as stable...
Don't you agree ?
(I've already written that somewhere in Github but it's important : Thank you so much @Ocramius Marco Pivetta for the incredibly valuable work you offer to the PHP community day after day for years)

there is already stable version 1.0.0 and 1.1.0. close-able


Charts[Network Node]: Convert chart tests from the custom bash script to be BATS unit tests

:tada: This issue has been resolved in version 0.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Capacity per day as integer only

In v5_1/work/models.py
`
class Activity(Model):
"""Activity.
:param capacity_per_day:
:type capacity_per_day: int
:param name:
:type name: str
"""

_attribute_map = {
    'capacity_per_day': {'key': 'capacityPerDay', 'type': 'int'},
    'name': {'key': 'name', 'type': 'str'}
}

def __init__(self, capacity_per_day=None, name=None):
    super(Activity, self).__init__()
    self.capacity_per_day = capacity_per_day
    self.name = name

`
the type of the parameter capacity_per_day is 'int', but the user could fill that field with a float.
For instance with a 10 days iteration, if the user fills "4.9" in capacity per day, and that we want to use the api to calculate the total capacity for the iteration, the results from the api will be 40 instead of 49
Is there a way to change that?

#308

@RK159 thanks for reporting this issue.
The fix is in the following releases:
https://github.com/microsoft/azure-devops-python-api/releases/tag/6.0.0b2
https://github.com/microsoft/azure-devops-python-api/releases/tag/5.1.0b7

Thanks for the quick response @tedchamb that helps a lot!


Remove brew search --desc in readme

--desc flag is invalid.
resolves #243

It's not invalid as such, the documentation is just a little unclear/misguided. You use brew search --desc with a keyword of what you're looking for, i.e. I want to find formula that provide some kind of sql solution so I run:
~> brew search --desc sql
apache-drill: Schema-free SQL query engine for Hadoop and NoSQL
apgdiff: Another PostgreSQL diff tool
automysqlbackup: Automate MySQL backups
citus: PostgreSQL-based distributed RDBMS
fastbit: Open-source data processing library in NoSQL spirit
freetds: Libraries to talk to Microsoft SQL Server and Sybase databases
gom: GObject wrapper around SQLite

Would it be ok to change this PR to have it say the following?

Or use brew search --desc text|/text/ to browse packages from the command line.

In addition I can create a separate PR to add --desc to the help text for brew search. Are there any other flags missing from that text?

Would it be ok to change this PR to have it say ...

Yes; please! That text is confusing as is; I would have made the same mistake. Or closing this and opening a new PR to do so might be less work than revising this and editing the description and comment history on this one to still be cogent.
At this location, I'd do something simpler like "brew search --desc <keyword>"; don't worry too much about the full syntax with | and such, since this is a brief, informal message.

In addition I can create a separate PR to add --desc to the help text for brew search

:+1: You could just include it in the same PR, since it's related. It would be nice to have this too, since --desc is intended for common use by end users, so brew --help should describe it.
...and while you're in there, this is what the current brew --help search says:
brew search, -S:
    Display all locally available formulae for brewing (including tapped ones).
    No online search is performed if called without arguments.

brew search, -S text|/text/:
    Perform a substring search of formula names for text. If text is
    surrounded with slashes, then it is interpreted as a regular expression.
    The search for text is extended online to some popular taps.

I dunno about you, but that "brew search, -S" format with the comma seems odd and hard to read to me, and isn't standard quasi-BNF syntax. And using "text" as the placeholder for both literal text and regex patterns is hard to read IMHO. Maybe it should be something more like:
brew (search | -S)
   ...
brew (search | -S) (text | /pattern/)
   ...

Or just drop the -S from the helptext entirely, since it makes the syntax description more complex, and I'll bet 80%+ of users are using the search form instead of -S. If nothing else, change all the helptext to say brew search ... and then just put a footnote at the bottom saying "-S may be used as a synonym for search". Something like this, with appropriate markup:
brew search
   ...
brew search (text | /pattern/)
   ...

The `-S` switch may be used as a synonym for the `search` subcommand.

Ok I'll take a look.


Recent releases in HomepageService

Recent releases for the last six months are provided by HomepageService

 [Detector] Endpoint for start page infos


runtime(doc): grammar & typo fixes

Thanks, can you pleas also update the Last Change header for each of the touched help files?


Flowchartless operation

A number of questions and requests around either creating flowcharts at runtime or using parts of fungus without using Flowcharts, Blocks, and Commands to talk to systems. Creating flowcharts at runtime is not recommended and often using parts of Fungus is very dependant of the code running inside a Command's OnEnter.
Describe the solution you'd like
Moving much of the intricate logic out of commands and into systems themselves, similar to Conversation, would allow users to more easily extend and manipulate Fungus from script or potentially use Fungus without flowcharts at all.
Additional context
This would have a nice side benefit of making it easier to update editor systems in the future, as most Flowchart and other elements based on MonoBehaviours would only be corralling data to give to systems, not the logic to make them run. It would also make writing editor and playmode tests for Fungus systems easier as they would not have to be tied to a editor prefab with a flowchart on it.
This may also increase the likelihood of addition community contributions as there will be lower required understanding of Fungus' Flowcharts in order to achieve a minimum desired result.

This actually a brilliant idea, it also opens the possibility for users to build their own VN framework on top of Fungus, currently this is not possible due to how Fungus relies heavily to prefab-workflow and how little the internal APIs being exposed.
And please, Fluent like API :)


Update step to use 4.x.y of tuist

This step is on 3.x.y. Can this step be updated to use 4.x.y and the ability to select the version?

+1


feat(sdk-schematics): expose models without dictionary

Proposed change
Expose models without dictionary
Related issues

:bug: Fixes #1802

Shouldn't we re-generate the o3r showcase sdk with that ?


Run CI on main after merges

          @stevekuznetsov I think this accidentally opens up a gap in coverage. Isn't it possible for two pull requests to enter the merge queue, each of them passing in CI but the combination of them not passing? Rare, but definitely not unheard of.

Not saying this PR should get reverted, but rather that we should be running CI checks on main after every merge and I don't think we currently are.
Originally posted by @floatplane in https://github.com/NWACus/avy/issues/581#issuecomment-1858573770

I guess the merge queue is really the place to catch these sorts of failures. But just from browsing the "Actions" tab and looking at previous runs, I'm not seeing where CI checks are being run on the merge queue - maybe I'm missing something.

Oh wait now I see one: https://github.com/NWACus/avy/actions/runs/7227590574. Never mind, I think this is all working as intended! Sorry for the noise.


Does not compile on Mac M1 Silicon / Arm64 architecture

Describe the bug
Orbtk does not compile an a M1 Mac.
To Reproduce
On a M1 Mac:
cargo run --example minimal
   Compiling orbtk v0.3.1-alpha5 (/Users/stefanpfeiffer/playground/rust/orbtk-crate/orbtk)
...
  = note: Undefined symbols for architecture arm64:
            "_OBJC_CLASS_$_CHHapticDynamicParameter", referenced from:
                objc-class-ref in libsdl2_sys-5a9139bf0738ff00.rlib(SDL_mfijoystick.m.o)
            "_OBJC_CLASS_$_CHHapticEventParameter", referenced from:
                objc-class-ref in libsdl2_sys-5a9139bf0738ff00.rlib(SDL_mfijoystick.m.o)
            "_CHHapticDynamicParameterIDHapticIntensityControl", referenced from:
                -[SDL_RumbleMotor setIntensity:] in libsdl2_sys-5a9139bf0738ff00.rlib(SDL_mfijoystick.m.o)
            "_CHHapticEventParameterIDHapticIntensity", referenced from:
                -[SDL_RumbleMotor setIntensity:] in libsdl2_sys-5a9139bf0738ff00.rlib(SDL_mfijoystick.m.o)
            "_OBJC_CLASS_$_CHHapticPattern", referenced from:
                objc-class-ref in libsdl2_sys-5a9139bf0738ff00.rlib(SDL_mfijoystick.m.o)
            "_OBJC_CLASS_$_CHHapticEvent", referenced from:
                objc-class-ref in libsdl2_sys-5a9139bf0738ff00.rlib(SDL_mfijoystick.m.o)
            "_CHHapticEventTypeHapticContinuous", referenced from:
                -[SDL_RumbleMotor setIntensity:] in libsdl2_sys-5a9139bf0738ff00.rlib(SDL_mfijoystick.m.o)
          ld: symbol(s) not found for architecture arm64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: could not compile `orbtk` due to previous error

Expected behavior
Orbtk should compile and the minimal example should run.
Is the readme missing something specific for M1 Macs? I also did brew install sdl2 - no change.
README says If you have trouble build the provided OrbTk examples or simply don't want to use a C compiler, please check the backend section. It contains alternatives. - no idea what the backend section is.

Hey dl1ely,
thanks for taking up OrbTk for a m1 based system.
I'm sorry, but personally i don't have access to a mi/arm64 powered system. So I can't cross check. Towards the addressed README subsection: Since we/i have reworked the document lately, i must have killed a former link. I will cross check but dought, that this document would have a clue to the give issue. If i recall correctly, it was intended to describe the build process for web targets. But i might be completely wrong.
Anyway, the lock clearly reference the missing symbols in libsdl2_sys (rust wrapper), that will consult the system sdl2. Maybe the sdl2 version on your silicon has an older release version or the linke can't find the shared library?

Hi Ralf,
thanks for your kind reply. I am new to the apple platform. Unfortunately i am lacking the skills to debug such problems on my own. No idea what i am missing here and how to fix it.
Perhaps someone else with experience in these kind of issues can shed a light in the future, when M1 based systems become more widespread.
Thank you so far!
Stefan

you can try to add a build.rs at the root of project (same level as cargo.toml). and add following code into it. This will try to link the binary against CoreHaptics framework.
fn main() {
    println!("cargo:rustc-link-lib=framework=CoreHaptics");
}

This works and works on M2 Apple Silicon.

Thanks @tanzhenghao-james;
this is good to know. I'm not experienced enough to rule out, if that build.rs snippet should be added automatically if installation detects mac silicon? Anyone else?
The CoreHaptics framework seems to be an opt in for Apple devices ....

Sorry for delay.Since we depends on rust-sdl2 and they depends on CoreHaptics, it would be better to let they address this issue.


Sign-in bug

Time Tracking: MA-78
Students reporting they are unable to login to SSO on QA
Reproduction Test 1:

A) Sign-in bug reproduced on Experimental as Student
B) Sign-in bug reproduced on v7.24.0 as Student
C) Sign-in bug reproduced on Experimental as Staff
D) Sign-in bug reproduced on v7.24.0 as Staff

Notes:

Checkout a tag:
git checkout v7.24.0 -b v7.24.0

Hi @Jackkkkkkdzk & @mliu6723,
Issue updated after review.
Please re-test and report your results here for Test 1 (A) and (B) above. Please include device type Android or iOS.

Hi All,
I just tried running the build I got from "git checkout v7.24.0 -b v7.24.0" and I'm getting the following errors (see below). Note: I am able to run/build the regular experimental branch without issue, and I tried running both of these builds on both a "Pixel 2 API 30" and a "Pixel 6 API 31" emulator with same results/errors.
"
Launching lib\main.dart on sdk gphone x86 in debug mode...
Running Gradle task 'assembleDebug'...
../../AppData/Local/Pub/Cache/hosted/pub.dev/file-6.1.2/lib/src/interface/file.dart:15:16: Error: The method 'File.create' has fewer named arguments than those of overridden method 'File.create'.
Future create({bool recursive = false});
^
org-dartlang-sdk:///third_party/dart/sdk/lib/io/file.dart:232:16: Context: This is the overridden method ('create').
Future create({bool recursive = false, bool exclusive = false});
^
../../AppData/Local/Pub/Cache/hosted/pub.dev/file-6.1.2/lib/src/interface/file.dart:15:16: Error: The method 'File.create' doesn't have the named parameter 'exclusive' of overridden method 'File.create'.
Future create({bool recursive = false});
^
org-dartlang-sdk:///third_party/dart/sdk/lib/io/file.dart:232:16: Context: This is the overridden method ('create').
Future create({bool recursive = false, bool exclusive = false});
^
../../AppData/Local/Pub/Cache/hosted/pub.dev/file-6.1.2/lib/src/forwarding/forwarding_file.dart:22:8: Error: The method 'ForwardingFile.createSync' has fewer named arguments than those of overridden method 'File.createSync'.
void createSync({bool recursive = false}) =>
^
org-dartlang-sdk:///third_party/dart/sdk/lib/io/file.dart:248:8: Context: This is the overridden method ('createSync').
void createSync({bool recursive = false, bool exclusive = false});
^
../../AppData/Local/Pub/Cache/hosted/pub.dev/file-6.1.2/lib/src/forwarding/forwarding_file.dart:22:8: Error: The method 'ForwardingFile.createSync' doesn't have the named parameter 'exclusive' of overridden method 'File.createSync'.
void createSync({bool recursive = false}) =>
^
org-dartlang-sdk:///third_party/dart/sdk/lib/io/file.dart:248:8: Context: This is the overridden method ('createSync').
void createSync({bool recursive = false, bool exclusive = false});
^
"

Hi Charles,
I encountered same error as Trent when testing 7.24. Following your instructions, I have now successfully tested both Experimental and v7.24.0 as Student and as Staff on both iOS simulator and Android emulator(Pixel 5). I have found no problem logging in to SSO.

After downgrading my Flutter version to 3.3.10, I was also able to successfully log-in on both of my emulators ("Pixel 2 API 30" and a "Pixel 6 API 31") on my student and work accounts.
However, I also experienced several graphical issues on the app home screen which included individual cards and sometimes the entire home screen itself not displaying. These error culminated in the app crashing on both my emulators on multiple occasions.
In trying the 7.24v on my physical device (Pixel 6a android 13), I was also able to replicate these same graphical errors (screenshots below) but did not encounter a crash (the home screen froze several times though and had to be reloaded).
Additionally, it is worth noting that across all devices (physical and emulated) both the employee ID card and student ID card either returned an error or displayed blank while I was purportedly logged in to my work or student account respectively.

Sign-in bug verified resolved in May, let's close this out.
@tkiyohar would you please create a new issue for the web card height problem if there is not one already. Student ID not rendering in QA is being worked on in a separate issue.


Add flags to allow multiple spaces in request and status lines

Depends on #111.
These new flags set whether multiple spaces are allowed as delimiters in request lines and response status lines.
The latest version of the HTTP/1.1 spec (request lines, response status lines) allows implementations to parse multiple whitespace characters in place of the SP delimiter in the response status line, including:

SP, HTAB, VT (%x0B), FF (%x0C), or bare CR

This option relaxes the parsers to allow for multiple spaces, but does not allow the delimiters to contain the other mentioned whitespace characters. We'd rather wait for someone to have a concrete use case before deciding to support that, as allowing chars like \r raises serious security questions as described by the spec.

Marking this as a draft temporarily, it turns out I was premature and we'll need this for request lines too :disappointed:

This is ready for review, but will depend on #111 to actually pass tests etc. It doesn't look like I can change the base branch of the PR to point to my fork, but once #111 is merged it should update automatically.

Sigh, the fuzzer found a bug with this PR after combining with #111. Back to draft for now.

I have rewritten this to eagerly check the flag rather than backtracking after an error, which fixes the bugs mentioned above and obviates the issue where the reason phrase would include leading spaces from the delimiter. Happily this seems to be a performance improvement rather than a regression even when the new flags are disabled (results vs 6f6ff10):
req/req                 time:   [292.13 ns 295.81 ns 301.23 ns]
                        thrpt:  [2.2261 GiB/s 2.2668 GiB/s 2.2954 GiB/s]
                 change:
                        time:   [-13.390% -12.468% -11.159%] (p = 0.00 < 0.05)
                        thrpt:  [+12.561% +14.244% +15.460%]
                        Performance has improved.

req_short/req_short     time:   [62.834 ns 62.992 ns 63.188 ns]
                        thrpt:  [1.0023 GiB/s 1.0054 GiB/s 1.0079 GiB/s]
                 change:
                        time:   [-11.112% -9.9009% -8.9416%] (p = 0.00 < 0.05)
                        thrpt:  [+9.8196% +10.989% +12.501%]
                        Performance has improved.

resp/resp               time:   [303.51 ns 304.23 ns 305.34 ns]
                        thrpt:  [2.1320 GiB/s 2.1398 GiB/s 2.1449 GiB/s]
                 change:
                        time:   [-12.059% -11.512% -11.016%] (p = 0.00 < 0.05)
                        thrpt:  [+12.379% +13.010% +13.713%]
                        Performance has improved.

resp_short/resp_short   time:   [67.521 ns 67.686 ns 67.929 ns]
                        thrpt:  [1.2476 GiB/s 1.2521 GiB/s 1.2552 GiB/s]
                 change:
                        time:   [-9.1562% -8.7366% -8.3331%] (p = 0.00 < 0.05)
                        thrpt:  [+9.0906% +9.5730% +10.079%]
                        Performance has improved.

I haven't thrown it into godbolt or anything yet, but I suspect something about this change triggers a different inlining behavior compared to the baseline.

Is there any other parsing changes you expect, or shall we prep a crate release?

@seanmonstar we should be good to prep a release, thanks! I've been fuzzing this against our internal fork of picohttpparser and am not finding any other places for improvement, although I am excluding path parsing from the fuzzing for now. Paths are more difficult because both httparse and pico lean on other libraries to meaningfully interpret them, so future changes that come out of that work are more likely to land in http anyway.

This broke some stuff: prior to this PR, there was no way to parse a request with a specific parser config, that allowed me to implement allow_spaces_after_header_name_in_responses and allow_obsolete_multiline_headers_in_responses only for responses without explicit checks.
Now that there is a ParserConfig::parse_request method, those flags are applied to both requests and responses.


refactor: index.js exports

This fixes an issue with the latest version of Create React App with Typescrpt, where the app will crash due to unsupported exports with an alias.

@kepta I am having issues running unit tests locally, any help would be appreciated.

Thanks for helping out @damianthekreeeytor I am looking into this.


LX100 G2 variant drops JTAG Vref during programing

The G2 I tested with is an LX100 variant, and during flash readback or programming, it drops Vref on the JTAG thus the programming fail. Has programming of the LX100 Pano with standard 14.7 and DLCP9 clone succeeded for others?
This is how device status looks like. Is it possible eFUSES are blocking access?
'1': Reading bootsts register contents...
[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         1
[1] FALLBACK_0 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         1
[2] RESERVED                                                               :         0
[3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR                                  :         1
[4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR                                  :         0
[5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                      :         0
[6] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         1
[7] FALLBACK_1 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         0
[8] RESERVED                                                               :         0
[9] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR                                  :         0
[10] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR                                 :         0
[11] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                     :         0
[12] STRIKE CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         1
[13] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         1
[14] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[15] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
'1': Reading status register contents...
[0] CRC ERROR                                                              :         0
[1] IDCODE ERROR                                                           :         0
[2] DCM LOCK STATUS                                                        :         1
[3] GTS_CFG_B STATUS                                                       :         1
[4] GWE STATUS                                                             :         1
[5] GHIGH STATUS                                                           :         1
[6] DECRYPTION ERROR                                                       :         0
[7] DECRYPTOR ENABLE                                                       :         0
[8] HSWAPEN PIN                                                            :         1
[9] MODE PIN M[0]                                                          :         1
[10] MODE PIN M[1]                                                         :         1
[11] RESERVED                                                              :         0
[12] INIT_B PIN                                                            :         1
[13] DONE PIN                                                              :         1
[14] SUSPEND STATUS                                                        :         0
[15] FALLBACK STATUS                                                       :         0

I replaced the flash with IS25LP064. Still the same behavior - Vref drops on the JTAG thus the flash programming fails. So it's not in the bootloader unless there is something in the eFUSE. Any ideas?

The lx150 version I have also has the same issue G2-RevB

I've run into this issue as well, but I've found an unreliable way of getting past it which might be a clue…
As far as I can tell, Vref drops when iMPACT tries to load the SPI access core to the device, and the device reboots into the factory bitstream. But if you mash the Pano button while it's doing this, sometimes the SPI access core will load anyway, and it'll work fine.
I wonder if the SPI access core is inadvertently triggering some kind of power-off mode on the Pano?

No luck with the pano button in my case. BTW, I replaced the flash with a new blank IS25LP064. The whole 2.5V power rail drops during the programming. It's done by pulling the enable input on U16 (LM2830) to GND, through Q8 NPN, which is driven from the board to board connector, by some kind of power ready signal. When the power drops the green LED next to the flash making a short flash. Disconnecting the 2.5V power disable signal and forcing 2.5V always on did not help, it made the JTAG inoperable.

Hmm, interesting. The device I'm working with is a Rev A, so maybe it behaves differently in this regard… I'll have to see if I can get my hands on a later revision and get it wired up.

I have a Rev C-05...

FYI: I've been able to flash both a rev A(B?) and a rev C device successfully using the original Pano updater utility over Ethernet.  See https://github.com/skiphansen/pano_progfpga.  Flash the multiboot image and leave the "golden" image in place and you'll be able to flash again by loading a bitstream via JTAG to run the golden image again.

I have successfully programmed the flash on a G2 rev C using a generic FTDI 2232H board which does not use the Vref line.  However, the FT2232H board will drive the JTAG lines at 3.3V level so there is a risk of damage to the FPGA but I have not seen any problems sofar.  One option is to add a small resistor (say 220 ohm) in series on the signals going to the FPGA, that will limit the current.
See [https://github.com/Saanlima/Pano_G2C/tree/master/fpgaprog] for more info.

I've tested xc3sprog on both revs and it works without problems with my diligent HS JTAG adapter. The problem with Impact is most like caused by pulling the "unused" outputs to ground, the xc3sprog bit file also had the same problem until it was changed to leave the unused outputs floating.
I've also has 100% success using Impact if I hold the Pano button while programming, but that is a pain.
Make targets and the needed bit files for xc3sprog are now included in Tom's repository.


Add ability to specify non-existent field for combobox

The reason for this PR that sometimes model can have json type fields with nested attributes and calling form.object.public_send(field_name) on it will fail. I used same check as rails do here
At the moment calling this fails
  <%= form.combobox '[existent_field][non_existent_field]' %>

Either a system or unit/integration test would be fine. I don't think we have tests for the main component. But we do have tests for the listbox option presenter. You can create tests based on that, if you wanted to test the component by itself.
Thanks!

Also, please rebase or merge main back in so we can get the changes from your other merged PR


Chanegs from master

Coverage increased (+1.07%) to 98.768% when pulling 74221ce97edbe2895b619384dda1b4305140b2ac on master into dc506157c12c1da7f2296c7504468f82a7dd0695 on revise.