Feature: Broadcast focus state

Hello!
I'm working with Lexical at the moment, and have a fully working editor all set up and working. However, I've had a request from my UX team to show a focus ring around the editor; this currently doesn't seem possible, as the editor does not broadcast focus/blur events.
The best I can manage at the moment is an outline around the editor "inner" using the :focus-within CSS selector, but this isn't as clean as we'd like:

Would something like a focus hook, or an editor.isFocused boolean be possible? Anything I could use to add/remove a class based on state would be ideal!

There are BLUR and FOCUS commands you can listen to which should give you what you need?

There are BLUR and FOCUS commands you can listen to which should give you what you need?

I thought they were commands that would action a blur or focus? i.e "I want to manually focus the editor, so I'll call editor.focus()". Have I misunderstood those?

Oh! I see you meant import { FOCUS_COMMAND, BLUR_COMMAND} from "lexical" - apologies, I didn't realise which commands you were referring to.
Those have worked a treat, thank you very much for the point in the right direction 👍

@trueadm the BLUR_COMMAND still triggers even when just using the toolbar options. Is there any way to ignore any toolbar clicks triggering the BLUR_COMMAND?

@mattvb91 If you look at the event target or relatedTarget and seeing if that gives you any signal to help you?

@mattvb91 If you look at the event target or relatedTarget and seeing if that gives you any signal to help you?

spot on! Thank you, appreciated


[INTERNAL][FIX] MessageManager sample: load fragment from correct path

Hello @nzamani,
Thank you for your pull request. I've created an internal record<PHONE_NUMBER> . The status of the issue will be updated here in GitHub.
Regards, Diana

Hi @nzamani,
your pull request has been merged.
Thanks and best regards,
Tommy


expose port 50052 (readonly-grpc)

@eliezio What is the intention in exposing this port? Readonly mode is only available in serve-testing mode, which the operator doesn't run

@eliezio What is the intention in exposing this port? Readonly mode is only available in serve-testing mode, which the operator doesn't run

you're right. I misunderstood the --readonly-grpc-addr flag only applies to serve-testing mode. Canceling this MR...


Failed to start device "X0"

Required information

Distribution: Ubuntu
Distribution version: 20.04
The output of "lxc info" or if that fails:

config:
  images.auto_update_interval: "1"
api_extensions:
- storage_zfs_remove_snapshots
- container_host_shutdown_timeout
- container_stop_priority
- container_syscall_filtering
- auth_pki
- container_last_used_at
- etag
- patch
- usb_devices
- https_allowed_credentials
- image_compression_algorithm
- directory_manipulation
- container_cpu_time
- storage_zfs_use_refquota
- storage_lvm_mount_options
- network
- profile_usedby
- container_push
- container_exec_recording
- certificate_update
- container_exec_signal_handling
- gpu_devices
- container_image_properties
- migration_progress
- id_map
- network_firewall_filtering
- network_routes
- storage
- file_delete
- file_append
- network_dhcp_expiry
- storage_lvm_vg_rename
- storage_lvm_thinpool_rename
- network_vlan
- image_create_aliases
- container_stateless_copy
- container_only_migration
- storage_zfs_clone_copy
- unix_device_rename
- storage_lvm_use_thinpool
- storage_rsync_bwlimit
- network_vxlan_interface
- storage_btrfs_mount_options
- entity_description
- image_force_refresh
- storage_lvm_lv_resizing
- id_map_base
- file_symlinks
- container_push_target
- network_vlan_physical
- storage_images_delete
- container_edit_metadata
- container_snapshot_stateful_migration
- storage_driver_ceph
- storage_ceph_user_name
- resource_limits
- storage_volatile_initial_source
- storage_ceph_force_osd_reuse
- storage_block_filesystem_btrfs
- resources
- kernel_limits
- storage_api_volume_rename
- macaroon_authentication
- network_sriov
- console
- restrict_devlxd
- migration_pre_copy
- infiniband
- maas_network
- devlxd_events
- proxy
- network_dhcp_gateway
- file_get_symlink
- network_leases
- unix_device_hotplug
- storage_api_local_volume_handling
- operation_description
- clustering
- event_lifecycle
- storage_api_remote_volume_handling
- nvidia_runtime
- container_mount_propagation
- container_backup
- devlxd_images
- container_local_cross_pool_handling
- proxy_unix
- proxy_udp
- clustering_join
- proxy_tcp_udp_multi_port_handling
- network_state
- proxy_unix_dac_properties
- container_protection_delete
- unix_priv_drop
- pprof_http
- proxy_haproxy_protocol
- network_hwaddr
- proxy_nat
- network_nat_order
- container_full
- candid_authentication
- backup_compression
- candid_config
- nvidia_runtime_config
- storage_api_volume_snapshots
- storage_unmapped
- projects
- candid_config_key
- network_vxlan_ttl
- container_incremental_copy
- usb_optional_vendorid
- snapshot_scheduling
- snapshot_schedule_aliases
- container_copy_project
- clustering_server_address
- clustering_image_replication
- container_protection_shift
- snapshot_expiry
- container_backup_override_pool
- snapshot_expiry_creation
- network_leases_location
- resources_cpu_socket
- resources_gpu
- resources_numa
- kernel_features
- id_map_current
- event_location
- storage_api_remote_volume_snapshots
- network_nat_address
- container_nic_routes
- rbac
- cluster_internal_copy
- seccomp_notify
- lxc_features
- container_nic_ipvlan
- network_vlan_sriov
- storage_cephfs
- container_nic_ipfilter
- resources_v2
- container_exec_user_group_cwd
- container_syscall_intercept
- container_disk_shift
- storage_shifted
- resources_infiniband
- daemon_storage
- instances
- image_types
- resources_disk_sata
- clustering_roles
- images_expiry
- resources_network_firmware
- backup_compression_algorithm
- ceph_data_pool_name
- container_syscall_intercept_mount
- compression_squashfs
- container_raw_mount
- container_nic_routed
- container_syscall_intercept_mount_fuse
- container_disk_ceph
- virtual-machines
- image_profiles
- clustering_architecture
- resources_disk_id
- storage_lvm_stripes
- vm_boot_priority
- unix_hotplug_devices
- api_filtering
- instance_nic_network
- clustering_sizing
- firewall_driver
- projects_limits
- container_syscall_intercept_hugetlbfs
- limits_hugepages
- container_nic_routed_gateway
- projects_restrictions
- custom_volume_snapshot_expiry
- volume_snapshot_scheduling
- trust_ca_certificates
- snapshot_disk_usage
- clustering_edit_roles
- container_nic_routed_host_address
- container_nic_ipvlan_gateway
- resources_usb_pci
- resources_cpu_threads_numa
- resources_cpu_core_die
- api_os
- container_nic_routed_host_table
- container_nic_ipvlan_host_table
- container_nic_ipvlan_mode
- resources_system
- images_push_relay
- network_dns_search
- container_nic_routed_limits
- instance_nic_bridged_vlan
- network_state_bond_bridge
- usedby_consistency
- custom_block_volumes
- clustering_failure_domains
- resources_gpu_mdev
- console_vga_type
- projects_limits_disk
- network_type_macvlan
- network_type_sriov
- container_syscall_intercept_bpf_devices
- network_type_ovn
- projects_networks
- projects_networks_restricted_uplinks
- custom_volume_backup
- backup_override_name
- storage_rsync_compression
- network_type_physical
- network_ovn_external_subnets
- network_ovn_nat
- network_ovn_external_routes_remove
- tpm_device_type
- storage_zfs_clone_copy_rebase
- gpu_mdev
- resources_pci_iommu
- resources_network_usb
- resources_disk_address
- network_physical_ovn_ingress_mode
- network_ovn_dhcp
- network_physical_routes_anycast
- projects_limits_instances
- network_state_vlan
- instance_nic_bridged_port_isolation
- instance_bulk_state_change
- network_gvrp
- instance_pool_move
- gpu_sriov
- pci_device_type
- storage_volume_state
- network_acl
- migration_stateful
- disk_state_quota
- storage_ceph_features
- projects_compression
- projects_images_remote_cache_expiry
- certificate_project
- network_ovn_acl
- projects_images_auto_update
- projects_restricted_cluster_target
- images_default_architecture
- network_ovn_acl_defaults
- gpu_mig
- project_usage
- network_bridge_acl
- warnings
- projects_restricted_backups_and_snapshots
- clustering_join_token
- clustering_description
- server_trusted_proxy
- clustering_update_cert
- storage_api_project
- server_instance_driver_operational
- server_supported_storage_drivers
- event_lifecycle_requestor_address
- resources_gpu_usb
- clustering_evacuation
- network_ovn_nat_address
- network_bgp
- network_forward
- custom_volume_refresh
- network_counters_errors_dropped
- metrics
- image_source_project
- clustering_config
- network_peer
- linux_sysctl
- network_dns
- ovn_nic_acceleration
- certificate_self_renewal
- instance_project_move
- storage_volume_project_move
- cloud_init
- network_dns_nat
- database_leader
- instance_all_projects
- clustering_groups
- ceph_rbd_du
api_status: stable
api_version: "1.0"
auth: trusted
public: false
auth_methods:
- tls
environment:
  addresses: []
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
    MIICGDCCAZ+gAwIBAgIRAIG0NsaRld9U4RCr/jM92EEwCgYIKoZIzj0EAwMwOzEc
    MBoGA1UEChMTbGludXhjb250YWluZXJzLm9yZzEbMBkGA1UEAwwScm9vdEBycm91
    d3BybGMwMDExMB4XDTIxMDMyMzA5NDc1NloXDTMxMDMyMTA5NDc1NlowOzEcMBoG
    A1UEChMTbGludXhjb250YWluZXJzLm9yZzEbMBkGA1UEAwwScm9vdEBycm91d3By
    bGMwMDExMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEe42kRWP6nNpKTAcQSelThK4x
    B9Kp8Cj1wnCBQ3jpzH27e+BoyFOvtnhM18SAzNjMVKA/Z6xy5vJpOd6rrBTFElPN
    XG3BS2DDrc5+t7vFUWJO+rf5arXBJEN/d0BJKDYXo2cwZTAOBgNVHQ8BAf8EBAMC
    BaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAwBgNVHREEKTAn
    gg1ycm91d3BybGMwMDExhwR/AAABhxAAAAAAAAAAAAAAAAAAAAABMAoGCCqGSM49
    BAMDA2cAMGQCMEmZCS6ki7UR46H2bKxLrxq6+xfNCZ9WjEJYTbaUyNa7W7xMUaBx
    6FirTubYAyffhQIwFRTsFLnyCh0Hc7A5qMMSMgQaoVCNFt0IlohMu3nTPzYfggXO
    HRXSGTnrBIo17eWf
    -----END CERTIFICATE-----
  certificate_fingerprint: b742be0f073a13465cada3a4ab3092b43a2db8900c4bb6198ede906a21601c61
  driver: lxc | qemu
  driver_version: 4.0.11 | 6.1.0
  firewall: xtables
  kernel: Linux
  kernel_architecture: x86_64
  kernel_features:
    netnsid_getifaddrs: "true"
    seccomp_listener: "true"
    seccomp_listener_continue: "true"
    shiftfs: "false"
    uevent_injection: "true"
    unpriv_fscaps: "true"
  kernel_version: 5.10.0-1052-oem
  lxc_features:
    cgroup2: "true"
    core_scheduling: "true"
    devpts_fd: "true"
    idmapped_mounts_v2: "true"
    mount_injection_file: "true"
    network_gateway_device_route: "true"
    network_ipvlan: "true"
    network_l2proxy: "true"
    network_phys_macvlan_mtu: "true"
    network_veth_router: "true"
    pidfd: "true"
    seccomp_allow_deny_syntax: "true"
    seccomp_notify: "true"
    seccomp_proxy_send_notify_fd: "true"
  os_name: Ubuntu
  os_version: "20.04"
  project: default
  server: lxd
  server_clustered: false
  server_name: rrouwprlc0011
  server_pid: 251159
  server_version: "4.21"
  storage: zfs
  storage_version: 2.0.2-1ubuntu5
  storage_supported_drivers:
  - name: ceph
    version: 15.2.14
    remote: true
  - name: btrfs
    version: 5.4.1
    remote: false
  - name: cephfs
    version: 15.2.14
    remote: true
  - name: dir
    version: "1"
    remote: false
  - name: lvm
    version: 2.03.07(2) (2019-11-30) / 1.02.167 (2019-11-30) / 4.43.0
    remote: false
  - name: zfs
    version: 2.0.2-1ubuntu5
    remote: false

Issue description
To start GUI applications in lxd containers we mount the /tmp/.X11-unix/X0 file to the container:
lxc launch ubuntu:20.04 c1
lxc config device add c1 X disk path=/tmp/.X11-unix/X0 source=/tmp/.X11-unix/X0

However since version 4.21 this fails with the following error:
Error: Failed to start device "X": Failed opening source path "/var/lib/snapd/hostfs/tmp/.X11-unix/X0": open /var/lib/snapd/hostfs/tmp/.X11-unix/X0: no such device or address

This used to work in version 4.20 and is reproducible on multiple machines and also on ubuntu 18.04.
Looking at /var/lib/snapd/hostfs there are no files:
$ ll /var/lib/snapd/hostfs
total 0

Steps to reproduce
lxc launch ubuntu:20.04 c1
lxc config device add c1 X disk path=/tmp/.X11-unix/X0 source=/tmp/.X11-unix/X0

Information to attach

[ ] Any relevant kernel output (dmesg)
[ ] Container log (lxc info NAME --show-log)
[ ] Container configuration (lxc config show NAME --expanded)

architecture: x86_64
config:
  image.architecture: amd64
  image.description: ubuntu 20.04 LTS amd64 (release) (20211129)
  image.label: release
  image.os: ubuntu
  image.release: focal
  image.serial: "20211129"
  image.type: squashfs
  image.version: "20.04"
  volatile.base_image: a8402324842148ccfcbacbc69bf251baa9703916593089f0609e8d45e3185bff
  volatile.eth0.host_name: veth48e111e9
  volatile.eth0.hwaddr: 00:16:3e:1f:d3:9d
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.power: RUNNING
  volatile.uuid: a970d8cd-af00-494b-997b-098bb5a669b4
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

[ ] Main daemon log (at /var/log/lxd/lxd.log or /var/snap/lxd/common/lxd/logs/lxd.log)
[ ] Output of the client with --debug
[ ] Output of the daemon with --debug (alternatively output of lxc monitor while reproducing the issue)

location: none
metadata:
  context:
    ip: '@'
    method: GET
    protocol: unix
    url: /1.0
    username: uid=83265
  level: dbug
  message: Handling API request
timestamp: "2021-12-15T13:18:42.049008537+01:00"
type: logging

location: none
metadata:
  context:
    ip: '@'
    method: GET
    protocol: unix
    url: /1.0/instances/c1
    username: uid=83265
  level: dbug
  message: Handling API request
timestamp: "2021-12-15T13:18:42.05083918+01:00"
type: logging

location: none
metadata:
  context:
    ip: '@'
    method: GET
    protocol: unix
    url: /1.0/events
    username: uid=83265
  level: dbug
  message: Handling API request
timestamp: "2021-12-15T13:18:42.053949587+01:00"
type: logging

location: none
metadata:
  context: {}
  level: dbug
  message: 'New event listener: 833c9c95-9d40-415f-85d5-1a48842870f7'
timestamp: "2021-12-15T13:18:42.054109059+01:00"
type: logging

location: none
metadata:
  context:
    ip: '@'
    method: PUT
    protocol: unix
    url: /1.0/instances/c1
    username: uid=83265
  level: dbug
  message: Handling API request
timestamp: "2021-12-15T13:18:42.054470167+01:00"
type: logging

location: none
metadata:
  context: {}
  level: dbug
  message: 'New task Operation: 779c91ef-ba16-4c2b-ad76-b16658d92e34'
timestamp: "2021-12-15T13:18:42.078390893+01:00"
type: logging

location: none
metadata:
  class: task
  created_at: "2021-12-15T13:18:42.056932954+01:00"
  description: Updating instance
  err: ""
  id: 779c91ef-ba16-4c2b-ad76-b16658d92e34
  location: none
  may_cancel: false
  metadata: null
  resources:
    containers:
    - /1.0/containers/c1
    instances:
    - /1.0/instances/c1
  status: Pending
  status_code: 105
  updated_at: "2021-12-15T13:18:42.056932954+01:00"
timestamp: "2021-12-15T13:18:42.078733274+01:00"
type: operation

location: none
metadata:
  context: {}
  level: dbug
  message: 'Started task operation: 779c91ef-ba16-4c2b-ad76-b16658d92e34'
timestamp: "2021-12-15T13:18:42.078763911+01:00"
type: logging

location: none
metadata:
  class: task
  created_at: "2021-12-15T13:18:42.056932954+01:00"
  description: Updating instance
  err: ""
  id: 779c91ef-ba16-4c2b-ad76-b16658d92e34
  location: none
  may_cancel: false
  metadata: null
  resources:
    containers:
    - /1.0/containers/c1
    instances:
    - /1.0/instances/c1
  status: Running
  status_code: 103
  updated_at: "2021-12-15T13:18:42.056932954+01:00"
timestamp: "2021-12-15T13:18:42.079033967+01:00"
type: operation

location: none
metadata:
  context:
    ip: '@'
    method: GET
    protocol: unix
    url: /1.0/operations/779c91ef-ba16-4c2b-ad76-b16658d92e34
    username: uid=83265
  level: dbug
  message: Handling API request
timestamp: "2021-12-15T13:18:42.080953858+01:00"
type: logging

location: none
metadata:
  context:
    device: X
    instance: c1
    instanceType: container
    project: default
    type: disk
  level: dbug
  message: Starting device
timestamp: "2021-12-15T13:18:42.083946467+01:00"
type: logging

location: none
metadata:
  context: {}
  level: dbug
  message: 'Failure for task operation: 779c91ef-ba16-4c2b-ad76-b16658d92e34: Failed
    to start device "X": Failed opening source path "/var/lib/snapd/hostfs/tmp/.X11-unix/X0":
    open /var/lib/snapd/hostfs/tmp/.X11-unix/X0: no such device or address'
timestamp: "2021-12-15T13:18:42.084309262+01:00"
type: logging

location: none
metadata:
  context: {}
  level: dbug
  message: 'Scheduler: container c1 changed: re-balancing'
timestamp: "2021-12-15T13:18:42.084382046+01:00"
type: logging

location: none
metadata:
  class: task
  created_at: "2021-12-15T13:18:42.056932954+01:00"
  description: Updating instance
  err: 'Failed to start device "X": Failed opening source path "/var/lib/snapd/hostfs/tmp/.X11-unix/X0":
    open /var/lib/snapd/hostfs/tmp/.X11-unix/X0: no such device or address'
  id: 779c91ef-ba16-4c2b-ad76-b16658d92e34
  location: none
  may_cancel: false
  metadata: null
  resources:
    containers:
    - /1.0/containers/c1
    instances:
    - /1.0/instances/c1
  status: Failure
  status_code: 400
  updated_at: "2021-12-15T13:18:42.056932954+01:00"
timestamp: "2021-12-15T13:18:42.084523603+01:00"
type: operation

location: none
metadata:
  context: {}
  level: dbug
  message: 'Event listener finished: 833c9c95-9d40-415f-85d5-1a48842870f7'
timestamp: "2021-12-15T13:18:42.086136733+01:00"
type: logging

location: none
metadata:
  context:
    listener: 833c9c95-9d40-415f-85d5-1a48842870f7
  level: dbug
  message: Disconnected event listener
timestamp: "2021-12-15T13:18:42.086111062+01:00"
type: logging

Can you show output of:
sudo nsenter --mount=/run/snapd/ns/lxd.mnt -- ls -la /var/lib/snapd/hostfs/tmp/.X11-unix/X0

And
ls -la /tmp/.X11-unix/X0

$ sudo nsenter --mount=/run/snapd/ns/lxd.mnt -- ls -la /var/lib/snapd/hostfs/tmp/.X11-unix/X0
srwxrwxrwx 1 83265 users 0 Dec 14 09:07 /var/lib/snapd/hostfs/tmp/.X11-unix/X0

$ sudo ls -la /tmp/.X11-unix/X0
srwxrwxrwx 1 fassbinb users 0 Dec 14 09:07 /tmp/.X11-unix/X0

Does passing through /tmp/.X11-unix/ work?

Yeah that seems to work:
lxc config device add c1 X disk path=/tmp/.X11-unix/ source=/tmp/.X11-unix/
Device X added to c1

And is the file you wanted to pass accessible inside the container that way?
The error you are getting is from:
https://github.com/lxc/lxd/blob/master/lxd/device/disk.go#L1325-L1328
It is quite a basic function call using the Go stdlib, so its strange that LXD running inside the snap mount namespace cannot open it.

Well it was a few seconds ago:
root@c1:~# ls /tmp/.X11-unix/
X0  X1024  X1025

Thats strange ... ?

Okay it seems to not be an lxd problem after all:
sudo ls -la /tmp/.X11-unix/X0
ls: cannot access '/tmp/.X11-unix/X0': No such file or directory

Where was that run from?

So it seems to be coming and going on the host or just in the container?

It's from my host, so that's strange :thinking:

So after a fresh reboot the X0 file is there again in the host and contaienr and xeyes work again!

So mounting the folder seems a good workaround. Mounting the file directly still fails:
$ lxc launch ubuntu:20.04 c4
Creating c4
Starting c4
$ lxc config device add c4 X disk path=/tmp/.X11-unix/X0 source=/tmp/.X11-unix/X0
Error: Failed to start device "X": Failed opening source path "/var/lib/snapd/hostfs/tmp/.X11-unix/X0": open /var/lib/snapd/hostfs/tmp/.X11-unix/X0: no such device or address
$ lxc config device add c4 X disk path=/tmp/.X11-unix/ source=/tmp/.X11-unix/
Device X added to c4

@tomponline do you have any idea why this might behave differently than in 4.20?

Just reproduce the mounting of the /tmp/.X11-unix/ folder on all colleagues' workstation, and the behaviour is the same, after lxc config device add ... the directory is empty.

It's from my host, so that's strange thinking

Yeah if the file is coming and going that is going to be a problem.

Any ideas @stgraber ?

@tomponline sounds like the issue here is with our changes to the bind mount logic and the source file being a socket.
You can't open() a socket the normal way. You may be able to open it enough with O_PATH though.
@tomponline should be reproducible by creating a socket with nc -U -l and attempting to pass that in.

@stgraber ah OK so the socket is the difference, will test it.

Yep that got it:
nc -U -l /home/user/foo.soc
lxc config device add ovndb foo disk source=/home/user/foo.sock path=/root/foo.sock
Error: Failed to start device "foo": Failed opening source path "/home/user/foo.sock": open /home/user/foo.sock: no such device or address

thanks @stgraber O_PATH works well, and I was able to remove the O_READONLY as its not needed for directories when opening with O_PATH (and is ignored anyway from what I read).
Testing on VMs now to check no regression there.

VM disk tests seem fine with this.

How to install this fix asap?  Reverting to 4.20 does not work as the database format has changed and edge does not feature it yet.

Its been merged so should be in the edge snap channel soon.


Concerto vNext Proposals

Feature Request 🛍
These are ideas, open for discussion.
1. Faceted Primitive Types #433 - 3.x
typedef SSN = String regex=/\d+/

concept Person {
  o SSN ssn
}

References:

https://www.w3schools.com/xml/schema_facets.asp
https://docstore.mik.ua/orelly/xml/schema/ch05_01.htm

2. Reimplement in Typescript #406 - 4.x (or possibly 3.x if we don't use mm classes)
Generate TS code from the metamodel (bootstrap) and then code the implementation against the generated code, ensuring consistency.
3. Cleaner / Simpler Functional APIs
Better separation between serialisation, introspection, validation - for example.
4. Final Types #482 - (3.x)
The $class is required in serialised instances because concepts can be extended. We could support the addition of a final keyword which would indicate that a concept could not be extended, meaning that the type of an object can be inferred by introspecting the model.
4. Numeric type enhancements #189 - (4.x)
Ensure full support integer and long numeric types in the JavaScript library, perhaps by using the built-in big integer support in JavaScript. Also, should we introduce a new decimal type to handle monetary amounts?
5. Optional vs required property handling consistency
Martin to provide further details.
6. Decorators v2 #391 - (4.x)
Introduce well defined, modelled decorators: https://github.com/accordproject/concerto/issues/391
7. Import Aliasing #480 - (3.x?)
Allow models to alias imports to deal with name collisions.
8. Improved TypeScript generation #449 - (3.x - new target?)
This generator would generate TypeScript interfaces that describe the JSON structure of the data, and TypeScript classes that can be used to parse, validate and serialize instances with the expected types.
9. Record Types (Dictionary / Maps) #447 - (4.x)
Allow modellers to define record types aka maps or dictionaries.

Closing. Each of the issues are tracked separately and managed in the Roadmap.
https://github.com/orgs/accordproject/projects/15/views/1


github.com%2Fgogo/protobuf/v1.2.0

Type: Incorrect
Summary:
github.com%2Fgogo/protobuf/v1.2.0
Details:
Add BSD-3-Clause
Resolution:
https://github.com/gogo/protobuf/blob/v1.2.0/LICENSE
Affected definitions:

protobuf v1.2.0

Already Declared as BSD-3-Clause. Closing.


page for modal_remove does not actually show how to use the function

on the page: https://shiny.posit.co/py/api/core/ui.modal_remove.html
the function ui.modal_remove() is never actually used on this page, even though the purpose of the example code is to show how it's being used.

Thanks for the reminder @athenadeng! I had made a note of this in a shiny issue, but I think I was distracted by other aspects of that issue and adding the example to the docs fell off my radar.


fix(jsx): boolean attribute

Description
fix https://github.com/BuilderIO/mitosis/issues/732

I'm adding a snapshot because the preview deployment didn't show it fixed

snaps show it works and even in the preview now


Update joi to 6.4.2

Coverage remained the same at 100.0% when pulling f28e9fb0e59da6b3cb7aa281b87f28191c0daaaa on chore/update-joi into 5575aafcc8d4be6093fe71b5adb9215fcfce6a84 on master.


[service bus] Sample for getting message count / dead letter count

Is your feature request related to a problem? Please describe.
I want to be able to get the Active Message 'Count' waiting to be read, or Dead Letter queue 'count' from ASB.
Describe the solution you'd like
I was hoping to see some sample code in your git repo. Would appreciate if there is such an example.  ( preferably in JS/Node )
Thanks
Describe alternatives you've considered
Still searching. ....
Additional context
none.

Closing this issue in favor of #8195 where we will address the question put forward here


Median of Two Sorted Arrays

Description
Given two sorted arrays nums1 and nums2 of size m and n respectively, return the median of the two sorted arrays.
The overall run time complexity should be O(log (m+n)).
DSA Problem
https://leetcode.com/problems/median-of-two-sorted-arrays/description/

Please assign this issue to me


Add named arguments along with a function to bind to the named args

@RangelReale
This is very similar to #104, but with a few differences:

bob.BindNamed now produces the final query. Merging two steps into one.
The args do not have to be a struct. The type can either be:

A struct with fields that match the named arguments in the query
A map with string keys. When supplied, the values in the map will be used to bind the named arguments in the query.
When there is only a single named argument, one of the following can be used:

A primitive type (int, bool, string, etc)
time.Time
Any type that implements driver.Valuer.

package main

import (
	"context"
	"fmt"

	_ "github.com/jackc/pgx/v5/stdlib"
	"github.com/stephenafamo/bob"
	"github.com/stephenafamo/bob/dialect/psql"
	"github.com/stephenafamo/bob/dialect/psql/sm"
)

type Args struct {
	In1 int
	In2 int
	In3 int
	Id1 int
}

func main() {
	ctx := context.Background()

	query := psql.Select(
		sm.Columns("id", "name"),
		sm.From("users"),
		sm.Where(psql.Quote("id").In(bob.Named("in1", "in2", "in3"))),
		sm.Where(psql.Raw("id >= ?", bob.Named("id1"))),
	)

	// Use as a regular query
	{
		bound := bob.BindNamed(ctx, query, Args{
			In1: 1,
			In2: 2,
			In3: 3,
			Id1: 4,
		})

		// bound is a [Query] and can be used like any other query

		queryStr, args, err := bob.Build(ctx, bound)
		if err != nil {
			panic(err)
		}

		fmt.Println(queryStr)
		fmt.Println(args)
	}

	// Use in prepared statements
	{
		ctx := context.Background()
		db, err := bob.Open("pgx", "postgresql://user:pass@localhost/bob_droppable?sslmode=disable")

		stmt, err := bob.Prepare[Args](ctx, db, query)
		if err != nil {
			panic(err)
		}

		_ = stmt
	}
}


FileNotFoundError: [Errno 2] No such file or directory: 'useragent_windows.dat'

There is no useragent_windows.dat on my Windows 10 pc, so the program fails from the get-go. Please provide details on the file, where it should be located, and how to obtain or create it.
When the program is resolving this my local conda site-packages environment is expected to contain it.

go to source code, and change useragent_windows.dat to useragents_windows.dat

There are no instances of useragent_windows.dat - all mentions include the 's'


Update Coveralls integration and badges

Old: https://coveralls.io/github/ntwb/eslint-plugin-wordpress/
New: https://coveralls.io/github/WordPress-Coding-Standards/eslint-plugin-wordpress

Coveralls fails to throw an error on a failed upload /shrug
Via https://travis-ci.org/WordPress-Coding-Standards/eslint-plugin-wordpress/jobs/251409045#L1379
$ npm run coveralls
><EMAIL_ADDRESS>coveralls /home/travis/build/WordPress-Coding-Standards/eslint-plugin-wordpress
> nyc report --reporter=text-lcov | coveralls
/home/travis/build/WordPress-Coding-Standards/eslint-plugin-wordpress/node_modules/coveralls/bin/coveralls.js:18
        throw err;
        ^
Bad response: 422 {"message":"Couldn't find a repository matching this job.","error":true}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>coveralls: `nyc report --reporter=text-lcov | coveralls`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>coveralls script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR!  Your build exited with 0.

The repo has now been re-sync'd at Coveralls:
https://coveralls.io/github/WordPress-Coding-Standards/eslint-plugin-wordpress


ExpressionParser and directives

Writing a small directive, I came across something that I don't know if can be simplify, this is my scenario:
Implemented like: as-test="{something:1}". Works fine, but i found that this directive was going to be very simple most of the time.
When I tried as-test="1" I coudn't get the parameter data. More or less the way it was done before edge.
So, basically two things:

Is this incorrect?  as-test="1"
When checking some other simple parameter values i found that if I pass  as-test="#"` I get:

Cannot read property 't' of undefined.

Reproduced like this:  flattenExpression(  new ExpressionParser( ("[#]") ).result[0] )
This one on the other side works fine: flattenExpression(  new ExpressionParser( ("[1]") ).result[0] )
Version 0.8.1
Method: processDirective
Line: 63357 and 63358.
Extra data: right after "TODO clean this up, it's shocking" xD
Cheers

Yep that's correct. The second arg to the decorator function will be 1: https://jsfiddle.net/kq6xyct1/
This is improved in the upcoming 0.9 release that's currently in alpha. Basically, in 0.8 the whole attribute is read, wrapped in [ ]s, and fed to an expression parser manually. With 0.9, the main parser knows that as-test is a directive and starts parsing an expression directly, so you get a better error message: https://jsfiddle.net/ge01xktg/1/

Extra data: right after "TODO clean this up, it's shocking" xD

...yeah. :laughing:

Sorry, I should have closed this!


Artemis 726

The overrided injectMonitor method should still call monitor.addStore(largeMessagesFactory.getDirectory()); as large messages are handled the same way than in https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/JournalStorageManager.java#L736


cargo-kani self-test

We currently run a few smoke tests in CI on various platforms to check whether things behave correctly. We should capture this into a behavior that can be run with one simple command.
This will simplify CI (just run self-test) and let customers run a quick self-test on their own local install, to validate everything seems installed and working correctly.

We run some ad-hoc smoke tests that could become the self-test procedure here:
https://github.com/model-checking/kani/blob/main/.github/workflows/kani.yml#L126

The idempotency one wouldn't be part of self-test.
We should add tests for the kani binary, too.


Build errors with gcc 4.9.2

I'm using Qt creator suite for windows standard build with mingw gcc 4.9.2 (from developer site).
When I try to build your cmake, or include Steams.h to my own project I getting following errors (same from your cmake, and my project):

gcc 4.9.2 support c++14 standard.

See #12 I believe it solves that exact problem


selectpicker show method not working

I'm trying to show and fill the search programmatically, but the selectpicker('show') and selectpicker('toggle') methods aren't working. Is there a different way of going about this with ajax search enabled?

Never mind, I had forgot to stopPropagation, so the clicking was closing the dropdown. 🤦♂


Change another vocoder

Hey, I have been running the Parallel WaveGAN on my own dataset and it's really wonderful. But at the same time I want to try another advanced vocoder such as melgan.v1.yaml, could you tell me how to use it? Thanks a lot!

@YangHan-Morningstar you can see usage examples here
https://colab.research.google.com/github/espnet/notebook/blob/master/tts_realtime_demo.ipynb

You can refer the config files in ljspeech recipe.
https://github.com/kan-bayashi/ParallelWaveGAN/tree/master/egs/ljspeech/voc1/conf
You can copy it and modify some parameters (fs, hop_size, etc.) to match with your dataset.
Then you can specify it with --conf option.
e.g. run.sh --stage 2 --conf conf/<your_modified_config>.yaml

OK, I'll trying this, thanks a lot!

@YangHan-Morningstar you can see usage examples here
https://colab.research.google.com/github/espnet/notebook/blob/master/tts_realtime_demo.ipynb

I have run this in my gpu successful but thisParallel WaveGAN Project used by sh file and I'm confused about it but the author just told me how to do it and I'm trying the method. Thanks god, it works!

You can refer the config files in ljspeech recipe.
https://github.com/kan-bayashi/ParallelWaveGAN/tree/master/egs/ljspeech/voc1/
(You can see brief introduction of the config in each header.)
You can copy it and modify some parameters (fs, hop_size, etc.) to match with your dataset.
Then you can specify it with --conf option.
e.g. run.sh --stage 2 --conf conf/<your_modified_config>.yaml

I have run it successfully in my gpu, Thanks!


Direct PCIe and CNVio2 access

Is your feature request related to a problem? Please describe
I'd like direct Bluetooth and Wifi Functionality like they have on chromebooks. this allows me to control devices over bluetooth and wifi easily.
Describe the solution you'd like
Direct PCIe and CNVio2 access in that way is Direct Bluetooth and wifi functionality possible
Describe alternatives you've considered
Chromebooks are a really good example of how this should work.
Please specify the version of Windows Subsystem for Android
2311.40000.5.0

#423


Migrate to batch/v1

batch/v1beta1 is no longer available as of Kubernetes 1.25.
This updates the CronJobs to batch/v1 API version that has been available since Kubernetes 1.21

Can this be merged? It is blocking me.

This can be done dynamically with
{{- if semverCompare ">=1.25-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: batch/v1
{{- else -}}
apiVersion: batch/v1beta1
{{- end }}

This can be done dynamically with
{{- if semverCompare ">=1.25-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: batch/v1
{{- else -}}
apiVersion: batch/v1beta1
{{- end }}

I didn't worry about making it retro-compatible since:

batch/v1 has been available for a while (Kubernetes 1.21 from Apr 2021)
The last Kubernetes version with support for batch/v1beta1 is 1.24 which is already EoL in both upstream Kubernetes and major cloud providers.

Ping @kapilt

Hello, any reason why this is not merged yet please ?

Curious if this will ever get merged or if I'm better off forking this repo

Please merge asap!

@castrojo @thisisshi @ajkerrigan


libSquoosh declares a global navigator variable

Before you start
Please take a look at the FAQ as well as the already opened issues! If nothing fits your problem, go ahead and fill out the following template:
Describe the bug
A clear and concise description of what the bug is.
import "@squoosh/lib" add a global navigator variable in codecs.ts. The issue is that some libraries assume the code is running is a web browser environment if there's a navigator object available on the global object.
To Reproduce
Steps to reproduce the behavior:
mkdir repro
cd repro
npm i sass @squoosh/lib
echo 'import "@squoosh/lib"; import "sass";' > test.mjs
node ./test.mjs

Expected behavior
A clear and concise description of what you expected to happen.
test.mjs should exit with code 0.
Actual behavior
…/repro/node_modules/sass/sass.dart.js:92529
    if (ua.indexOf("DumpRenderTree") >= 0) return hooks;
           ^

TypeError: Cannot read properties of undefined (reading 'indexOf')
    at …/repro/node_modules/sass/sass.dart.js:92529:12
    at Object.applyHooksTransformer (…/repro/node_modules/sass/sass.dart.js:7236:14)
    at Object.initHooks (…/repro/node_modules/sass/sass.dart.js:7216:251)
    at Object.initNativeDispatchContinue (…/repro/node_modules/sass/sass.dart.js:7182:9)
    at Object.initNativeDispatch (…/repro/node_modules/sass/sass.dart.js:7176:9)
    at Object.getNativeInterceptor (…/repro/node_modules/sass/sass.dart.js:9070:13)
    at Object.getInterceptor$x (…/repro/node_modules/sass/sass.dart.js:9326:16)
    at Object.set$render$x (…/repro/node_modules/sass/sass.dart.js:9363:16)
    at main0 (…/repro/node_modules/sass/sass.dart.js:17757:9)
    at …/repro/node_modules/sass/sass.dart.js:93924:7

Version:

OS w/ version: [e.g. iOS 12] N/A
Browser w/ version [e.g. Chrome 70] N/A
Node version: [e.g. 10.11.0] 16.9.1
npm version: [e.g. 6.4.1] 7.21.1

Additional context, screenshots, screencasts
Add any other context about the problem here.
It seems that Emscripten allows us to use anything for the pool size, so I suggest using something like globalThis[Symbol.for('squoosh.navigator')].hardwareConcurrency instead. I could also open a bug on the Sass issue tracker, but I don't think Sass is the only library that check for globalThis.navigator to make assumptions, and it'd be better to avoid it IMHO.

I'm not sure I understand the issue; in which circumstances the navigator is not defined?

The problem is that we set PTHREAD_POOL_SIZE to use a variable name that accidentally has a meaning in a different context (in this case web). However,PTHREAD_POOL_SIZE can take any string, so we could have chosen PTHREAD_POOL_SIZE=foo.bar and that would have worked as well. The solution then is to use a symbol to ensure uniqueness, which we can then refer to in JavaScript.

so we could have chosen PTHREAD_POOL_SIZE=foo.bar

Yeah but then we need to set that to number of CPUs on both Web and Node.
I can see how polyfilling navigator is bad for Node lib usecase though.
I have another suggestion: let's instead change it to
-s PTHREAD_POOL_SIZE='ENVIRONMENT_IS_NODE ? require("os").cpus().length : navigator.hardwareConcurrency'

This should work correctly in both Node and browser environments that we build for, and I've verified that the condition check is eliminated by Closure (which we use) when we set -s ENVIRONMENT=worker or -s ENVIRONMENT=node (which we do).
This seems like a simpler solution than setting a global symbol in each environment.

Yes that appears to work, thanks for the suggestion :+1: PR incoming to make that change :smile:

It seems that it can't be resolved temporarily. try:
await squoosh(...args);
delete globalThis.navigator;

Unfortunately, due to a few people leaving the team, and staffing issues resulting from the current economic climate (ugh), the CLI and libsquoosh packages are no longer actively maintained. I know that sucks, but there simply isn't the time & people to work on this. If anyone from the community wants to fork it, you have my blessing. The squoosh.app web app will continue to be supported and improved.


Errors: vector memory exhausted (limit reached?)

Brief problem description
My dataset appears to be too large for streamMetabolizer to run on my computer. I am estimating metabolism from the Columbia River.  Data set size is ~ 66,000 entries at 15 min intervals so about  690 days of metabolism, not too long.  It runs roughly overnight (24,000 seconds) and returns the following error (error 1-3 are about tidyverse deprecations).  It saves a small output file, but there are no mcmc samples in the file.
What you saw on your computer
4: In metab_fun(specs = specs, data = data, data_daily = data_daily,  :
Modeling failed
Warnings:
error in running command
There were 4 chains where the estimated Bayesian Fraction of Missing Information was low. See
http://mc-stan.org/misc/warnings.html#bfmi-low
Examine the pairs() plot to diagnose sampling problems  Errors:
vector memory exhausted (limit reached?)
This last error suggests a memory problem.  I am running a 2015 Macbook Pro with 16 GB memory.  Run is on 4 cores.  I am sampling 1000 warm up and 1000 saved steps.  When I run a file with about 1/10 of the days and 500 warm up and saved steps, it works fine, and I get the expected results.  That the small file works suggest that the data or model output is too big for my computer.  Thus there is no problem per se, rather this is a PSA that 700 days of metabolism and 100 steps might be too much for my laptop. Time to run on a cluster.
Include all code you ran (a minimal example) and all console output, errors, and warnings. Include a data file if needed.
load("CRall_sm.RData")  #load data fram ready to go for sM, Bob can supply if needed

cr_name <- mm_name(type='bayes', pool_K600='normal', err_obs_iid = T, err_proc_iid =T)
cr_specs <- specs(cr_name, K600_daily_meanlog_meanlog=1, K600_daily_meanlog_sdlog=0.75, K600_daily_sdlog_sigma=0.1, burnin_steps=1000,
                  saved_steps=1000)
CRall_fit <- metab(cr_specs, data=CRall_sm, info=c(site='Columbia, date/time correction', source='Bob Hall'))

Session information
Run the following code line (or sessionInfo() if that doesn't work) and paste in your output.
> devtools::session_info()

─ Session info ────────────────────────────────────────────────────────────────────────────
 setting  value
 version  R version 4.0.3 (2020-10-10)
 os       macOS Mojave 10.14.6
 system   x86_64, darwin17.0
 ui       RStudio
 language (EN)
 collate  en_US.UTF-8
 ctype    en_US.UTF-8
 tz       America/Denver
 date     2021-01-21

─ Packages ────────────────────────────────────────────────────────────────────────────────
 package           * version  date       lib source
 assertthat          0.2.1    2019-03-21 [1] CRAN (R 4.0.2)
 backports           1.1.10   2020-09-15 [1] CRAN (R 4.0.2)
 base64enc           0.1-3    2015-07-28 [1] CRAN (R 4.0.2)
 bayesplot           1.7.2    2020-05-28 [1] CRAN (R 4.0.2)
 callr               3.5.1    2020-10-13 [1] CRAN (R 4.0.2)
 cli                 2.1.0    2020-10-12 [1] CRAN (R 4.0.2)
 codetools           0.2-16   2018-12-24 [1] CRAN (R 4.0.3)
 colorspace          1.4-1    2019-03-18 [1] CRAN (R 4.0.2)
 colourpicker        1.1.0    2020-09-14 [1] CRAN (R 4.0.2)
 crayon              1.3.4    2017-09-16 [1] CRAN (R 4.0.2)
 crosstalk           <IP_ADDRESS>  2020-03-13 [1] CRAN (R 4.0.2)
 curl                4.3      2019-12-02 [1] CRAN (R 4.0.1)
 desc                1.2.0    2018-05-01 [1] CRAN (R 4.0.2)
 deSolve             1.28     2020-03-08 [1] CRAN (R 4.0.2)
 devtools            2.3.2    2020-09-18 [1] CRAN (R 4.0.2)
 digest              0.6.26   2020-10-17 [1] CRAN (R 4.0.2)
 dplyr             * 1.0.2    2020-08-18 [1] CRAN (R 4.0.2)
 DT                  0.16     2020-10-13 [1] CRAN (R 4.0.2)
 dygraphs            <IP_ADDRESS>  2018-07-11 [1] CRAN (R 4.0.2)
 ellipsis            0.3.1    2020-05-15 [1] CRAN (R 4.0.2)
 fansi               0.4.1    2020-01-08 [1] CRAN (R 4.0.2)
 farver              2.0.3    2020-01-16 [1] CRAN (R 4.0.2)
 fastmap             1.0.1    2019-10-08 [1] CRAN (R 4.0.2)
 fs                  1.5.0    2020-07-31 [1] CRAN (R 4.0.2)
 generics            0.1.0    2020-10-31 [1] CRAN (R 4.0.2)
 ggplot2           * 3.3.2    2020-06-19 [1] CRAN (R 4.0.2)
 ggridges            0.5.2    2020-01-12 [1] CRAN (R 4.0.2)
 glue                1.4.2    2020-08-27 [1] CRAN (R 4.0.2)
 gridExtra           2.3      2017-09-09 [1] CRAN (R 4.0.2)
 gtable              0.3.0    2019-03-25 [1] CRAN (R 4.0.2)
 gtools              3.8.2    2020-03-31 [1] CRAN (R 4.0.2)
 hms                 0.5.3    2020-01-08 [1] CRAN (R 4.0.2)
 htmltools           0.5.0    2020-06-16 [1] CRAN (R 4.0.2)
 htmlwidgets         1.5.2    2020-10-03 [1] CRAN (R 4.0.2)
 httpuv              1.5.4    2020-06-06 [1] CRAN (R 4.0.2)
 igraph              1.2.6    2020-10-06 [1] CRAN (R 4.0.2)
 inline              0.3.16   2020-09-06 [1] CRAN (R 4.0.2)
 jsonlite            1.7.1    2020-09-07 [1] CRAN (R 4.0.2)
 labeling            0.4.2    2020-10-20 [1] CRAN (R 4.0.3)
 LakeMetabolizer     1.5.0    2016-06-23 [1] CRAN (R 4.0.2)
 later               <IP_ADDRESS>  2020-06-05 [1] CRAN (R 4.0.2)
 lattice             0.20-41  2020-04-02 [1] CRAN (R 4.0.3)
 lazyeval            0.2.2    2019-03-15 [1] CRAN (R 4.0.2)
 lifecycle           0.2.0    2020-03-06 [1] CRAN (R 4.0.2)
 loo                 2.3.1    2020-07-14 [1] CRAN (R 4.0.2)
 lubridate         * <IP_ADDRESS>  2020-11-13 [1] CRAN (R 4.0.2)
 magrittr            1.5      2014-11-22 [1] CRAN (R 4.0.2)
 markdown            1.1      2019-08-07 [1] CRAN (R 4.0.2)
 matrixStats         0.57.0   2020-09-25 [1] CRAN (R 4.0.2)
 memoise             1.1.0    2017-04-21 [1] CRAN (R 4.0.2)
 mime                0.9      2020-02-04 [1] CRAN (R 4.0.2)
 miniUI              <IP_ADDRESS>  2018-05-18 [1] CRAN (R 4.0.2)
 munsell             0.5.0    2018-06-12 [1] CRAN (R 4.0.2)
 pillar              1.4.6    2020-07-10 [1] CRAN (R 4.0.2)
 pkgbuild            1.1.0    2020-07-13 [1] CRAN (R 4.0.2)
 pkgconfig           2.0.3    2019-09-22 [1] CRAN (R 4.0.2)
 pkgload             1.1.0    2020-05-29 [1] CRAN (R 4.0.2)
 plyr              * 1.8.6    2020-03-03 [1] CRAN (R 4.0.2)
 prettyunits         1.1.1    2020-01-24 [1] CRAN (R 4.0.2)
 processx            3.4.4    2020-09-03 [1] CRAN (R 4.0.2)
 promises            1.1.1    2020-06-09 [1] CRAN (R 4.0.2)
 ps                  1.4.0    2020-10-07 [1] CRAN (R 4.0.2)
 purrr               0.3.4    2020-04-17 [1] CRAN (R 4.0.2)
 R6                  2.4.1    2019-11-12 [1] CRAN (R 4.0.2)
 Rcpp                1.0.5    2020-07-06 [1] CRAN (R 4.0.2)
 RcppParallel        5.0.2    2020-06-24 [1] CRAN (R 4.0.2)
 readr             * 1.4.0    2020-10-05 [1] CRAN (R 4.0.2)
 remotes             2.2.0    2020-07-21 [1] CRAN (R 4.0.2)
 reshape2            1.4.4    2020-04-09 [1] CRAN (R 4.0.2)
 rLakeAnalyzer       <IP_ADDRESS> 2019-06-09 [1] CRAN (R 4.0.2)
 rlang               0.4.8    2020-10-08 [1] CRAN (R 4.0.2)
 rprojroot           1.3-2    2018-01-03 [1] CRAN (R 4.0.2)
 rsconnect           0.8.16   2019-12-13 [1] CRAN (R 4.0.2)
 rstan             * 2.21.3   2020-10-20 [1] Github (stan-dev/rstan@ae36e6f)
 rstudioapi          0.11     2020-02-07 [1] CRAN (R 4.0.2)
 scales              1.1.1    2020-05-11 [1] CRAN (R 4.0.2)
 sessioninfo         1.1.1    2018-11-05 [1] CRAN (R 4.0.2)
 shiny             * 1.5.0    2020-06-23 [1] CRAN (R 4.0.2)
 shinyjs             2.0.0    2020-09-09 [1] CRAN (R 4.0.2)
 shinystan         * 2.5.0    2018-05-01 [1] CRAN (R 4.0.2)
 shinythemes         1.1.2    2018-11-06 [1] CRAN (R 4.0.2)
 StanHeaders       * 2.21.0-6 2020-08-16 [1] CRAN (R 4.0.2)
 streamMetabolizer * 0.11.4   2020-10-22 [1] Github (USGS-R/streamMetabolizer@4a7ba9c)
 stringi             1.5.3    2020-09-09 [1] CRAN (R 4.0.2)
 stringr             1.4.0    2019-02-10 [1] CRAN (R 4.0.2)
 testthat            2.3.2    2020-03-02 [1] CRAN (R 4.0.2)
 threejs             0.3.3    2020-01-21 [1] CRAN (R 4.0.2)
 tibble              3.0.4    2020-10-12 [1] CRAN (R 4.0.2)
 tidyr             * 1.1.2    2020-08-27 [1] CRAN (R 4.0.2)
 tidyselect          1.1.0    2020-05-11 [1] CRAN (R 4.0.2)
 unitted             0.2.9    2020-10-22 [1] Github (appling/unitted@d1f1172)
 usethis             2.0.0    2020-12-10 [1] CRAN (R 4.0.2)
 V8                  3.2.0    2020-06-19 [1] CRAN (R 4.0.2)
 vctrs               0.3.4    2020-08-29 [1] CRAN (R 4.0.2)
 withr               2.3.0    2020-09-22 [1] CRAN (R 4.0.2)
 xfun                0.18     2020-09-29 [1] CRAN (R 4.0.2)
 xtable              1.8-4    2019-04-21 [1] CRAN (R 4.0.2)
 xts                 0.12.1   2020-09-09 [1] CRAN (R 4.0.2)
 yaml                2.2.1    2020-02-01 [1] CRAN (R 4.0.2)
 zoo                 1.8-8    2020-05-02 [1] CRAN (R 4.0.2)

I just ran into the same problem, I found a reference for the description and solution of this problem, but I haven't found the answer yet, I hope it will help you, if you find a solution, you can also share it, the original text is as follows:
Bayesian models require the rstan
interface to Stan. Sometimes this is as simple as
installing Rtools and calling the above install.packages or install_github command, but other
times everything seems fine until you try to run a Bayesian model in
streamMetabolizer. Symptoms of an imperfect rstan installation are probably
diverse. Here's one we've seen:
> bayes_fit <- metab(specs('bayes'), data=mydat)
Warning message:
In metab_fun(specs = specs, data = data, data_daily = data_daily,  :
  Modeling failed: argument is of length zero

> get_fit(bayes_fit)
...
$warnings
[1] "running command ''/Library/Frameworks/R.framework/Resources/bin/R' CMD config CXX 2>/dev/null' had status 1"

$errors
[1] "argument is of length zero"

In such cases you should refer to the detailed instructions on the rstan website for
Mac and Linux
or Windows.


Make course colors colorblind-safe

Changed courses colors as requested by @churichard. Fixes #265.
Chroma.js verifies this color palette as being colorblind-safe.

You'll have to change the color of the External Credits header as well. The relevant line is here: https://github.com/TigerPathApp/tigerpath/blob/145601e5f70c01b5a51eae69c0b3038254fec087/frontend/src/styles/theme.js#L2
Feel free to update it to have a more suitable name, like externalCreditsHeaderColor.

@churichard Pushed my new changes. I also made the color of the header text black because the default (white) was hard to read on the new header color.

The semester header usually has a color that is a slightly darker version of the course card color.
While the course cards have a lightness (the third element of the HSL value) of around 90%, the corresponding header color generally has a similar color with a lightness of around 60%.
So for example, the external credits course cards having a color of #f9d4cd, or hsl(10, 79%, 89%), would imply that the color of the corresponding header would be something like hsl(10, 79%, 65%) which translates to #ec775f.
Following that convention should eliminate the need to have to have a different text color for just the External Credits header.

I think #ec775f looks fine! It's dark enough that white text looks good and isn't too dark. Let me know what you think @bnehoran


NEW REPO: openebs/upgrade

Description

The upgrade repo will contain the upgrade related code for openebs resources. It will help upgrade the resources for regular releases and migration between different API versions.
Container images produced

openebs/upgrade-amd64
openebs/upgrade-arm64

Initial Maintainers

@kmova
@vishnuitta

Initial Reviewers

@shubham14bajpai
@prateekpandey14
@sonasingh46

New Repo Created at: https://github.com/openebs/upgrade/
Docker Registries created:

https://hub.docker.com/repository/docker/openebs/upgrade-amd64-ci
https://hub.docker.com/repository/docker/openebs/upgrade-adm64
https://quay.io/repository/openebs/upgrade-amd64
https://hub.docker.com/repository/docker/openebs/upgrade-arm64-ci
https://hub.docker.com/repository/docker/openebs/upgrade-arm64
https://quay.io/repository/openebs/upgrade-arm64


Metaflow should use Google/Numpy docstring style

At the moment, metaflow causes sphinx documentation using the shinx.ext.naploeon extension to break because many docstrings are not formatted according to either Numpy's or Google's style guides.
While this could technically be seen as a bug in sphinx using a well established docstring style like Google's or Numpy's would generally improve the readability of metaflow's docs.

Thanks! We will look into updating the docstrings shortly.

Hi @savingoyal any progress on this? Is the issue still open?

@gatesyp We are waiting on merging the convergence branch into master before addressing this issue and #323. Hopefully, we should be able to get there in the coming few weeks.


refactor: refine cli functions with api and evaluation error into the…

… error module.

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[x] N
[ ] Y

refine cli functions with api and evaluation error into the error module

2. What is the scope of this PR (e.g. component or file name):

main.rs
kclvm/capi/src/service/service.rs
kclvm/error/src/lib.rs
kclvm/runner/src/lib.rs

3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[x] Other

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

[x] N
[ ] Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

[ ] Unit test
[ ] Integration test
[ ] Benchmark (add benchmark stats below)
[ ] Manual test (add detailed scripts or steps below)
[x] Other

6. Release note

Please refer to Release Notes Language Style Guide to write a quality release note.
None

LGTM

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

10 of 94 (10.64%)  changed or added relevant lines in 6 files are covered.
382 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-1.6%) to 59.206%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

kclvm/capi/src/service/service.rs
9
10
90.0%

kclvm/runtime/src/value/val_plan.rs
0
1
0.0%

kclvm/runtime/src/context/mod.rs
0
6
0.0%

kclvm/error/src/lib.rs
0
15
0.0%

kclvm/src/main.rs
0
16
0.0%

kclvm/runner/src/lib.rs
1
46
2.17%

Files with Coverage Reduction
New Missed Lines
%

kclvm/ast/src/token_stream.rs
7
75.0%

kclvm/3rdparty/rustc_span/src/lib.rs
375
33.75%

Totals

Change from base Build<PHONE_NUMBER>:
-1.6%

Covered Lines:
21541

Relevant Lines:
36383

💛  - Coveralls


What is our intention for how users will interact with third-party APIs

Overview
From what I understand so far, the point of frig is to handle all of the requests sent to an API on the users behalf. This could include authenticating to the service, performing request to get data and refreshing authentication.
what we currently have
Right now it seems that we manage authentication and refreshing of authentication. But then if you look deeper many of these integrations are handling data from the API and processing that data in some way. This springs the companies business logic into the backend of create frigg app.
what I assume customers will do with a new frigg app
My guess is that you already have a software product where all of your back and logic is stored. In order to add logic into our application that stands alongside your application, you would end up adding logic in both places. This is probably not what people are going to do. My guess is that they will want all of their business logic in the classes that are already supporting their application.
treating frigg as a proxy
If we limit the responsibilities of frig to only handle authentication and request processing and authentication refreshing, then our job becomes a lot easier.
Possible Sample code
async myServerlessAuthRoute(config){
  frigg.salesforce.authenticate(config)
}

async myServerlessProxyRoute(request){
  if(notAuthed){
    refreshAuthentication()
  }
  return frigg.salesforce.proxy(request)
}

In this case, we don't need code like this
I just want to open the discussion here to start with the end user in mind in terms of how they will consume Frigg. Right now, it is too complex. We need to make the simple tasks much easier in my humble opinion

I guess my main intention here is to redesign the interface of how users interact with Frigg. Imagine where the code requires and instructions are like this:
NPM install -G frigg create-frigg-app
create-frigg-app my app

echo Welcome to frigg!
Do you want to create a front end for this application? (Y/N)
From the list below, tell us which integrations you want to install (Note, you can add more anytime with `create-frigg-app generate integration Salesforce`)

echo We will now prompt your browser to log you into all the things you need and set up your config for you :)
npm start

Now the new user simply calls in their existing code:
frigg.salesforce.proxy(method, body, headers)

This will take more time to build but will get adopted much easier :)

@joncodo I put together a diagram once to highlight this difference of "with Frigg, without Frigg"
After reading your thoughts/points, I have three immediate thoughts:

Frigg answers the question "How do we make a scalable framework so that we can build and maintain integrations that use a lot of common patterns and allow for isolated business logic with a manageable codebase". In other words, you'd have either started with Frigg and be set because you've got a separated out repo, or you'd reach for a Frigg-type solution as your core codebase gets larger/more mature. Any integration-based business logic should be put into its own area, not necessarily baked into the rest of your application's logic. Ideal for a microservice solution.
The other user/person here is not the one off developer, but rather the head of product, head of engineering, or someone whose job is to look at the bigger picture and say "how can we get all of these things built with the resources we have?". What Frigg enables for this person is the ability to look externally for engineering help with external APIs. Instead of having their core engineering learn an external API and its nuances/intricacies once, they can either leverage the ever-increasing value of Frigg abstractions, or they can hire an external team to contribute their knowledge just to an isolated integration codebase (so, they don't need a contractor to have access to their core code/they can just hire expertise in a specific application/marketplace/ecosystem). Or they can combine approaches. The point here is that leveraging Frigg is beneficial for what it unlocks with getting external expertise in the door to help.
As it currently stands, Create Frigg App and most of the stuff inside Frigg's core repo do not show half of the puzzle. The first half is "help me handle authentication for many popular APIs and give me a normalized API/framework to handle that whole integration management flow". The second half is "Give me the tools and primitives and common patterns to quickly add business logic to my integrations".

For point #3 above, some patterns that we have scattered around different repos (that need to be given some love in the form of further massaging/abstraction):

Resumable processes (state machine + caching + common API patterns). One existing Left Hook client has this exercised pretty heavily in their repo.
Syncing logic (bi-directional, one-way, multiple api mapping). There's an existing "Sync Manager" and "Sync Object", with a not-yet-converted-to-Jest unit test that could be used and exercised further. It's actively used in 3 Left Hook client repos.
Webhook Handling. This should be an easy drop-in... need a new webhook handler? What type of webhook? (There are 3 common patterns). Handler drops into message into SQS queue (or Google Cloud PubSub topic etc.), and a separate function handles the actual message.
Cron/Polling Based Eventing. This is used by every current Left Hook client, very common pattern.
Target API Specific Code patterns. Primary example for this is HubSpot, where there are some common patterns that are immediately templateable and should be abstracted/made easier to consume for the end user developer. CRM Extensions (HubSpot makes a request to an API endpoint that you the developer informs HubSpot of; HubSpot calls the endpoint on every Contact/Company/Deal page load (configurable); HubSpot expects specifically formatted JSON in response in order to expose a UI widget inside HubSpot).
Unified API patterns. We're just starting to scratch this surface. But the ultimate goal is to have a layer on the API Module (not sure where it should go yet) where the API is translated/mapped to a specific category, so as the consumer of the API you can expect a normalized body back regardless of the underlying API being used. (So, "Contact" from a CRM comes back with the exact same fields, just swap out the underlying API provider and it still works... this enables development of categorical integrations).

There's much more that we'd add to the mix, but I think the last comment I would say is: Anyone is welcome to use any of these packages as they'd like. In the proxy case you're expanding on here, I would instead suggest that the developer grabs the API module, figures out on their own where to store api credentials, and then uses the Manager and API module to handle the requests in whatever they're doing for their compute. That said, there's no reason that they/we couldn't make a proxy layer microservice out of a Frigg application; that would be a valid use, once we've added more tooling around logging and handling etc.; It just seems to me that it would be underutilizing all that Frigg has to offer (once we've done the work to make the abstractions and functionality available to pull in).

Ok. That all sounds good to me. I can think of two take aways to be discussed.

@seanspeaks please approve - :) I think every api module should include the proxy method by default in the case where we do not have all of an API mapped over with helper methods.
I will write new tickets for use cases and we can refine that and put it in the docs. I think it is important to know who this is for and why you want to use it and why you don't want to use it.

@seanspeaks please validate these comments for the docs and modify to be more accurate 😄
Why you would want to use Frigg

You need to work with many APIs that interact with a lot of data
Its a scalable framework that handles interactions with many APIs
You can use common patterns to interact with all API features that are exposed
You can use Frigg as a micro service to handle your API interations
If we all work on the same problem, we all win when it comes to dealing with APIs

Why you may not want to use Frigg

You only need to interact with one API. (Frigg can still do this but the learning curve might out weigh the cost)
You don't want to use serverless

How is Frigg different than passport js?

Frigg handles a data model
Frigg handles authentication for you
Frigg exposes API methods from the API with a layer of abstraction

please approve - :) I think every api module should include the proxy method by default in the case where we do not have all of an API mapped over with helper methods.

Totally- though currently, that's achievable via access to the internal methods, which should inherit auth method/headers by default (api._get('url', optionsObject), ditto _post, _put, _delete, _patch)

I will write new tickets for use cases and we can refine that and put it in the docs. I think it is important to know who this is for and why you want to use it and why you don't want to use it.

Yup agreed
Why you would want to use Frigg

You need to enable end users of your app to work with many APIs that interact with ~a lot of~ their external data in a  low-touch, no-code UX
~Its a scalable framework that handles interactions with many APIs~ You want an architecture that allows for zero or low cost when there is little to no usage, but will scale quickly without DevOps/infrastructure management overhead
~You can use common patterns to interact with all API features that are exposed~ You want to use tried and true common integration patterns that take advantage of general API features and features specific to a given API, without having to come up with those patterns yourself
You can use Frigg as a micro service to handle your API interations
~If we all work on the same problem, we all win when it comes to dealing with APIs~ As a whole community of developers solves bugs and adds features, we all benefit from an easier integration development experience. Thousands of developers will solve problems much faster than any one company or developer ever could.
The library of API modules is ever growing and improving, and it's simple/easy to add your own
New recipes, workflows, and code patterns are added at a regular basis by the core team and by community contributors that could greatly benefit your own integrations
You'd like to involve external developers to contribute their code to your integrations, but you don't want them to get access to your whole primary codebase
Other solutions are too costly

Why you may not want to use Frigg

You only need to interact with one API. (Frigg can still do this but the learning curve might out weigh the cost)
You don't want to use serverless, or you want to use a technology that is not yet supported by the core framework
The methods on the API that you need have not yet been exposed in the Frigg API Module (Feel free to make a PR 😄 ) [Sean comment: Not sure this is a real objection when considering internal methods are readily available? see note above]
Frigg is not yet mature enough
You already have a working framework for developing integrations rapidly

How is Frigg different than passport js?

Frigg handles a data model [Sean Comment: I don't know what this means?]
Frigg handles authentication and credential storage for you
Frigg exposes API methods from the API with a layer of abstraction
Frigg's primary focus is on the actual development of the business logic that powers an integration; Passport.js focuses on user authentication and identification.
Frigg has opinions on compute and has primitives based on serverless compute to build that integration logic

Excellent work flow. I think this is a great new docs section!


If wrapped in tcolorbox, beginning \parskip is always inserted

From https://github.com/T-F-S/tcolorbox/issues/122. Note that theorems defined by amsthm work ok.
The problem occurs when

\parskip is non-zero and
tcolorbox option parbox=false is set.

\documentclass{article}
\usepackage{tcolorbox} % reproducible even prior to tcolorbox v4.32
\usepackage{lipsum}

\usepackage{amsthm}
\newtheorem{thm}{Amsthm}
\usepackage{thmtools}
\declaretheorem[name=Thmtools]{theorem}

\parskip=10pt
\def\dummy{
  Nam dui ligula, fringilla a, euismod sodales, sollicitudin vel, wisi. \par
  Morbi auctor lorem non justo. Nam lacus libero, pretium at, lobortis vitae, ultricies et, tellus.}

\begin{document}
\tcbset{parbox=false}

\begin{tcolorbox}
  \begin{theorem} \dummy \end{theorem}
\end{tcolorbox}

\begin{tcolorbox}
  \begin{thm} \dummy \end{thm}
\end{tcolorbox}
\end{document}

The output is different now; both cases have the extra space.

Looks like (another) parbox=false problem from tcolorbox. Not sure if it's intended.
Tested on overleaf.com, tcolorbox v4.30 (2020-04-28) won't cause empty paragraph in the parbox=false box in your example.

I've added a comment to the corresponding closed tcolorbox issue.

I opened T-F-S/tcolorbox#262.

Fixed with tcolorbox #262.


[INFRA] Add k8s pipeline

What changes were proposed in this pull request?
Add a github pipeline to run the tests of k8s
Why are the changes needed?
It can help us to verify the k8s patch
Does this PR introduce any user-facing change?
No
How was this patch tested?
No

Codecov Report

Merging #340 (bf19d40) into master (1aa3661) will decrease coverage by 1.12%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #340      +/-   ##
============================================
- Coverage     61.37%   60.24%   -1.13%
+ Complexity     1529     1447      -82
============================================
  Files           186      177       -9
  Lines          9445     8898     -547
  Branches        924      887      -37
============================================
- Hits           5797     5361     -436
+ Misses         3340     3243      -97
+ Partials        308      294      -14

Impacted Files
Coverage Δ

...org/apache/spark/shuffle/RssSparkShuffleUtils.java

...e/spark/shuffle/reader/RssShuffleDataIterator.java

...ava/org/apache/spark/shuffle/RssShuffleHandle.java

...pache/spark/shuffle/writer/WriteBufferManager.java

...k/shuffle/writer/WrappedByteArrayOutputStream.java

.../java/org/apache/spark/shuffle/RssSparkConfig.java

...org/apache/spark/shuffle/writer/AddBlockEvent.java

...che/spark/shuffle/writer/BufferManagerOptions.java

.../org/apache/spark/shuffle/writer/WriterBuffer.java

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Could you help me review this patch? @zuston @kaijchen


Replace form with link to form at helsenorge.no

Follow-up on #143
The official national form for Norway has been launched a few days ago:
https://minhelse.helsenorge.no/skjemautfyller?Query=Questionnaire/302
Probably the other pages should have a banner as well telling the data is for previous registation before the form was disabled.
I also advice to add text to encourage people that have already registered to also register at helsenorge.no. The problem now is that we possibly have 7000+ people who think they have already registered, and do not understand they need to go to helsenorge.no as well. Not all people will see this text, but it will make it explicit and easier to communicate.

https://github.com/BustByte/coronastatus/pull/304


solid-js/web does not provide an export  named "AddEventListener"

Hello. I follow the steps and it gave me this error .

Hmm, maybe an issue with SSR? I assume this is an SSR configuration?

Yes is SSR configuration with solid-start. Looks like an SSR issue

The latest version has been tested with solid-start.  I'll close this issue for now.


[BUG] wash app commands do not respect wash context

Feature or Problem
When a context is set, wash app commands should respect that context
Related Issues
#864
Release Information
wash-cli v0.22.0
Consumer Impact
improved correctness and DX for wash app  commands.
Testing
Unit Test(s)
test_lattice_prefix_and_nats_client_from_cmd_opts

@ahmedtadde the latest changes look great. It looks like part of your new test is failing, but only on Windows. I suspect set_default_context might not be working on Windows(?) If you add #[cfg(not(target_family = "windows"))] above the new test and it passes, I think we should merge this and file a separate issue to investigate wash contexts on Windows

Filed the suspected windows bug: https://github.com/wasmCloud/wasmCloud/issues/966


WIP: Broker Relist Subresource

2nd PR implementing a relist subresource, as outlined by #1086.

At some point I would like to discuss this with you guys, mostly because I feel like you are doing it wrong.

@enj can you elaborate?

Sorry did not have time earlier to elaborate.  So, to be clear, I am not commenting on the validity of actually having a relist subresource.  I will admit that it strange to have an endpoint the exists solely to cause a change to an API type, and I do not really understand why you need or want to do that.  But I will leave that for you guys to decide as I lack the context to say if its a good idea or not.

So what I believe from this is a bad idea is the actual implementation of the relist subresource endpoint.  This implementation re-uses the registry store struct, which is fine if you need all the power and flexibility that gives you.  But you do not need that at all in this case (and you are offloading too much onto the user wanting to relist by forcing them to give you the broker resource as input).  And using this struct is dangerous because it tightly couples you to the underlying implementation, is effectively direct to etcd, and allows you to bypass parts of the standard REST path.  We made the mistake of doing this in a lot of the API types in Openshift.  And we realized it was a really bad idea, and have now gone through the pain to rewriting those bits to use the REST client interfaces.  So my suggestion would be for you to build this using the broker REST client interface.
Here is a rough draft of what I think you should do instead:
type RelistBroker struct {
	metav1.TypeMeta
	metav1.ObjectMeta

	// Spec holds information about the request being evaluated.
	Spec RelistBrokerSpec

	// Status is filled in by the server and indicates whether the request succeeded
	Status RelistBrokerStatus
}

type RelistBrokerSpec struct {
	// you may not need this at all, but I could see this being something
	// like "relist" if you want to support other actions in the future
	// you would want more generic names for the struct if you want to
	// support such a use case though
	Action string
}

type RelistBrokerStatus struct {
	// did the relist happen?
	Success bool

	// if it failed, why did it fail
	Reason string
}

type relistBrokerREST struct {
	client brokerRESTInterfaceClient
}

func (r *relistBrokerREST) New() runtime.Object {
	return &RelistBroker{}
}

func (r *relistBrokerREST) Create(ctx genericapirequest.Context, name string, obj runtime.Object, includeUninitialized bool) (runtime.Object, error)
	rb, ok := obj.(*RelistBroker)
	if !ok {
		return nil, apierrors.NewBadRequest(fmt.Sprintf("not a RelistBroker: %#v", obj))
	}
	// perform any validation on rb as needed
	...
	// get the broker we are a sub resource of so we can relist it
	r.client.Get(name)
	// increment the counter with whatever logic you want
	...
	// update the broker
	err := r.client.Update(name)
	// retry on conflict if needed
	// create a new RB as the response (and fill in data you know to be true)
	rbOut := &RelistBroker{}
	rbOut.Status.Success = true
	return rbOut, nil
}

I find this approach to be significantly simpler.  It is basically what a user might do by hand, but turned into a very tightly controlled API.  Note that it requires no strategy because it uses a REST client, and it is not tightly coupled with the storage implementation of the broker itself.  If desired, instead of doing a relist subresource, you could simply do an action subresource that could later support different controlled actions against the broker.  But maybe you do not need that complexity.

Sublist resource may have to be 0.1.1 item.
On Fri, Oct 6, 2017 at 11:17 PM Mo Khan<EMAIL_ADDRESS>wrote:

Sorry did not have time earlier to elaborate. So, to be clear, I am not
commenting on the validity of actually having a relist subresource. I
will admit that it strange to have an endpoint the exists solely to cause a
change to an API type, and I do not really understand why you need or want
to do that. But I will leave that for you guys to decide as I lack the
context to say if its a good idea or not.
So what I believe from this is a bad idea is the actual implementation of
the relist subresource endpoint. This implementation re-uses the registry
store struct, which is fine if you need all the power and flexibility that
gives you. But you do not need that at all in this case (and you are
offloading too much onto the user wanting to relist by forcing them to give
you the broker resource as input). And using this struct is dangerous
because it tightly couples you to the underlying implementation, is
effectively direct to etcd, and allows you to bypass parts of the standard
REST path. We made the mistake of doing this in a lot of the API types in
Openshift. And we realized it was a really bad idea, and have now gone
through the pain to rewriting those bits to use the REST client interfaces.
So my suggestion would be for you to build this using the broker REST
client interface.
Here is a rough draft of what I think you should do instead:
type RelistBroker struct {
metav1.TypeMeta
metav1.ObjectMeta
// Spec holds information about the request being evaluated.
Spec RelistBrokerSpec
// Status is filled in by the server and indicates whether the request succeeded
Status RelistBrokerStatus
}
type RelistBrokerSpec struct {
// you may not need this at all, but I could see this being something
// like "relist" if you want to support other actions in the future
// you would want more generic names for the struct if you want to
// support such a use case though
Action string
}
type RelistBrokerStatus struct {
// did the relist happen?
Success bool
// if it failed, why did it fail
Reason string
}
type relistBrokerREST struct {
client brokerRESTInterfaceClient
}
func (r *relistBrokerREST) New() runtime.Object {
return &RelistBroker{}
}
func (r *relistBrokerREST) Create(ctx genericapirequest.Context, name string, obj runtime.Object, includeUninitialized bool) (runtime.Object, error)
rb, ok := obj.(*RelistBroker)
if !ok {
return nil, apierrors.NewBadRequest(fmt.Sprintf("not a RelistBroker: %#v", obj))
}
// perform any validation on rb as needed
...
// get the broker we are a sub resource of so we can relist it
r.client.Get(name)
// increment the counter with whatever logic you want
...
// update the broker
err := r.client.Update(name)
// retry on conflict if needed
// create a new RB as the response (and fill in data you know to be true)
rbOut := &RelistBroker{}
rbOut.Status.Success = true
return rbOut, nil
}
I find this approach to be significantly simpler. It is basically what a
user might do by hand, but turned into a very tightly controlled API. Note
that it requires no strategy because it uses a REST client, and it is not
tightly coupled with the storage implementation of the broker itself. If
desired, instead of doing a relist subresource, you could simply do an
action subresource that could later support different controlled actions
against the broker. But maybe you do not need that complexity.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/service-catalog/pull/1266#issuecomment-334906757,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWXmBbGSnNio7iGkv7VSCeNZeMd5ABdks5spu1TgaJpZM4Pi97Y
.

@enj

I will admit that it strange to have an endpoint the exists solely to cause a change to an API type, and I do not really understand why you need or want to do that.

The purpose of this endpoint is to provide a REST api that results in the generation of the broker resource being bumped without requiring the user having to know how to change the spec in just the right way to cause a relist, or worse, making a change to the spec in another area just to cause a relist.
I will be honest here: we already have the functionality required for users to get the behavior we want, and the relist subresource isn't strictly required to do it.  So, if you would like to sherpa your preferred design through, that's fine.  If we can't agree on an approach, that's also fine.  In either event, I don't consider this to be in the critical path for a beta release, and have other things that are higher priority to give attention to.
So, in conclusion: @enj and @eriknelson, feel free to work together on this.  I suggest that you write up a proposal that shows examples of the body that should be sent to this call and the response returned to the user before you work further on implementation, and present that as a separate PR or issue.

I have some unrelated work I need to take care of this week, but I'm planning on submitting a proposal for an alternate implementation that incorporates @enj's suggestions to #1086 soon.

@eriknelson starting this back up since it's been stalled for a while - I think @enj's comment here is ringing the bell for me.
@enj I also think that your example is a very concise one that would be useful to write up in an API doctrine-type document somewhere.  (related: kubernetes/community#892)

This is so far out of date I'm going to close.


feat(expectedConditions): add helper library for syncing with non-angula...

...r apps

usage:
var EC = protractor.ExpectedConditions;
var button = $('#xyz');
var isClickable = EC.elementToBeClickable(button);

browser.get(URL);
browser.wait(isClickable, 5000); //wait for an element to become clickable
button.click();

You can also customize the conditions:
var urlChanged = function() {
  return browser.getCurrentUrl().then(function(url) {
    return url != 'http://www.angularjs.org';
  });
};

var condition = EC.and(urlChanged, EC.titleContains('foo'), EC.textToBePresentInElement($('def'), 'bar'));
$('navButton').click();
browser.wait(condition, 5000); //wait for an element to become clickable
// do other things

Can you add the usage notes to the commit message?

Added usage examples

LGTM!

committed at https://github.com/angular/protractor/commit/9bc1c53e40161521b0c125a810f86235c974f100

How do we test for non clickable with this?


Deleting a former ghost page deletes the page in the other locale

Q
A

Bug?
yes

New Feature?
no

Sulu Version
1.4.2 (tried with sulu-minimal)

Actual Behavior
Two users:
"EnglishGuy" only has read & write permission in en locale
"Admin" can do anything in de + en

EnglishGuy creates a page in en locale
Admin creates a copy of the ghost page of the en locale in the de locale.
Admin deletes the page in the de locale

This does not only delete the page in de, but also in en.
Expected Behavior
Only the page in the current locale (de) should be deleted.

Deleting should actually work this way, and removing only the content of one locale is a missing feature we haven't implemented yet. The only problem I see here, is that the user should actually not be allowed to delete the page, if he doesn't have the permission to do so in all languages.

@danrot Oh, ok, thank you. Should I add the feature tag to this issue or are you already tracking this?
BTW: I think you misread something, I deleted the page with the Admin user (he has all permissions everywhere).

Actually I thought we already had an issue like that... But I can't find it anymore. Maybe you can create a new issue, which explains this feature (doesn't have anything to do with the permission stuff you've described here).

Ok! Created issue https://github.com/sulu/sulu-standard/issues/776.

Just to be sure, it would not have been possible to delete the page without having the permissions for all languages?

Ok, I just checked it and have bad news. I could delete a page with User_DE even though he only has write permissions in the de locale (but read permissions in all locales)...
Should I create a separate issue for that?

@afroewis Yes, that would be awesome.

Created  https://github.com/sulu/sulu-standard/issues/777.


TypeError: init() got an unexpected keyword argument 'status'

When Trying to run a simple example, I am getting this Type Error. could be Notion changed something?
file "/usr/local/lib/python3.5/dist-packages/notion/client.py", line 40, in create_session
method_whitelist=("POST", "HEAD", "TRACE", "GET", "PUT", "OPTIONS", "DELETE"),
TypeError: init() got an unexpected keyword argument 'status'

Just trying notion-py for the first time today, and I hit exactly the same issue.
This occurs on:
client = NotionClient(token_v2="<my token>")

For me this problem actually happened when 'requests' package was out of date

You can delete “status=5,” in “retry = Retry(status=5,)” which path is notion/client.py, deleted it also can run with no wrong.

I can confirm that my problem was also an outdated requests package


Implemented TimeSpan type, which is the type used to represents durat…

…ion of various service bus specific properties

Is this similar to http://joda-time.sourceforge.net/apidocs/org/joda/time/Period.html?

The Period in Java and TimeSpan in C# represents duration. One issue I'm facing with Period is using it to parse RP returned duration represented in TimeSpan format.
Period's built-in formatter ISOPeriodFormat can be used only if the duration is represented in ISO8601 format, which is the swagger recommended format but service bus will switch to this format only in the future api version.
I tried PeriodFormatBuilder, but unable to parse all the possible combination that TimeSpan string format.
    [-]d\0
    [-]d.hh:mm\0
    [-]hh:mm\0
    [-]d.hh:mm:ss\0
    [-]hh:mm:ss\0
    [-]d.hh:mm:ss:ffffffff\0
    [-]hh:mm:ss:ffffffff\0

For example following builder requires string to be exactly in hh:mm:ss:ffffffff format
        PeriodFormatter formatter = new PeriodFormatterBuilder()
                .appendDays().appendSeparatorIfFieldsAfter(".")
                .appendHours().appendSeparatorIfFieldsAfter(":")
                .appendMinutes().appendSeparatorIfFieldsAfter(":")
                .appendSeconds().appendSeparatorIfFieldsAfter(".")
                .appendMillis()
                .toFormatter();

But I'm thinking that in fluent user can specify duration using Period type and internally we use TimeSpan type. Once the PR started supporting ISOPeriodFormat (which is planned for next api version) we can just remove the TimeSpan.

https://github.com/Azure/autorest/pull/369

@jianghaolu - thanks for the autorest discussion link about duration.
Once the service bus starts supporting ISO8601 duration then Java codegen will emit joda.time.Period.
In the fluent layer, we accept joda.time.Period and TimeSpan type (in implementation namespace) can convert this to C# TimeSpan format to send over the wire. This means once service bus update rolled out fix https://github.com/Azure/azure-rest-api-specs/issues/962#issuecomment-282851197 without breaking customer we can just remove period-to-timespan conversion.


[Feature] Client Optional?

Hello!
We are putting together a vanilla+ server, and some users are not interested in interacting with mods at all. Sorry, I checked around and couldn't find out answers to some questions.
Does origins require the client to have the mod installed or is it optional without server complication? We're putting together our 'optional' mods as part of the shared pack so they can enable only if they want it.
Or, is there a way to defer the race screen until the player triggers a command, or gets a default race that can only be overridden using the mods item?
Thanks for your consideration!

Installing the mod on clients isn't optional, I'm afraid. There are many features the mod uses which requires clients to cooperate with the server. Therefore this is not possible, and I'll close this feature request.
However, the second part of your question is possible. You can make the mod "auto-choose" the Human origin (no special features at all), which prevents players from choosing an origin at the start. They can then use an Orb of Origin (you'd need to add a crafting recipe or use /give to give them one) to get the regular origin selection screen. Another option, not using the item, would be using the /origin gui <target> command to make the origin screen appear for them.
To do that, you'd need to use a datapack too, like this one which does what I just described: https://cdn.discordapp.com/attachments/749571272635187342/937741131402313748/Human_Default.zip
Another option would be just using the mod as is. Players who don't want an origin can just choose human in the selection screen.


[dxgi] Delay qualifying foreground loss as occlusion

That fixes a regression with Yakuza 0 introduced by commit ed9ffa6584dfb49a630df4d8cd7ec7fe29b1f23b (after which commit the game hangs with black screen on start).
There are actually two manifestations of essentially the same problem.

The initial hang on start happens after the game sets fullscreen mode through dxgi and then calls GetFullscreenState which kicks off fullscreen state and retuns no fullscreen status. This is unexpected, game seems to refuse to do anything after this. What happens here is that the game didn't make the window visible yet before SetFullscreenState, it is only becoming visible in the course of configuring fullscreen mode (here on Windows WS_VISIBLE attributed is still not set while window is fullscreen and visible, but this is unrelated and unfixable in dxvk in isolation). The process of window gaining focus has some delay. Window manager ultimately controls the focus, so Wine doesn't make a window foreground for WINAPI until WM sends corresponding X events. That doesn't happen immediately and the delay may be quite big until the window is fully mapped, displayed and only then we get a focus event and mark the window as foreground. So GetFullscreenState called right after SetFullscreenState sees that the window is not foreground and kicks off fullscreen mode. If solving just initial fullscreen setting (by checking that our window ever had focus at all before concuding that it is occluded) fixes the hang on start, but then at any alt tab the same happens: after kicking off fullscreen the game seems very unhappy and refuses to do any presentation or window management.
How the game is supposed to work, is that upon receiving WM_KILLFOCUS it sets windowed mode itself and minimizes the window. WM_KILLFOCUS is apparently supposed to arrive before GetFullscreenState() will kick off fullscreen mode. I think here plays the role that using GetForegroundWindow for detecting "occlusion" status is a workaround, some delays for focusing events may also affect this sequence. I doubt it is possible to fully correctly solve without having Windows-like WSI and window management not intergating host's native WM.

The added delay to react on foreground loss should hopefully solve the issues with transition process in p. 2. A separate check for yet-nevet-foreground window is still needed for p. 1., ~100ms may be by far not enough for that process to settle at list in this case when the window is getting mapped during fullscreening.

From the failed build log it seems to me the failure is not related to the patch

GitHub Actions are just like that sometimes: https://github.com/doitsujin/dxvk/actions/runs/11039230566/job/30664242387 ... if you force-push a nop it will usually go through just fine.

Overall idea alright to me, but is the check really something we want to do in the WSI backend rather than the DXGI swap chain itself? I feel like doing this in the swap chain would give us better control on when to reset the timer and also make it more obvious what's going on.
We have high_resolution_clock (in util_time.h) as a portable way to measure time if that's a concern, use high_resolution_clock::time_point to store time stamps and then the comparison can be something like if (high_resolution_clock::now() - m_timestamp > std::chrono::milliseconds(100)).

The reason I placed it into WSI is that logically that part is supposed to tell whether this is occluded or not (taking into account Win32 state,  potentially in the future performing some Win specific interaction). I think this timeout logically belongs there. Here the timer is reset on start of a certain Win32 operation, backend should be aware of anything happening to window config. I'd suggest to keep the Win / Wine specifc 'isOccluded' logic in the backend while the logic related to swapchain config may be in the swapchain part.
But if you feel strong to do that another way no problem for me moving it to the swapchain part of course.

(in other words, if sdl2 backend would decide to implement isOcclusion that delay logic on top of that in swapchain code would likely make no sense for it)


NoSuchMethodError in Jobs.java:169

*Detailed description of the issue: The Plugin isn't starting because spigot says it isn't up to date

Error:
https://www.toptal.com/developers/hastebin/asipoyawiv.yaml

Jobs Version: v2.12.0
Server Type (Spigot/Paper/etc): Spigot
Server Version (using /ver): 1.18.2

You have 2.12.0 version, latest one is at <IP_ADDRESS>, so yes, its not up to date.


Cannot switch from move mode to rotate mode

Description
In v1, I typically select a building, hit M key to move it, then before clicking, I hit R key to switch to rotate mode, so I can align it with the satellite map, then click to finish.
In v2 when I am in move mode, I hit the R key and nothing happens to the building, it stays in move mode. I have to click first then hit R to rotate. This adds a step so slows me down.
Version
2.0.0-beta.0
What browser are you seeing the problem on? What version are you running?
Chrome v110.0
The OS you're using
No response
Steps to reproduce
No response
The browser URL at the time you encountered the bug
https://mapwith.ai/rapid-v2-beta#background=EsriWorldImageryClarity&datasets=fbRoads,msBuildings&disable_features=boundaries&id=w-1314881948303995373&map=20.06/25.40854/-101.01982
The auto-detected useragent string for your browser (leave blank if you're manually filling this form out)
No response

Ah yeah I was just looking at this a few days ago. It was bothering me too 😆
The details on this one are: previously we had this complicated architecture with Modes and Behaviors but also some of the Modes had special built in Behaviors to do the key listening.  We made a new Behavior for key listening but it needs some cleanup.


[WIP] PoC of resvg-convert (rsvg-convert like tool)

NOTE: This is my first ever written Rust code - I won't lie, a lot of it was trial and error
What is working (and is working well):

Output to STDOUT resvg-convert in.svg -f png
Conversion to SVG with text converted to path resvg-convert in.svg -f svg -o out.svg
.. and to other vector based formats "pdf", "eps", "ps".

What is not working:

--export-id is exporting an object in raster images
Not done in the Qt backend. Not sure if even doable?

What is left to do:

Fix build
Add tests
Taking SVG input from standard input
Go through other rsvg-convert options
Get reviews and feedback.

Not done in the Qt backend. Not sure if even doable?

Qt also supports PDF. And resvg must support the same set of features for all backends. Otherwise it's no go.

Conversion to SVG with text converted to path

This is very bad. I want to omit this. And it's not possible at the moment.

Taking SVG input from standard input

This is a separate issue.
Anyway, as I said previously, I don't want to rely on backend's internal PDF support. Mainly because there will be more backends in the future, so the PDF backend should be standalone and handwritten. Also, they are pretty unpredictable and I want a full control over the output.
Thanks for your effort, but I can't accept this pull request.

So what's your advice? I need this tool. Should I maintain a fork of resvg in my own repo then?

This is very bad. I want to omit this. And it's not possible at the moment.
Can you explain what's very bad? As I said rsvg-convert exports SVGs with texts converted to path and I need this very behavior. At least for my use case this PR does the job.

In fact it's already running in a production environment. The question is now on how do I tie it in into resvg.

I need this tool.

I'm not sure what exactly do you need. As I said before, if we will use backend's PDF implementation it will create raster images anyway. So it's easier to embed PNG directly.

Should I maintain a fork of resvg in my own repo then?

If you want it right now - yes. I will not use backend's PDF implementation anyway, as I explained earlier.
Could you explain why do you need this and in what form do you plan to use it?

Do you need a single page PDF?
Do you need an ability to embed SVG into an existing PDF? In this case resvg should produce some intermediate output.
Why not PNG? Because of scaling? If so, SVG cannot be converted without raster layers anyway (not sure what features does PDF support).
Why do you need text to path conversion? It will create a huge file with poor performance. On the other hand, we have to embed custom fonts to the PDF to use text.
What about filters? How can we translate Gaussian blur to PDF? Should it be ignored? Should it be optional?

I'm not against the PDF support, but I'm not sure what result do you expect to achieve.

if we will use backend's PDF implementation it will create raster images anyway. So it's easier to embed PNG directly.

I will reply to your other questions in depth later but I want to answer the above first.
Given this SVG https://rush.sh/Gjv2o6FVC3hmT0edWku7Dr7oVPE/0c1cUj.raw.svg (which is representative of what I'm doing)
resvg-convert 0c1cUj.raw.svg -f pdf -o 0c1cUj.pdf
It generates a PDF that is fully vector.

I'm not sure what exactly do you need. As I said before, if we will use backend's PDF implementation it will create raster images anyway. So it's easier to embed PNG directly.

I need rsvg-convert-like functionality to pipe-in SVG from stdin and pipe out results to std-out in the following formats:

SVG with text converted to paths. I don't care that the resulting SVG is huge - I care for it to render correctly even in web browsers which don't have the fonts installed.
PDF with vector properties preserved
PNG with configurable DPI (for example small DPI is used to generate thumbnails)

resvg-convert which this PR implements satisfies all of the above requirements. But I would like to avoid maintaining a fork and rather (at least) contribute some parts of it to resvg itself. I'm fine maintaining the resvg-convert tool itself.

Could you explain why do you need this and in what form do you plan to use it?
I use it as a utility function in a SaaS product (I can share which one but I don't want to be accused of using this thread for advertising). The results are viewed through a web browser.

Do you need a single page PDF?
Yes, just one page with the dimensions of the original SVG file.

Do you need an ability to embed SVG into an existing PDF? In this case resvg should produce some intermediate output.
No - just pure SVG -> PDF. Same as rsvg-convert does.

Why not PNG? Because of scaling? If so, SVG cannot be converted without raster layers anyway (not sure what features does PDF support).

PNG is not good for printing, not good for zooming. In my case SVG files are also smaller than respective rendered SVG file. SVG can also be post-processed and DOM events can be attached to it.

Why do you need text to path conversion? It will create a huge file with poor performance. On the other hand, we have to embed custom fonts to the PDF to use text.

It's for the web. Users may not have the right fonts installed. Huge file is not a concern as it's actually not that huge in practice. (smaller than a PNG file anyway) Performance seems OK (remember I've been using rsvg-convert before)

5. What about filters? How can we translate Gaussian blur to PDF? Should it be ignored? Should it be optional?

Preferably rasterized - honoring the DPI setting.

Thanks for feedback. I will look into it.

@RazrFalcon I hope you're doing well. Do you think resvg would serve my use-case well today? I am still using my modified resvg library from a year ago. Can I update and throw away my old code?

Sadly, no. The next release will specifically forbid such use case. svg2pdf must be written from scratch.

That's unfortunate as my PR has served me well for the last year. I guess I will just keep using the old call.

Sure, but it works only in very specific range. And resvg aims to support most of the spec.
Hopefully, it will be implemented one day.