Question: SchemaOf returns undefined-able type for a required array?

Yes, strict nulls is a required typescript setting for types to work, as mentioned in the docs

SchemaOf returns undefined-able type for a required array
I need to verify that my schema match array of strings, so I use [`yup.SchemaOf `]( URL but when I try to validate using this schema or InferType from it, it returns me `string[] | undefined`. I can't understand where this `undefined` comes from:

js
const schema: yup.SchemaOf = yup.array().of(yup.string().required()).required();
type MyType = yup.InferType ;

Expected result: `type MyType = string[]`
Actual result: `type MyType = string[] | undefined`

I provided this simplified example, but this happens not only with array of strings, but with any arrays, including arrays in object attributes.

Note: if I don't use SchemaOf annotation, it works as expected:

js
const schema = yup.array().of(yup.string().required()).required();
type MyType = yup.InferType ; // type MyType = string[]

(but that way I can't guarantee that validation schema produce objects that match types defined in my application)

Yup version: 0.32.11
NodeJS version: 16.15.0
TypeScript version: 4.6.4

It became pretty annoying so I appreciate any feedback. Thank you!

This is also here: URL

I'm not sure why this isn't being fixed. Validating that arrays are defined seems like a pretty basic validation rule.

this will still fail if strict is set to false in the tsconfig.json... example on the left is without strict mode enabled
image

Took me a second to figure that out. You may end up introducing new TS errors when changing the config, though.

also posted here: #1389

Validation of required/defaulted array results in array | undefined type
**Describe the bug**
When validating a required array or an array with a default value, the resulting type is `arraytype[] | undefined`, as if it wasn't required.

**To Reproduce**
Example to reproduce:

typescript
import * as yup from 'yup';

// Define a required array of required numbers
export const schema: yup.SchemaOf = yup.array().of(yup.number().required()).required();

async function test() {
 // Type 'number[] | undefined' is not assignable to type 'number[]'.
 // Type 'undefined' is not assignable to type 'number[]'.
 const x: number[] = await schema.validate([]);
}

Same result when using `.default([])`.

**Expected behavior**
A required array should have type `arraytype[]` without undefined.

**Platform (please complete the following information):**
 - Yup 0.32.9
 - Typescript 4.2.3

Hello, I tried to run it using :
- Yup 0.32.8
- Typescript 4.2.3
And it worked, no `| undefined` added to the expected type.

Minimal runnable example here : URL

It seems to have broken between the 0.32.8 and the 0.32.9, but I have no idea of the modification that could have caused this type bug.

This one worked for my `string | undefined` problem:
`members: yup.array().of(yup.string().required(errorMessage)).defined()`


Question: [google_maps_flutter] Google maps overlay?

@UDAYBIDKAR did some great work on this in URL but unfortunately isn't available to finish the work. If anyone would like to build on their great contribution and take it to the finish line, that would be great — there's just some review comments to address (see the PR for details).

[google_maps_flutter] Google maps overlay
I would like to display an image in overlay at given lat-log positions on Google map using Flutter. I am using flutter package google_maps_flutter: ^2.2.1, at present the package does not provide to implement the feature .

@tuandq2711
Can you elaborate on the use case you are trying to achieve and current limitation you are facing ?

@darshankawar
Currently on android or ios there is a Ground Overlays section to be able to draw images on the map. But on google_maps_flutter I don't see any to use. I can't add that part by myself so I hope you guys can help me add it.

Closing this as duplicate of URL Please follow-up in it for further updates.

[google_maps_flutter] Support for Ground Overlay
Hi, I'm developing an app where the main functionality is a Map with a Custom Ground Overlay. I've achieve that with the Ionic Framework but I want to make a Flutter version and I notice that the Ground Overlay Class or functionality is not present in the library at the moment.

This is what I need:

Android:
 URL

iOS:
 URL

This is a main functionality for my app, so I need this to launch a production Flutter version of my app. Please, take a look at it.

Thanks!

Are there any plans to release an update on this? Is there any workaround?

year and a half and still no progress, not even a comment :(

I know it's not solution, but I discovered another map package which supports ground overlays and many other things:
flutter_map
I didn't need google specific functionality for map, so I replaced them.

Maybe it will help someone....

Hi there!

I needed GroundOverlay in my project and implemented support for **Android**.
You are welcome to continue working on my forked repo to add iOS support

 URL

If you want to use GroundOverlay for Flutter Android now,
you can use the following dependency from the repository instead of the one from pub repo

google_maps_flutter:
__git:
____url: git@github.com:bytestreme/plugins_git.git
____path: packages/google_maps_flutter/google_maps_flutter/

Is there any update in groundoverlay feature in flutter please....

Plus one to this request. I would like to overlay a builds interior on the map.

+1 for this, @bytestreme great work on Android, but I (and others I believe) really need it on iOS as well. An official release would be great

It has been **4 years** waiting for this feature. We don't even have an estimate on when this will be addressed.

I have followed this feature request since the first issues and later PRs. After waiting for a while, I started using this fork from originally rejected PR #3420, It has been a while since I have been using it in production without any major issues. However, it would be great to have it on the official channel.

This is how you can give it a try installing in your pubspec.yaml:

 google_maps_flutter:
 git:
 url: URL
 path: packages/google_maps_flutter/google_maps_flutter/

I used it for showing geotiffs of irregular shapes with RGB data or single-band with transparency computed locally on the flutter side. Here are some examples. Unfortunately I can’t share the class geotiff handling the png encoding since I am not the owner.

<img width="1070" alt="image" src=" URL

@stuartmorgan have you some expectation about a date to implement this feature?

Any updates on this? Such functionality would be of major use for a great number of app ideas. I can understand that there is currently no bijection between the functionalities of the native ground overlays for Android and iOS, for example the fact that the iOS implementation has no constructor allowing the specification of a target location and a width. However, this is not something that basic math can't get around.

Some existing forks of the `plugins` library are of good quality in Android. However, iOS is still rather flaky and unsuitable for production code when attempting more powerful functionality.

Thanks again for all the hard work.

Is there something new on this issue? It would be really good if this is implemented in next releases.


Question: left right assertion failures on intel/nvidia hybrid gpu laptop.

Fixed the timing issues, which includes mp4 timing, so it should work without jank.

I'm going to close this issue, if you still see the frame corruption issues open a new issue. Thanks for all the help guys!

left right assertion failures on intel/nvidia hybrid gpu laptop.
Hi! I tried running wl-screenrec on my hardware but I consistently get the following errors on both my NVIDIA card and my integrated intel gpu:

bash
❯ ./wl-screenrec --dri-device /dev/dri/renderD129 -v
Using output eDP-1
[file @ 0x564a68e9ce00] Setting default whitelist 'file,crypto,data'
[AVHWDeviceContext @ 0x564a68e9d340] libva: VA-API version 1.18.0
[AVHWDeviceContext @ 0x564a68e9d340] libva: Trying to open /usr/lib/dri/iHD_drv_video.so
[AVHWDeviceContext @ 0x564a68e9d340] libva: va_openDriver() returns -1
[AVHWDeviceContext @ 0x564a68e9d340] libva: Trying to open /usr/lib/dri/i965_drv_video.so
[AVHWDeviceContext @ 0x564a68e9d340] libva: va_openDriver() returns -1
[AVHWDeviceContext @ 0x564a68e9d340] Failed to initialise VAAPI connection: -1 (unknown libva error).
thread 'main' panicked at 'assertion failed: `(left == right)`
 left: `-5`,
 right: `0`', src/avhw.rs:34:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[AVIOContext @ 0x564a68e9d180] Statistics: 0 bytes written, 0 seeks, 0 writeouts

If anyone can provide some context as to why this is occurring, I'd love to dig in deeper and provide more information.

The previous logs were from ArchLinux. I tried the same on NixOS on my Intel Iris Xe card laptop and I get the exact same error.

Which GPU is renderD129? Could you post outputs of `ls -lah /dev/dri/by-path`, `lspci`, as well as `vainfo`? Also, does wf-recorder work in vaapi mode (`wf-recorder -c h264_vaapi -d /dev/dri/renderD129`)?

You cannot use vaapi on integrated nvidia graphics (or, I thought so, I had a hard time finding a reference that proved or disproved this), so I highly suggest you use the intel gpu for encode.

I do not have that machine with me right now so I will provide the above details for the intel Iris Xe card I have. I'll report back with the logs from the hybrid machine when I have it available again.

bash
~
❯ ls -lah /dev/dri/by-path
Permissions Size User Date Modified Name
lrwxrwxrwx@ 8 root 3 Jul 20:57  pci-0000:00:02.0-card -> ../card0
lrwxrwxrwx 13 root 3 Jul 20:05  pci-0000:00:02.0-render -> ../renderD128

bash
[nix-shell:~]$ lspci
00:00.0 Host bridge: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers (rev 01)
00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
00:04.0 Signal processing controller: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant (rev 01)
00:06.0 PCI bridge: Intel Corporation 11th Gen Core Processor PCIe Controller (rev 01)
00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01)
00:12.0 Serial controller: Intel Corporation Tiger Lake-LP Integrated Sensor Hub (rev 20)
00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller (rev 20)
00:14.2 RAM memory: Intel Corporation Tiger Lake-LP Shared SRAM (rev 20)
00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20)
00:15.0 Serial bus controller: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 (rev 20)
00:15.1 Serial bus controller: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1 (rev 20)
00:16.0 Communication controller: Intel Corporation Tiger Lake-LP Management Engine Interface (rev 20)
00:1c.0 PCI bridge: Intel Corporation Device a0be (rev 20)
00:1f.0 ISA bridge: Intel Corporation Tiger Lake-LP LPC Controller (rev 20)
00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)
00:1f.4 SMBus: Intel Corporation Tiger Lake-LP SMBus Controller (rev 20)
00:1f.5 Serial bus controller: Intel Corporation Tiger Lake-LP SPI Controller (rev 20)
01:00.0 Non-Volatile memory controller: Micron Technology Inc Device 5404 (rev 03)
02:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller (rev 01)

bash
[nix-shell:~]$ vainfo
Trying display: wayland
libva info: VA-API version 1.18.0
libva info: Trying to open /run/opengl-driver/lib/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib32/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /run/opengl-driver/lib/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Trying to open /usr/lib32/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i965_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

bash
[nix-shell:~]$ wf-recorder -c h264_vaapi -d /dev/dri/renderD128
selected region 0,0 0x0
[AVHWDeviceContext @ 0x7f4524005800] Failed to initialise VAAPI connection: -1 (unknown libva error).
Failed to create hw encoding device /dev/dri/renderD128:

Yeah, so you do not have a functional libva installation--I suggest you follow your distributions documentation on vaapi.

Oh I didn't consider that. Thanks for taking a look. I'll try to setup vaapi, use wf-recorder to check if it's working and then try wl-screenrec again.

I have setup vaapi and wl-screenrec works now. Thanks. However the colors look "washed out" and the overall quality is a little blurry which is odd. I see there's an issue about this in the repo so I will take a look at that.
Thanks for your help.

Do they look overall worse than wf-recorder? Keep in mind the default bitrate is rather low, as this is what I like (I prefer small file sizes over high quality), but feel free to increase it with the `--bitrate` parameter

I'll try that! The colors are actually significantly better than wf recorder but the blurriness remains

AMD GPU support
Hey i get this error when i try to use it with amd igpu

🄸 ganymede ~> RUST_BACKTRACE=full wl-screenrec
Using output eDP-1
Xlib: extension "DRI2" missing on display ":0".
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
[AVHWDeviceContext @ 0x55d28a6560c0] libva: /usr/lib/dri/radeonsi_drv_video.so init failed
[AVHWDeviceContext @ 0x55d28a6560c0] Failed to initialise VAAPI connection: 2 (resource allocation failed).
thread 'main' panicked at 'assertion failed: `(left == right)`
 left: `-5`,
 right: `0`', src/main.rs:767:13
stack backtrace:
 0: 0x55d2898cee70 - std::backtrace_rs::backtrace::libunwind::trace::h1d00f3fcf4cb5ac4
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
 1: 0x55d2898cee70 - std::backtrace_rs::backtrace::trace_unsynchronized::h920a6ff332484ee2
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
 2: 0x55d2898cee70 - std::sys_common::backtrace::_print_fmt::hd7323920c925af6d
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/sys_common/backtrace.rs:65:5
 3: 0x55d2898cee70 - ::fmt::h3155a8c966b4beb5
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/sys_common/backtrace.rs:44:22
 4: 0x55d2898eb94e - core::fmt::write::h062c617411b691df
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/core/src/fmt/mod.rs:1209:17
 5: 0x55d2898cc935 - std::io::Write::write_fmt::hb61fdf1275c61e1c
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/io/mod.rs:1682:15
 6: 0x55d2898cec35 - std::sys_common::backtrace::_print::hd1b4d9664ab500e0
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/sys_common/backtrace.rs:47:5
 7: 0x55d2898cec35 - std::sys_common::backtrace::print::hca896ae22beb06cb
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/sys_common/backtrace.rs:34:9
 8: 0x55d2898d04ef - std::panicking::default_hook::{{closure}}::h0b5eeed5cf36ab5f
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:267:22
 9: 0x55d2898d022a - std::panicking::default_hook::h8932b573145a321b
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:286:9
 10: 0x55d2898d0be8 - std::panicking::rust_panic_with_hook::h4b1447a24e3e94f8
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:688:13
 11: 0x55d2898d0987 - std::panicking::begin_panic_handler::{{closure}}::h8701da9995a3820c
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:579:13
 12: 0x55d2898cf31c - std::sys_common::backtrace::__rust_end_short_backtrace::hb696c5ed02a01598
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/sys_common/backtrace.rs:137:18
 13: 0x55d2898d06a2 - rust_begin_unwind
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:575:5
 14: 0x55d28982cc53 - core::panicking::panic_fmt::h8aa706a976963c88
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/core/src/panicking.rs:65:14
 15: 0x55d2898eabeb - core::panicking::assert_failed_inner::h3c3fae67130f6d6f
 16: 0x55d28982a24b - core::panicking::assert_failed::hb8d58c1ba4efd32a
 17: 0x55d28983fe06 - wl_screenrec::State::start_if_output_probe_complete::hdfdb73a7e409d7d4
 18: 0x55d28983e058 - >::event::h60a3a4608687ec1f
 19: 0x55d289846952 - wayland_client::event_queue::queue_callback::h8d386cc6546cff38
 20: 0x55d28984784a - wayland_client::event_queue::EventQueue ::dispatch_pending::h0b0717127d7c09df
 21: 0x55d289847d87 - wayland_client::event_queue::EventQueue ::blocking_dispatch::he196364748bcac03
 22: 0x55d28984160e - wl_screenrec::main::h8ddb69fd9753ba1f
 23: 0x55d289830763 - std::sys_common::backtrace::__rust_begin_short_backtrace::h69401c9006f76632
 24: 0x55d2898369b9 - std::rt::lang_start::{{closure}}::h11dce253789bb3c0
 25: 0x55d2898c8b9b - core::ops::function::impls:: for &F>::call_once::h8cbb48ae40ddb046
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/core/src/ops/function.rs:286:13
 26: 0x55d2898c8b9b - std::panicking::try::do_call::h92db802eb38b49b7
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:483:40
 27: 0x55d2898c8b9b - std::panicking::try::ha8949d2082cf3644
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:447:19
 28: 0x55d2898c8b9b - std::panic::catch_unwind::h5e34c1f8a5992ed9
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panic.rs:137:14
 29: 0x55d2898c8b9b - std::rt::lang_start_internal::{{closure}}::hea52a0bb3f8ff16a
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/rt.rs:148:48
 30: 0x55d2898c8b9b - std::panicking::try::do_call::h5bc358faf3d68a8b
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:483:40
 31: 0x55d2898c8b9b - std::panicking::try::h675304212928379d
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:447:19
 32: 0x55d2898c8b9b - std::panic::catch_unwind::h7ce3ad349ed5c844
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panic.rs:137:14
 33: 0x55d2898c8b9b - std::rt::lang_start_internal::hcd7e45acd25ab5ab
 at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/rt.rs:148:20
 34: 0x55d289843ed5 - main
 35: 0x7f35c843c290 -
 36: 0x7f35c843c34a - __libc_start_main
 37: 0x55d28982cf95 - _start
 at /build/glibc/src/glibc/csu/../sysdeps/x86_64/start.S:115
 38: 0x0 -

output of vainfo:

🄸 ganymede ~ [101]> vainfo
Trying display: wayland
vainfo: VA-API version: 1.17 (libva 2.17.1)
vainfo: Driver version: Mesa Gallium driver 22.3.3 for AMD Radeon Graphics (renoir, LLVM 14.0.6, DRM 3.49, 6.1.5-arch2-1)
vainfo: Supported profile and entrypoints
 VAProfileMPEG2Simple : VAEntrypointVLD
 VAProfileMPEG2Main : VAEntrypointVLD
 VAProfileVC1Simple : VAEntrypointVLD
 VAProfileVC1Main : VAEntrypointVLD
 VAProfileVC1Advanced : VAEntrypointVLD
 VAProfileH264ConstrainedBaseline: VAEntrypointVLD
 VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
 VAProfileH264Main : VAEntrypointVLD
 VAProfileH264Main : VAEntrypointEncSlice
 VAProfileH264High : VAEntrypointVLD
 VAProfileH264High : VAEntrypointEncSlice
 VAProfileHEVCMain : VAEntrypointVLD
 VAProfileHEVCMain : VAEntrypointEncSlice
 VAProfileHEVCMain10 : VAEntrypointVLD
 VAProfileHEVCMain10 : VAEntrypointEncSlice
 VAProfileJPEGBaseline : VAEntrypointVLD
 VAProfileVP9Profile0 : VAEntrypointVLD
 VAProfileVP9Profile2 : VAEntrypointVLD
 VAProfileNone : VAEntrypointVideoProc

I have similar error, after running `wl-screenrec`:

Using output eDP-1
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
[AVHWDeviceContext @ 0x5590fb0ac040] libva: /usr/lib/dri/radeonsi_drv_video.so init failed
[AVHWDeviceContext @ 0x5590fb0ac040] Failed to initialise VAAPI connection: 2 (resource allocation failed).
thread 'main' panicked at 'assertion failed: `(left == right)`
 left: `-5`,
 right: `0`', src/main.rs:767:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

OS: Arch Linux x86_64
Window Manager: Sway Wayland only mode
Host: 82B1 Lenovo Legion 5 15ARH05H
CPU: AMD Ryzen 7 4800H with Radeon Graphics (16) @ 2.900GHz
GPU: AMD ATI 06:00.0 Renoir
GPU: NVIDIA GeForce GTX 1660 Ti Mobile

I have installed
libva
libva-mesa-driver
libva-vdpau-driver
vulkan-radeon
mesa-vdpau

Thanks for the reports. Could I get the output of

strace wl-screenrec

and the output of

strace vainfo --display drm --device /dev/dri/card0

Also, if /dev/dri/card0 isn't you amd gpu, set `--dri-device=/dev/dri/cardx` of `wl-screenrec`

Okay, I think I know what's going on. Can I see

vainfo --display drm --device /dev/dri/renderD128

`strace wl-screenrec`: URL
`strace vainfo --display drm --device /dev/dri/card0`: URL

🄸 ganymede ~> vainfo --display drm --device /dev/dri/renderD128
Trying display: drm
vainfo: VA-API version: 1.17 (libva 2.17.1)
vainfo: Driver version: Mesa Gallium driver 22.3.3 for AMD Radeon Graphics (renoir, LLVM 14.0.6, DRM 3.49, 6.1.5-arch2-1)
vainfo: Supported profile and entrypoints
 VAProfileMPEG2Simple : VAEntrypointVLD
 VAProfileMPEG2Main : VAEntrypointVLD
 VAProfileVC1Simple : VAEntrypointVLD
 VAProfileVC1Main : VAEntrypointVLD
 VAProfileVC1Advanced : VAEntrypointVLD
 VAProfileH264ConstrainedBaseline: VAEntrypointVLD
 VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
 VAProfileH264Main : VAEntrypointVLD
 VAProfileH264Main : VAEntrypointEncSlice
 VAProfileH264High : VAEntrypointVLD
 VAProfileH264High : VAEntrypointEncSlice
 VAProfileHEVCMain : VAEntrypointVLD
 VAProfileHEVCMain : VAEntrypointEncSlice
 VAProfileHEVCMain10 : VAEntrypointVLD
 VAProfileHEVCMain10 : VAEntrypointEncSlice
 VAProfileJPEGBaseline : VAEntrypointVLD
 VAProfileVP9Profile0 : VAEntrypointVLD
 VAProfileVP9Profile2 : VAEntrypointVLD
 VAProfileNone : VAEntrypointVideoProc

Okay, I anticipate that `wl-screenrec --dri-device /dev/dri/renderD128` might work?

If so, I can make it use that device by default

nope,

🄸 ganymede ~> wl-screenrec --dri-device /dev/dri/renderD128
Using output eDP-1
[h264_vaapi @ 0x5620833caa40] No usable encoding entrypoint found for profile VAProfileH264High (7).
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ffmpeg::Error(38: Function not implemented)', src/main.rs:684:39
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

vainfo --display drm --device /dev/dri/renderD128

Trying display: drm
vainfo: VA-API version: 1.17 (libva 2.17.1)
vainfo: Driver version: Mesa Gallium driver 22.3.3 for AMD Radeon Graphics (renoir, LLVM 15.0.7, DRM 3.49, 6.1.5-arch2-1)
vainfo: Supported profile and entrypoints
 VAProfileMPEG2Simple : VAEntrypointVLD
 VAProfileMPEG2Main : VAEntrypointVLD
 VAProfileVC1Simple : VAEntrypointVLD
 VAProfileVC1Main : VAEntrypointVLD
 VAProfileVC1Advanced : VAEntrypointVLD
 VAProfileH264ConstrainedBaseline: VAEntrypointVLD
 VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
 VAProfileH264Main : VAEntrypointVLD
 VAProfileH264Main : VAEntrypointEncSlice
 VAProfileH264High : VAEntrypointVLD
 VAProfileH264High : VAEntrypointEncSlice
 VAProfileHEVCMain : VAEntrypointVLD
 VAProfileHEVCMain : VAEntrypointEncSlice
 VAProfileHEVCMain10 : VAEntrypointVLD
 VAProfileHEVCMain10 : VAEntrypointEncSlice
 VAProfileJPEGBaseline : VAEntrypointVLD
 VAProfileVP9Profile0 : VAEntrypointVLD
 VAProfileVP9Profile2 : VAEntrypointVLD
 VAProfileNone : VAEntrypointVideoProc

wl-screenrec --dri-device /dev/dri/renderD128

Using output eDP-1
[h264_vaapi @ 0x5647a3015980] No usable encoding entrypoint found for profile VAProfileH264High (7).
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ffmpeg::Error(38: Function not implemented)', src/main.rs:684:39
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Does `ffmpeg -vaapi_device /dev/dri/renderD128 -f lavfi -i rgbtestsrc=duration=5:size=1280x720:rate=30 -vf hwupload,crop=100:100:200:200,scale_vaapi=format=nv12:w=100:h=100 -c:v h264_vaapi testout.mp4` work?

`ffmpeg -vaapi_device /dev/dri/renderD128 -f lavfi -i rgbtestsrc=duration=5:size=1280x720:rate=30 -vf hwupload,crop=100:100:200:200,scale_vaapi=format=nv12:w=100:h=100 -c:v h264_vaapi testout.mp4`

ffmpeg version n5.1.2 Copyright (c) 2000-2022 the FFmpeg developers
 built with gcc 12.2.0 (GCC)
 configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librav1e --enable-librsvg --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-version3 --enable-vulkan
 libavutil 57. 28.100 / 57. 28.100
 libavcodec 59. 37.100 / 59. 37.100
 libavformat 59. 27.100 / 59. 27.100
 libavdevice 59. 7.100 / 59. 7.100
 libavfilter 8. 44.100 / 8. 44.100
 libswscale 6. 7.100 / 6. 7.100
 libswresample 4. 7.100 / 4. 7.100
 libpostproc 56. 6.100 / 56. 6.100
Input #0, lavfi, from 'rgbtestsrc=duration=5:size=1280x720:rate=30':
 Duration: N/A, start: 0.000000, bitrate: N/A
 Stream #0:0: Video: rawvideo (RGBA / 0x41424752), rgba, 1280x720 [SAR 1:1 DAR 16:9], 30 tbr, 30 tbn
Stream mapping:
 Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (h264_vaapi))
Press [q] to stop, [?] for help
[h264_vaapi @ 0x556510bae6c0] No quality level set; using default (20).
[h264_vaapi @ 0x556510bae6c0] Driver does not support some wanted packed headers (wanted 0xd, found 0).
[h264_vaapi @ 0x556510bae6c0] Driver does not support packed sequence headers, but a global header is requested.
[h264_vaapi @ 0x556510bae6c0] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).
Output #0, mp4, to 'testout.mp4':
 Metadata:
 encoder : Lavf59.27.100
 Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), vaapi(progressive), 100x100 [SAR 16:9 DAR 16:9], q=2-31, 30 fps, 15360 tbn
 Metadata:
 encoder : Lavc59.37.100 h264_vaapi
frame= 150 fps=0.0 q=-0.0 Lsize= 5kB time=00:00:04.96 bitrate= 8.9kbits/s speed=14.3x
video:4kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 36.048229%

 URL

wl-screenrec --low-power=off

Using output eDP-1
[h264_vaapi @ 0x5618377f29c0] Driver does not support some wanted packed headers (wanted 0xd, found 0).
[h264_vaapi @ 0x5618377f29c0] Driver does not support packed sequence headers, but a global header is requested.
[h264_vaapi @ 0x5618377f29c0] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).
3 fps
[avi @ 0x561837595680] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 292 >= 292
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ffmpeg::Error(22: Invalid argument)', src/main.rs:757:55
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

And then I tried second time and it worked
[roland@blackrainbow ~]$ wl-screenrec --low-power=off

Using output eDP-1
[h264_vaapi @ 0x560869f3f580] Driver does not support some wanted packed headers (wanted 0xd, found 0).
[h264_vaapi @ 0x560869f3f580] Driver does not support packed sequence headers, but a global header is requested.
[h264_vaapi @ 0x560869f3f580] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).
3 fps
56 fps
10 fps
16 fps
46 fps
38 fps
80 fps
45 fps
2 fps
10 fps
10 fps
2 fps
2 fps
3 fps
5 fps
9 fps

Awesome. I've seen that non monotonically increasing error before as well, I'm not entirely sure why it happens. I think I should probably just discard frames that end up having a higher PTS, but I'm not sure why wlroots is not giving increasing timestamps.

There's still a bug with --low-power=auto (the default), and I think I have an idea

Okay, latest should be able to auto-detect the low_power setting properly, as well as discarding non-monotonic frames

Interesting. Does the shell matter in the quality of the recording? bash vs fish
 URL

I can't imagine why it would. I get an error opening that URL....

I'm pretty sure that it's a side effect of the non monotonic DTS thing--you probably missed an IDR. I'll see if I can figure it out. Certainly not a function of your shell


Question: 🚀 Feature: publish: :push action?

That's right.

Yep, spread them out to where they belong, and leave their management up to their respective owners.

I am again a bit confused by the wording "catalog repo". :) There should be no catalog repo. You should have catalog-info files spread out all across your version control system, and the catalog (the catalog SERVICE, running in your infrastructure) holds a list of URLs pointing to those files. It updates its internal state all the time, in the background, based on the contents of those files.

If an end user changes a catalog-info file in their own repo, that's already registered in the catalog backend, there's no more action to take. You don't re-register. A short while later, the updated info will just automatically be reflected in the catalog.

🚀 Feature: publish: :push action
### 🔖 Feature description

add publish:\ :push to the list of built-in action

### 🎤 Context

As a user who adding API (or any other component) to my service catalogue - I want to have the option to do this via UI.
Creating a new git repository for each new entity seems wasteful, so I want to have a single repository for all configs.
Creating yaml files manually and registering them via a direct link is tiring.
I want to push a new yaml file directly to the branch and be able to register entity in catalog immediately after creation.

template example:

 steps:
 - id: fetch-base
 name: Fetch Base
 action: fetch:template
 input:
 url: ./content
 values:
 name: ${{ parameters.name }}

 - id: publish
 name: Publish
 action: publish:github:push
 input:
 branch: master
 targetPath: some/path
 repoUrl: ${{ parameters.repoUrl }}

 - id: register
 name: Register
 action: catalog:register
 input:
 repoContentsUrl: ${{ steps['publish'].output.repoContentsUrl }}
 catalogInfoPath: 'some/path/catalog-info.yaml'

### ✌ Possible Implementation

_No response_

### 👀 Have you spent some time to check if this feature request has been raised before?

- [X] I checked and didn't find similar issue

### 🏢 Have you read the Code of Conduct?

- [X] I have read the Code of Conduct

### Are you willing to submit PR?

None

I would recommend looking into the `publish:github:pull-request` action instead, which would allow you create pull requests for each entity definition.

If you go to your backstage instance, `/create/actions` you should be able to see the options that you can pass into the action in the template definition.

Thank you for the answer, but the main idea here is not to leave backstage UI during updates. Do not interact with other services like github to merge PR

My point about this is described in a bit more detail at: URL

I'm wondering if this use case is better served by directly communication with the GitHub APIs from the client, rather than using the scaffolder? Bit in line with how the `catalog-import` client creates PRs.

I have the same problem. Do we have an update on publishing to a GitHub Folder? ... without having to create a new repo or manually merge a pull request?

🚀 Feature: Possibility to update entities via UI
### 🔖 Feature description

As a user, I want to be able to update entities' data via backstage UI

### 🎤 Context

When working with backstage, to add a link or relation or update some fields of entity - you need to manually update yaml file.
Editing entities via UI will make work with a backstage much more user-friendly. You will not need to edit data in the database (git repo in this case) directly.

### ✌ Possible Implementation

Backstage already have "view yaml" for the entity feature.
Few forms can be implemented to update common fields like description or links. On form submission - new yaml will override existing in the git repo and in backstage's database.

### 👀 Have you spent some time to check if this feature request has been raised before?

- [X] I checked and didn't find similar issue

### 🏢 Have you read the Code of Conduct?

- [X] I have read the Code of Conduct

### Are you willing to submit PR?

None

Hi!

This can be done in a couple different ways. For data in a version control system, ultimately the end result has to either be a push, or a pull request. That involves making requests using the relevant client library, eg octokit for the case of github. We have the helpers to get the auth set up for that so that it happens on behalf of the actual user performing the action, so that's good. You could make a web interface either for targeted actions as you mention, or in the form of a full YAML editor that helps you do validation and get the indentation right and all of that jazz.

Separate to this, there's an entire track to explore of having direct editor support, as in, building vscode / intellij plugins and thinking about leveraging schemas and/or querying the catalog for automatic validation as you type, and stuff like that.

Ping @taras here for info - these are topics that may be of interest to him, and to the Adoption SIG work that's underway.

Thank you for the answer.
I understand, that I can do it on my own, but I want it to be a part of backstage and available out of the box.

Also, if backstage will support some database as a source of truth backend (not git), it will be very helpful for decoupling from code, easy migrations, and consistency checks.
E.g.: specify postgres as the source backend for storing entities. Add action in templates for entity creation. Implement CRUD API and interfaces for entity management directly in the backstage app. Implement entity provider to sync with the core database.

Disclaimer: I still understand, that all this is possible to do on my own, but I won't be able to support it on my own :)

about

It is nice to have this, but still, this requires some third-party tool to work with backstage. And my point is that backstage should be self-sufficient and user friendly

Hi!

We've built something like this internally for our Bitbucket repos:
- a Yaml Editor that is filled with the catalog-info.yaml content from the repo (using monaco-yaml: URL
- an endpoint within Backstage that outputs a dynamic JSON Schema based on the whole Backstage catalog data for the different entity types - therefor offering then some predefined Enums and autocomplete functionality to e.g. easier define the correct component name in the dependencies as well as to have some validation like the inbuilt Backstage restrictions e.g. metadata.name must have a certain format
- a save functionality that creates a pull request with the changes

I was thinking about open sourcing it, but there would be needed to do some generalization, since we have some specific scenarios just for us in there right now and it's all put together in one plugin. Might be considering to split the above mentioned functionalites up a bit into seperate plugins and have an "Editor" plugin, that can offers some extendable functionality so other plugins could integrate their own saving logic. There is probably quite a lot to consider to have it generalized.

Here is a screenshot to easier grasp what we've done:
image

Thank you for the answer
It looks handy, but still not enough for backstage to be an independent tool for all team (not only developers)
Thanks for the link, I will try it. But if you decide to implement CUD UI for entities - I would like to use it.

BTW, backstage is really cool and powerful tool, but a bit complex sometimes

@belech I really appreciate your implementation details! I just found out about monaco-yaml from your suggestion and it looks awesome! We've been trying to build a custom template to download + merge yaml files together but it's not quite working out for us with multi yaml files.

@belech Awesome stuff. Any chance you open source your solution.

My company is also interested in this, i see this as one basic feature. And i really hope this will be implemented..

I'd be interested in hearing about end-to-end workflow descriptions. Those of you who expressed interest, how would you envision that this worked from start to finish?

Say you are an org with a couple hundred or thousand repos and teams. You want to start adopting Backstage. What would you like the journey to be like, for your end users to start getting things into the catalog and get all of the right metadata into place, from that blank slate? How would permissions and the lifecycle of things work?

On the company that i work now, we divided the implementation on stages...

- 1 Stage (we are on this stage right now BTW):
Techdocs + Software Catalog + Users + Groups
We took 2 teams and they are in-charge to catalog and adding they own entities on a catalog repository.

- 2 Stage:
Expand from 2 teams to a tribe.

- 3 Stage:
Expand to all our 6 tribes.

- 4 Stage:
Implementing software templates, CI-CD, centralize all the solicitations of services on backstage.

For now. Stage 1 we encounter some issues.
Th adoption is running really slow, the dev's must clone the backstage service as well the catalog, running both on the machine and fixing entity errors... THEN creating a branch, making a pull request, and other team testing and validating if the PR is ok.
In the future all this entities must have some changes, updates etc.. and this process is slow and not that user intuitive even for the dev's.

Will be really nice to have a interface to help with..

I imagine working something like this..
1 - Developer logging on backstage.
2 - He have a button to CREATE a entities (user, system, api etc..) OR he can select a existing one and just editing that.
3 - The interface will be very similar to CREATE or UPDATE a entities.
will be nice if this will be a complete interface, with selects for choosing TEAMS, APIS from other entities, like form interface, maybe using the entities APIS to bring existing data of the database, like: "i'm creating a new API, this api has a part on a System, or consumes other api, is own by the the team" something like this..
4 - the dev click on save, then backstage makes sure that the entity is all ok.
5 - The dev save the changes directly on the YAML file and the database,( or only the database)

OR maybe like this..

1 - Developer logging on backstage.
2 - He have a button to CREATE a entities (user, system, api etc..) OR he can select a existing one and just editing that.
3 - Brings him to a online text editor, so he can make the changes, with help of ta intelisense, auto-complete, with all the tools need to facilitate this step.. if the user are Creating a new entities maybe given the option to use a template..
4 - the dev click on save, then backstage makes sure that the entity is all ok.
5 - The dev save the changes directly on the YAML file and the database,( or only the database)

On both cases i saw the permissions like this..
Devs/TechLeads can edit and create entities of their own SQUAD.
PrincipalEngineer can edit and create entities of multiple SQUADS from his tribe
Coordenators can edit and create entities of ALL tribes..

BTW all teams can SEE all the entities from other teams..

This is how i saw on the company that i work... maybe this will not be 100% to other people on this thread..

(i'm not native to English language so, forgive-me if i wrote something not 100% clear.. )

@belech I was inspired by your reference material and built a clone for myself to help learn React. That monaco-yaml library seems to force me into the low-level javascript event listeners and it felt very difficult to use React other than a way to import a component. Did you experience the same?

I dont know if I just lack some React experience, but for the life of me, l just couldnt get Jest to instrument the monaco-yaml editor.

What was really interesting about this effort was that I didnt realize monaco is the VSCode engine and that IDEs use language-server-protocols (LSP). So the monaco-yaml shims the YAML LSP built by Red Hat and so I built a rudimentary VSCode web editor for backstage files. Anyways, really cool experience!

@freben, I kind of like this plugin because I can reuse a full json schemastore which works beyond just backstage files. However, if I try to contribute this feature back, do you have any ideas where should it be located? I just threw mine on the left nav bar, but I'm wondering if it should be an optional drop-down where people typically select the github ingestion tool

I'm thinking abbot another suggestion..
When we use templates we can put the properties of the entity..
then we put the steps on the template.. to create new repo or push a file etc...

I wonder if is a great idea to use the templates as a structure to edit a entity..
the way i saw this, the editing page will be similar to the create template..
the editing fields will be the same fields as the create.
(if for some reason the editing has more fields, or some fields are different, this can be solved with dedicated template YAML, OR as a new parameters on the existing template. like "editing_parameters: " and "editing_steps:")

I know that backstage has a route to return a entity data, so the entity fields that are store on the database are display on this editing page. the UI can be customizable by using the "editing_parameters:" on the template..

After the user make the changes the entity can be validate and... if everything is right.. this will RUN the "editing_steps:"

For me this make sense, most of the tools to make this backstage have, like: route to validate a entity, steps to push files to a repo, and the UI..

On my take this is "basically" re-create the create page but using different parameters and steps or even a different template.yaml, the KIND and TYPE on the entity will be the key to determine what "editing template" to use...
And the steps will be customizable to.. almost the same as the normal template.

this make sense?
(English isn't my main language, so feel free to ask something)

This is something very useful for me because I'm importing some resource from external sources like rabbit exchanges and queues but these resources doesn't have any additional information like tags or customized field. In this case all my resources goes to same owner, for example. That would be great if we had a tool to edit these components after the importing.

I have created a plugin which goes into this direction but I'm still testing it internal so consider it alpha.
 URL


Question: Correção de Estilização na Página de Horóscopo?

Correção de estilo concluída e integrada à branch develop.
feature da tarefa: Feature/correcao estilo

Correção de Estilização na Página de Horóscopo
Descrição: Esta tarefa foca na construção e implementação do conteúdo da tela do horoscopo do site, utilizando o design já estabelecido como referência.

figma: URL
documento: heavenly.pdf

@JosielSantos16 Além de criar uma nova página para redirecionamento individual de cada horóscopo de signo a partir da página principal de horóscopo, é necessário corrigir os espaçamentos entre os componentes e ajustar as fontes.

Fiz a implementação dessa tela e das outra e subi os commits, estou esperando a revisao

@JosielSantos16 a revisão dessa tarefa esta na tarefa de integração #32

Correção de Estilização
Descrição: Esta tarefa envolve a revisão e ajuste dos estilos das páginas existentes para corrigir erros de estilização, melhorar o layout e garantir uma apresentação visual consistente. As subtarefas incluem:

1. Correção de Espaçamentos:

 - Ajustar o espaçamento entre e ao redor dos componentes para garantir uma distribuição equilibrada e evitar que os elementos fiquem muito próximos das bordas ou entre si.

1. Ajuste de Estilos:

 - Modificar propriedades de CSS, como cores, fontes, tamanhos de texto e margens, para corrigir problemas visuais e garantir uma aparência uniforme em todas as páginas.

1. Verificação de Responsividade:

 - Garantir que as páginas estejam visualmente corretas e funcionais em diferentes tamanhos de tela, incluindo dispositivos móveis e desktops.

1. Correção de Outros Erros Visuais:

 - Identificar e resolver quaisquer problemas visuais adicionais que possam surgir nas telas de horóscopo, constelação e dúvidas comuns.

segue as subtarefas:

- [ ] #27
- [ ] #28
- [ ] #29

@JosielSantos16 Revisei os o código puxando para meu ambiente dev, esta muito bom as correções. Um ponto de atenção seria colocar mais detalhes de onde foi corrigido na tarefa, tipo imagens mostrando a correção e o erro de estilização referentes a cada pagina corrigida.


Question: Tighten the definition of "column"?

I left a comment now on the tc39 proposal. I hope for now that Firefox reverts this behavior but the issue is known from our side. Since not all Firefox versions agree on the offset it's unfortunately a pretty frustrating situation right now that we do not want to try to make too many guesses about.

Tighten the definition of "column"
The source map spec doesn't describe the units for columns -- just that they are zero-based. It turns out that Gecko uses UTF-16 code points, and that seems to be a common, but not universal, choice. It would improve the spec if it were explicit about the units.

I would like to revisit this. Firefox today is the only engine that does not use UTF-16 codepoints and apparently switched at one point at random. I would propose to once and for all specify this to mean UTF-16 as this matches what _most_ tools today assume.

* URL
* URL

So here are some of my findings. Take this file:

html

 Column Test

function fail() {
 throw new Error();
}

function logColumn(c, e) {
 const lines = e.stack.split(/\r?\n/g);
 if (lines[0] === 'Error') {
 lines.shift();
 }
 console.log(c, parseInt(lines[1].match(/:\d+:(\d+)/)[1]));
}

try {
 /* xxxxx */fail();
} catch (e) {
 logColumn("x", e);
}
try {
 /* ☃☃☃☃☃ */fail();
} catch (e) {
 logColumn("☃", e);
}
try {
 /* 🔥🔥🔥🔥🔥 */fail();
} catch (e) {
 logColumn("🔥", e);
}
try {
 /* 👩👩👧👩👩👧👩👩👧👩👩👧👩👩👧 */fail()();
} catch (e) {
 logColumn("👩👩👧", e);
}

The calculated offsets of the `throw` keyword are the following (utf-8 offset, utf-16 offset, unicode character offset):

/* xxxxx */: 14/14/14
/* ☃☃☃☃☃ */: 39/19/19
/* 🔥🔥🔥🔥🔥 */: 29/19/14
/* 👩👩👧👩👩👧👩👩👧👩👩👧👩👩👧 */: 99/49/34

What browsers report:

**Safari:**
* x – 18
* ☃ – 23
* 🔥 – 23
* 👩👩👧 – 53

**Firefox:**
* x 14
* ☃ 19
* 🔥 14
* 👩👩👧 34

**Chrome:**
* x 14
* ☃ 19
* 🔥 19
* 👩👩👧 49

**Edge:**
* x 14
* ☃ 19
* 🔥 19
* 👩👩👧 49

**Node:**

* x 14
* ☃ 19
* 🔥 19
* 👩👩👧 49

Really nice data and +1 for the set of test cases! Since Chrome/Edge/Node/Deno are all V8 under the hood, their consistent behavior is expected. I'm pretty sure the JS engines populate this property without involvement (by default) from embedding runtimes/browsers. It's really:

* V8 (UTF-16)
* JavaScriptCore (UTF-16 + "what's a call site" 4)
* Spidermonkey (UTF-32)

So no two engines actually agree in this case, although V8 and JavaScriptCore disagree on something not related to column offset calculations.

Btw, I'm not sure if it's still maintained but eshost-cli could be a nice way of running these test cases across runtimes: URL If nothing else, the page with Supported Hosts is a nice potential checklist.

Given that this is mostly determined by browsers I will skip evaluating what the generators currently output. From my experience at processing a lot of source maps at Sentry, the general consensus is pretty strong for it to be counted in UTF-16 offsets.

If someone is available to volunteer, it'd be great to see this analysis of generators. The goal is to get in the habit of testing sourcemap generators anyway, so we can file bugs against them and get everyone aligned. Also this is something of an edge case, so I wouldn't be shocked to see someone who we should already file a bug against (as soon as we agree on the definition)--so this testing should be directly useful for that.

I tried but I have not found a place in the browsers where columns are displayed for CSS source maps, thus I was unable to determine based on observation in the browser how columns are handled. However libsass produces UTF-16 columns:

**foo.scss**

css
body {
 /*🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥*/background:/*🔥*/red;
 /*🔥🔥🔥*/color:/*🔥*/blue;
}

**foo.css**

css
body{background:red;color:blue}/*# sourceMappingURL=foo.css.map */

**foo.css.map**

json
{"version":3,"sourceRoot":"","sources":["foo.scss"],"names":[],"mappings":"AAAA,KAC8B,eAClB","file":"foo.css"}%

Decoded:

 0:0 -> foo.scss:0:0
 0:5 -> foo.scss:1:30
 0:20 -> foo.scss:2:12

If you look at the tokens referenced:

1:30 -> background:/*🔥*/red;
2:12 -> color:/*🔥*/blue;

It's possible you could do it in Firefox by having CSS that uses non-base-plane characters and then provokes a warning later on the same line. Then, look at the warning in the console. IIRC (it's been a while) the devtools will apply source maps in this case.

To drive this discussion forward, here is my proposal of what should be added to the spec:

Yes. I consider this closed. We can follow up on other formats if the need arises.

I think we were still waiting to hear back from some folks about WASM? I'm happy to close this an open a separate ticket for that since the above PR has been merged.

The PR for the wasm columns definition: tc39/source-map-spec#14

Sourcemap locations may be resolved incorrectly in Firefox
Please consider this issue an FYI for other Sentry users as much as anything else, since I think the fix will happen in Firefox.

We recently ran into a problem where JavaScript crash reports from Firefox were resolved to the wrong location in the original code. The issue turned out to be that Firefox expresses column numbers in stack traces differently than other browsers. Chrome and Safari report the column number in UTF-16 code units, whereas Firefox reports them in Unicode code points. From what I can tell, this package assumes UTF-16 code units. If a minified source bundle contains many characters (eg. emojis) that require multiple UTF-16 characters to encode, this can result in incorrectly resolved source locations when processing crash reports in Firefox.

I filed an issue at URL and URL to try to find an upstream resolution.

Seems like this is already fixed, feel free to reopen if that is not the case.


Question: Create a preprocessing step to use defaults, validate input data, and calculate flow partitions?

Here's a version of the 1st one, the user workflow. It includes functions that don't exist, and I haven't followed the current situation of the workflow, but it should be enough to evaluate the solution.
Tulipa User Workflow-2.pdf

Create a preprocessing step to use defaults, validate input data, and calculate flow partitions
### Description

As in the Tulipa-OBZ-CaseStudy, we start with the bare minimum input data and then move on to the tables we need to create the model. Having these steps inside Tulipa will help improve the users' experience and avoid data that generates incorrect constraints (e.g., the flow partitions must be inferred from the asset partitions).

### Sub issues

- [ ] Create the minimum input data (mandatory) files/tables an user must provide
- [ ] Create a validation function to check #461
- [x] #1129
- [ ] #1052

@abelsiqueira This is the issue we commented on in yesterday's meeting. Please add/change according to what you also consider needed here. There are new functions in TulipaIO that can be used for the preprocessing step.

@clizbe I think this will be nice to have before TLC starts, but if not, we can still work with the model as it is. Please also add/change as you consider in this issue.

Hi @datejada, I'm not sure about the other bullet points. But I will work on creating the data validation #461 skeleton. Perhaps the flow partition inference can be part of that, but that could be a separate step as well. Please tag me when you define how the inference will work and I'll try to see where it fits

I'll try to pick up the flow partitions since it sounds fun and I know there's already a version in OBZ. ;)

I believe it's for the User Format. And the Model Format will either fill the defaults or leave things blank if unused. 🤔

@abelsiqueira and @clizbe The more I explain the model to people/users, the more it feels better to have files/tables with the bare minimum data (i.e., the primary keys of the tables) + some values to run the model and then fill the non-specified data with the defaults that we defined in the JSON (third point in the list) to create the Tulipa tables.

One first step is to have the same file schema but fill in the non-mandatory data that has not been specified with the defaults defined in the JSON. That would already remove many data from users to fill in (and even from our example files).

A second step would be to decide whether these files are closer to the current User Files in the OBZ. That can be later based on the feedback we get in the TLC.

I think we need to sit together to review the workflow and align this point. It also affects #415, and defines where this code will live and how TulipaIO and TulipaClustering interact TEM.

Create a diagram of the workflow
Create a diagram to help describe all steps and inputs of the workflow.

#### Related Issues:
#414

---

Last update: 27/06/2024

I've split the diagram into two parts. One for the pipeline and one for the DBs. They are both still WIP, and the DBs are mostly just showing the keys.

## High level overview of compact usage

mermaid
graph
 classDef db fill:#aaa,color:black,stroke:black,stroke-width:1px;
 classDef cls_tem fill:#0af,color:black;
 classDef cls_tio fill:#fc0,color:black;
 classDef cls_tc fill:#0f0,color:black;

 source["Some source (e.g. ESDL + EDR, CSV folder)"]:::db

 %% DBs/DataFrames
 initial_data[(Initial data)]:::db
 clustering_data[(Clustering data)]:::db

 %% Connections
 source --> TIO.read_csv_folder:::cls_tio
 --> initial_data
 --> TC.split_into_periods:::cls_tc
 --> TC.find_representative_periods:::cls_tc
 --> TC.write_clustering_results_to_tables:::cls_tc
 --> clustering_data
 --> TEM.EnergyProblem:::cls_tem
 --> TEM.create_model!:::cls_tem
 --> TEM.solve_model!:::cls_tem

mermaid
graph
 classDef db fill:#222,color:white,stroke:white,stroke-width:1px;
 classDef object fill:#09f,color:black;
 classDef cls_tem fill:#3d3,color:black;
 classDef cls_tio fill:#77f,color:black;
 classDef cls_tc fill:#77f,color:black;
 classDef undefined fill:#f33,color:black;

 source["Some source (e.g. ESDL + EDR, CSV folder)"]
 scenario["Scenario specification ?"]:::undefined

 %% Actions and packages
 TIO("TulipaIO"):::cls_tio
 TEM("TulipaEnergyModel"):::cls_tem
 TC("TulipaClustering"):::cls_tc
 TP("Partitioner"):::undefined
 create_input_dataframes("create_input_dataframes"):::cls_tem
 create_internal_structures("create_internal_structures"):::cls_tem
 compute_constraints_partitions("compute_constraints_partitions"):::cls_tem
 create_model("create_model"):::cls_tem
 solve_model(solve_model):::cls_tem
 construct_dataframes(construct_dataframes):::cls_tem

 %% Objects
 con{{DB connection}}:::object
 table_tree{{table_tree}}:::object
 _graph{{graph}}:::object
 rps{{representative_periods}}:::object
 timeframe{{timeframe}}:::object
 cps{{constraints_partitions}}:::object
 dfs{{dataframes}}:::object
 model{{model}}:::object
 solution{{solution}}:::object

 %% DBs/DataFrames
 static_data[(Graph Data)]:::db
 raw_profiles_data[(Raw Profiles Data)]:::db
 cluster_data[(RP & Timeframe Cluster Data)]:::db
 clustered_profiles_data[(Clustered Profiles Data)]:::db
 partition_data[(Partitioned Data)]:::db

 %% Connections
 source --> TIO
 --> static_data & raw_profiles_data
 --> TC
 --> cluster_data & clustered_profiles_data
 scenario --> TP
 --> partition_data
 TIO --> con
 static_data & raw_profiles_data & cluster_data & clustered_profiles_data & partition_data --> create_input_dataframes
 --> table_tree
 --> create_internal_structures
 --> _graph & rps & timeframe
 _graph & rps --> compute_constraints_partitions
 --> cps
 _graph & rps & cps & timeframe --> construct_dataframes
 --> dfs
 _graph & rps & dfs & timeframe --> create_model
 --> model
 --> solve_model
 --> solution

The DB diagram is not automatically generated, here is a snapshot, the code is below.

TulipaDB

dbml
// Use DBML to define your database structure
// Docs: URL

// Types are limited to what is provided by SQL
Table Asset {
 asset string [primary key]
 extra_stuff unknown
}

Table Flow {
 from_asset string [primary key, ref: > Asset.asset]
 to_asset string [primary key, ref: > Asset.asset]
 extra_stuff unknown
}

Table Profile {
 profile_name string [primary key]
 timestep int [primary key]
 value float
}

Table AssetProfileReference {
 asset string [primary key, ref: > Asset.asset]
 profile_type string [primary key]
 profile_name string [ref: > Profile.profile_name]
}

Table FlowProfileReference {
 from_asset string [primary key, ref: > Flow.from_asset]
 to_asset string [primary key, ref: > Flow.to_asset]
 profile_type string [primary key]
 profile_name string [ref: > Profile.profile_name]
}

// ---------
// All DB above are used by Clustering. Everything below is Model specific
// ---------

Table RepPeriod {
 rep_period int [primary key]
 num_timesteps int
 resolution float
}

Table TimeframePeriod {
 period int [primary key]
 rep_period int [primary key, ref: > RepPeriod.rep_period]
 weight float
}

Table RepPeriodProfile {
 profile_name string [primary key, ref: > Profile.profile_name]
 rep_period int [primary key, ref: > RepPeriod.rep_period]
 profile_type string
 value float
}

Table TimeframeProfile {
 profile_name string [primary key]
 timestep int [primary key, ref: > TimeframePeriod.period]
 value float
}

Table AssetTimeframeProfileReference {
 asset string [primary key, ref: > Asset.asset]
 profile_name string [primary key, ref: > TimeframeProfile.profile_name]
}

Table AssetRepPeriodPartition {
 asset string [primary key, ref: > Asset.asset]
 rep_period int [primary key, ref: > RepPeriod.rep_period]
 specification enum
 partition string
}

Table FlowRepPeriodPartition {
 from_asset string [primary key, ref: > Flow.from_asset]
 to_asset string [primary key, ref: > Flow.to_asset]
 rep_period int [primary key, ref: > RepPeriod.rep_period]
 specification enum
 partition string
}

Table AssetTimeframePartition {
 asset string [primary key, ref: > Asset.asset]
 specification enum
 partition string
}

Is it normal that I have a "Unable to render rich display" error?

@abelsiqueira @suvayu Maybe this is a good candidate for a wiki? 🙃

Have we decided what use we'll be moving to the wiki? We have 6 places for prose right now:

- README.md
- README.dev.md
- CONTRIBUTING
- Docs = Website
- Issues
- Discussions

So it might be useful to redefine some things to give use to the wiki. Also, it is a good time to bring up URL since it relates to documentation and purpose.

Diataxis was a great read!
I agree we're spreading out a bit, but this is something that doesn't seem to really belong in an issue... Maybe it can go into the docs? Right now it's pretty dev-related, but eventually might be useful to the user.

@abelsiqueira Is there a way we can have this generate with code? That way we can put it in the docs without screenshotting it and keep it updated in the future (maybe add it to our PR checklist?)

Thinking like an engineer @clizbe ;-)

We could explore using `Mermaid.js`. It's supported by GitHub. You can experiment @ URL

Great! Let's use that. It'll probably take some work for the first version but updating after that shouldn't be bad.

For my purposes (figuring out what to implement in the refactor), I eventually moved to Miro and abandoned this.

However, it might be useful to have a visual explanation of how things work to some groups. Either for users or developers.
@clizbe @datejada @gnawin @suvayu , do you see any diagram that would be useful to have?

- For new users, it might be useful to have an overview of things, but not an overwhelming amount of info. Maybe the left side of the Miro board is enough?
- For devs, it might be useful to have an overview of the functions or structures being created. But since there is no way to automate this, as far as I know, it might be quickly obsolete if we go into too much detail. It there a level of usefulness? (This was the one I was trying to make to drive the refactor)
- A complete list of all the input tables should be useful for intermediate users. At least for the TEM side, this is part of the schema. What would be the useful thing that you want to extract from this?
- A list of tables created within TEM might be useful for developers, which is the (possibly outdated) info in the Miro board. What would be the useful thing that you want to extract from this?

I think we should have two overviews:
1. The workflow for the user:
 - Raw to Processing options, Where TC comes in, Where does DuckDB come in, User vs Model schema if we have both... Similar to what's above but some more processing options/details.
 - This could be a Mermaid thing or basically just a ppt slide
 - GOAL: Easy overview of the workflow without reading any code or opening a notebook.
2. The BASIC structure of the code.
 - This might just be the dev docs of how to add a constraint, or maybe a breakdown of the main files and how they relate to each other. Or maybe it's just TulipaEnergyModel.jl?
 - GOAL: Help new devs understand the flow of the code.

I'll work on a PR for these, but do you want them?

- Maybe 1. go to `docs/src/10-how-to-use.md`, in an overview at the beginning?
- Probably 2. should go to `docs/src/91-developer.md`, do you have a different suggestion?

For 1, I think maybe the Beginner Tutorials would be better... Although it is kind of a technical reference... 🤔
The idea with the docs flow for new users is they click on Getting Started (install), which sends them to Beginner Tutorials, and later they read the How-Tos. The How-Tos even has a note that says it expects they've already followed the Beginner Tutorials.

But yeah How-To definitely makes more sense. I think put it there and we can reference it from wherever.

I created the following for the 2nd point. What do you think? I also sent in the internal teams chat so others can comment.
TulipaEnergyModel overview.pdf

I think it's a good start for the guts of the model. But I was thinking even more zoomed out.
Basically:
Raw -> User Format -> Conversion -> Model Format -> TEM (maybe with these details, maybe include that it uses DuckDB for its storage) -> Solution (in Julia or DuckDB?) -> Manipulation (optional) -> Export -> More manipulation (optional) -> Graphs

And we can add details, but just to have the roadmap of what they're doing and where the tools come in.
Otherwise they might get confused on what each tool (TIO, TEM, DDB, etc) is for and what's happening.

I created it using Canva, after struggling to try to make 10% in 10x more time in Mermaid.

This raises the issue of which solution to use, code-based or gui-based. Here are some points:

- Code-based (Mermaid.js, GraphViz, TikZ, explicit plotting).
 Pros:
 - These should be better for incorporating in a (semi-)automated build script of the documentation.
 - It should be possible to ensure that it never gets outdated (but it is a lot of work).

 Cons:
 - It is hard to make them look nice. Sometimes impossible.
 - Any automation will require maintenance.
- GUI-based (Canva, Miro, app.diagrams.net, paint, etc.)
 Pros:
 - It is much easier to use, and therefore much easier to (re)create.
 - They look much nicer.

 Cons:
 - Reproducibility is an issue because there is no code, so modifications. are harder.
 - If using a service, it requires account management and sharing.

My recommendation would be GUI-based because it is the best tool for the job. Even the static code-based solution takes many hours to do half as right.

The method you're using looks great! :) Sounds like code is too much of a pain in this case.


Question: Unify tagging for mirroring and release stages?

[Triage] Closing as a duplicate of URL Even though this issue was logged first, URL has more detail.

Unify tagging for mirroring and release stages
Related to URL

Currently both mirroring and release stage are tagging the same build commit with the same tag and pushing it to a remote (mirroring to `dotnet-security-partners/dotnet`, release to the public `VMR`). They are also using two different scripts to achieve this.

We should unify this step under one logic to guarantee that we don't accidently change only one of them in the future, resulting in a miss-match between what we published publicly versus what we handed off to partners.

We could utilize the Release CLI for this by just adding a single command and using it in both stages.

Given this only affect 6.0 and 7.0 there is limited ROI. Additionally URL covers testing to ensure the tags are consistent. Consider closing as won't fix.

[Triage] Will use URL to track integrating this logic into the release CLI.

Look into additional validation for produced outputs
During the February release we discovered several issues with tags and some of the produced outputs (like `release.json`) and could've been caught before hand.

Maybe its worth investing into some additional validation at the end of the test/validation pipeline that would skim the produced outputs for some easy-to-catch issues, like empty or not expanded values. We already have unit tests covering some of the functionality that we have ported to the ReleaseCLI, but since we still use scripts / do substitutions from the pipeline, it might be worth the effort.

[Triage] As part of this, we should ensure the artifacts are identical as much as possible between the partner and GH releases.


Question: Bug with Window Covers in Matter/SmartThings/Google Home Integration?

🤦

Can you confirm that google home is always in sync with "target position" instead of "current position" ?
We don't have target position in home assistant, right? At least I don't have it. So i could sync target position with current position, but doesn't really make sense...

For ALL covers? As I mentioned earlier:
Matter open = 0% and close = 100%
HA open = 100% and close = 0%

Therefore I am inverting. Can you test using "open cover" command (without percentage) to verify that it's REALLY inverted?

Yes, but users could be confused by it, when trying to set the position to 30% in GH 😀

But isn't that a problem of the integration. If the cover supports it, shouldn't it be part of the cover entity?
Anyway I am already using/used it for covers. I just need to re-add it for non-position-aware covers.

To make it clear:
I don't have a problem with device based bridge, it's just a matter of effort vs. available time at the moment 😀

Bug with Window Covers in Matter/SmartThings/Google Home Integration
Here is how you can explain your issue on GitHub in English:

I have an issue with my window covers. These covers do not support percentage-based positioning; they only have commands for "up," "down," and "stop." To manage their state, I added a sensor that indicates whether they are open or closed.

I created a YAML configuration for these covers using the cover component with the generic platform.

On Homebridge and Home Assistant, everything works fine.

On Matter, SmartThings, or Google Home, the integration does not work properly.

However, when I use Google Home via the cloud, it works as expected.

It seems like the problem is specifically related to how the configuration or functionality is handled in Matter/SmartThings/Google Home locally.

volet_louis:
 friendly_name: "Volet Louis 2"
 position_template: "{{ (states('binary_sensor.lumi_lumi_sensor_magnet_aq2_opening_25') == 'off')|int * 100 }}"
 open_cover:
 service: cover.open_cover
 data:
 entity_id: cover.volet_louis
 close_cover:
 service: cover.close_cover
 data:
 entity_id: cover.volet_louis
 stop_cover:
 service: cover.stop_cover
 data:
 entity_id: cover.volet_louis

Can you describe what exactly is not working?
Can you share the attributes (Home Assistant -> dev tools -> state -> search for the entity) of the generic cover) ?
Are there any error logs in the addon?

image

Nothing works. In smartthings I have 3 buttons, open, close and stop and one position from 0 to 100%
Position is made by a sensor. When reach it's close.

` volet_bureau:
 friendly_name: "Volet Bureau 2"
 unique_id: VWoQmdAes2Y8wZ0fsM13
 position_template: "{{ (states('binary_sensor.lumi_lumi_sensor_magnet_aq2_opening_21') == 'off')|int * 100 }}"
 open_cover:
 service: cover.open_cover
 data:
 entity_id: cover.volet_bureau
 close_cover:
 service: cover.close_cover
 data:
 entity_id: cover.volet_bureau
 stop_cover:
 service: cover.stop_cover
 data:
 entity_id: cover.volet_bureau`

You don't need to fake the position attribute with a template on HA. Just keeping the open/closed state is sufficient.

"supported_feature" will be 3 then.

Because if you add position, then HA will add the set position command too.

- Do you see the cover in the matter web ui?
- If yes, do you **see** the cover in google home after pairing?
- If yes, what buttons do you see? What happens when you press them?

 Please answer **all** of the above questions, and attach the addon logs and your bridge configuration from within the matter web ui.

Yes but without a template i can't keep position when using cover trigger.

Yes
image

Yes
All button are grey. I can't interact with them. When using google home cloud integration it's ok

Smart blinds for me now show up only as UP and DOWN. In earlier versions I could set them at a specific height just like in home assistant.
I could even use google assistant to specify the exact number between 0 and 100 to state how much I wanted the blinds to be open.
Now there are just two options - fully open or fully closed.
Previously was better I think.

@t0bst4r maybe we need to consider the value of supported features. In my case in the state if the cover in HA it shows:

`supported_features: 11`

from here

 OPEN = 1
 CLOSE = 2
 SET_POSITION = 4
 STOP = 8
 OPEN_TILT = 16
 CLOSE_TILT = 32
 STOP_TILT = 64
 SET_TILT_POSITION = 128

so mine is 11 in binary is 1011

Then:

| Constant | Decimal Value | Binary Representation |
|---------------------|---------------|-----------------------|
| OPEN | 1 | 0000 0001 |
| CLOSE | 2 | 0000 0010 |
| SET_POSITION | 4 | 0000 0100 |
| STOP | 8 | 0000 1000 |
| OPEN_TILT | 16 | 0001 0000 |
| CLOSE_TILT | 32 | 0010 0000 |
| STOP_TILT | 64 | 0100 0000 |
| SET_TILT_POSITION | 128 | 1000 0000 |

My covers have OPEN, CLOSE and STOP, but not sure why it shows me just the percentage thing...

@Biohospitalix

Can you please verify if IPv6 is enabled in your local network?
Are your running HAOS with the addon, or do you run the docker image?

---

@digiolin

This is a different issue (#144), but it should be fixed with the latest version.

Yes I use IPv6 and Matterhub as an add-on.
This works in the Samsung app by doing this:
I indicate 0 or 100% closure and I start the predefined position (0 or 100) . This does not work by shutter when indicating open or close.
Screenshot_20241201_131638_SmartThings
Screenshot_20241201_131625_SmartThings

[Bug] Covers - positional and non-positional devices
Cover devices no longer seem to work with 3.0.0-alpha.32.

[ 2024-11-15T21:03:32.276Z ] [ INFO ] [ matter.js / Behavior ]: Invoke a7593064a30d433a9930e4f7836e56b5.aggregator.cover_ratgdo_door.windowCovering.upOrOpen online#45f4f5a@95216b57 (no payload)
[ 2024-11-15T21:03:32.287Z ] [ ERROR ] [ matter.js / Runtime ]: { code: "home_assistant_error", message: "Entity cover.ratgdo_door does not support this service." }
[ 2024-11-15T21:03:32.288Z ] [ INFO ] [ matter.js / Runtime ]: Shutting down
[ 2024-11-15T21:03:32.288Z ] [ INFO ] [ matter.js / Node ]: a7593064a30d433a9930e4f7836e56b5 going offline
[ 2024-11-15T21:03:32.298Z ] [ INFO ] [ matter.js / UdpMulticastServer ]: lo: send ENETUNREACH ff02::fb:5353
[ 2024-11-15T21:03:32.406Z ] [ INFO ] [ matter.js / SecureSession ]: End CASE session secure/51346
[ 2024-11-15T21:03:32.408Z ] [ INFO ] [ matter.js / SecureSession ]: End CASE session secure/51347
[ 2024-11-15T21:03:32.408Z ] [ INFO ] [ matter.js / Node ]: a7593064a30d433a9930e4f7836e56b5 is offline
[ 2024-11-15T21:03:32.476Z ] [ INFO ] [ matter.js / ServerNodeStore ]: Closed a7593064a30d433a9930e4f7836e56b5 storage at /config/data/a7593064a30d433a9930e4f7836e56b5

Interesting. Somehow we are calling an action in home assistant which is not allowed for this cover. Did it work before?

Can you set the log level to debug and then try again? It will then log the exact action it is trying to call.

I saw some issue with covers. Mostly some were reversed. Was showing they were open while closed, and up/down command was inverted.
Funny thing, I have 4 x covers which are the same brand devices , 2 of them were ok but 2 others were working inverted on GH.

On HA side they were having the same data, this looked a bit non sense.

I'll track this down and get some debug data.

Updated to the alpha. 32 and my smart blinds reversed direction in Google home. Before they worked normally but now the open and close direction and state is the opposite in Google home

 Open is closed and closed is open. Also 26% open in home assistant is now 74% open in Google home.

So first things first:
- Matter specifies 0% as "open" and 100% as "closed".
- Home Assistant specifies 100% as "open" and 0% as "closed".

So I needed to reverse covers in general. To indicate that it's reversed, i used the `configStatus.liftMovementReversed` flag (this is what has changed) - maybe it was wrong doing both.

I'll remove that property to test it.

Not sure it will be sufficient, as not all my covers here looks inverted. Some are reporting open when opened, I have one coming from HomeKit and this one is always inverted.

I've tryed to set configStatus.liftMovementReversed to false, and then the working ones actions are working in reverse ( Opening close, and closing open.. But state looks eratic. Sometime it says it's open when close, and sometime it reports the correct state. I'm trying to find a logic behind that.

Does your cover support positions, or does it only support open and close?
After calling the `set_cover_position` it shows an error, that this service call is not supported.

Can you try calling that service manually from the home assistant dev tools?
- Service: `cover.set_cover_position`
- Target: `{"entity_id":"cover.ratgdo_door"}`
- Data: `{"position":100}'

Yeah, I get the same error in dev tools: `Failed to perform the action cover.set_cover_position. Entity cover.ratgdo_door does not support this service.`

This cover if for a garage door and it only supports open/close/stop.

Okay, can you post a screenshot of the attributes of this entity?
(HA -> Dev Tools -> State -> search for your entity)

Is there any indication where i can detect if it supports position awareness?

okay got it. actually i hoped that i dont need to parse `supported_features` since its deprecated for other domains. 😀

I have a cover with supported_feature 3. It only has up/down and state open/close, and probably stop.
Actually matter bridge only expose up down button but no state.

I've added support for "not position aware".

Also i reverted one change, which COULD be related to the missing percentage in GH. Just let me know.

still the same here, all covers have only up down buttons and no feedback/state.
Will try to catch some data tomorrow.

Just on thing I can give for now, Garage door now crash the bridge at startup:

Behaviors have errors
 at file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/endpoint/properties/Behaviors.js:128:21
 at all (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/general/dist/esm/util/Construction.js:375:17)
 at file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/general/dist/esm/util/Construction.js:365:11
 Cause #0: Error initializing 435459ea97854796829ca31284021754.aggregator.cover_porte_garage.windowCovering
 at crash (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/internal/BehaviorBacking.js:48:13)
 Caused by: Validating 435459ea97854796829ca31284021754.aggregator.cover_porte_garage.windowCovering.state: Conformance "LF & PA_LF": Matter does not allow you to set this attribute (128)
 at disallowValue (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/validation/conformance-compiler.js:305:13)
 at file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/validation/conformance.js:13:15
 at file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/managed/values/StructManager.js:135:13
 at Object.change (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/managed/Datasource.js:172:7)
 at WindowCovering$State.set [as currentPositionLiftPercent100ths] (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/managed/values/StructManager.js:105:32)
 at Function.assign ( )
 at applyPatchState (file:///usr/local/lib/node_modules/home-assistant-matter-hub/dist/backend/cli.js:888:14)
 at WindowCoveringServer.update (file:///usr/local/lib/node_modules/home-assistant-matter-hub/dist/backend/cli.js:1618:5)
 at WindowCoveringServer.initialize (file:///usr/local/lib/node_modules/home-assistant-matter-hub/dist/backend/cli.js:1609:10)

Also here are the data of one of my cover that only displays the up/down buttons and no state/position percent since alpha 33:

{
 "entityId": "cover.stores_buanderie",
 "endpointCode": "202",
 "endpointType": "WindowCovering",
 "state": {
 "identify": {
 "isIdentifying": false,
 "clusterRevision": 4,
 "identifyTime": 0,
 "identifyType": 0,
 "featureMap": {

 },
 "attributeList": [0, 1, 65533, 65532, 65531, 65529, 65528],
 "eventList": [],
 "acceptedCommandList": [0],
 "generatedCommandList": []
 },
 "bridgedDeviceBasicInformation": {
 "clusterRevision": 3,
 "vendorName": "t0bst4r",
 "vendorId": 65521,
 "productName": "MatterHub",
 "nodeLabel": "Stores Buanderie",
 "hardwareVersion": 2024,
 "softwareVersion": 2024,
 "productLabel": "Home Assistant Matter Hub",
 "reachable": true,
 "featureMap": {

 },
 "attributeList": [1, 2, 3, 5, 7, 9, 14, 17, 65533, 65532, 65531, 65529, 65528],
 "eventList": [],
 "acceptedCommandList": [],
 "generatedCommandList": []
 },
 "windowCovering": {
 "supportsCalibration": false,
 "supportsMaintenanceMode": true,
 "clusterRevision": 5,
 "featureMap": {
 "lift": true,
 "tilt": false,
 "positionAwareLift": true,
 "absolutePosition": true,
 "positionAwareTilt": false
 },
 "type": 0,
 "currentPositionLift": 10000,
 "configStatus": {
 "operational": true,
 "onlineReserved": false,
 "liftMovementReversed": true,
 "liftPositionAware": true,
 "tiltPositionAware": false,
 "liftEncoderControlled": false,
 "tiltEncoderControlled": false
 },
 "currentPositionLiftPercentage": 100,
 "operationalStatus": {
 "global": 0,
 "lift": 0
 },
 "targetPositionLiftPercent100ths": 10000,
 "endProductType": 0,
 "currentPositionLiftPercent100ths": 10000,
 "installedOpenLimitLift": 0,
 "installedClosedLimitLift": 10000,
 "mode": {
 "motorDirectionReversed": false,
 "calibrationMode": false,
 "maintenanceMode": false,
 "ledFeedback": false
 },
 "attributeList": [0, 7, 10, 13, 23, 65533, 65532, 65531, 65529, 65528, 16, 17, 11, 14],
 "eventList": [],
 "acceptedCommandList": [0, 1, 2, 5, 4],
 "generatedCommandList": []
 },
 "descriptor": {
 "clusterRevision": 2,
 "featureMap": {
 "tagList": false
 },
 "deviceTypeList": [
 {
 "deviceType": 514,
 "revision": 3
 },
 {
 "deviceType": 19,
 "revision": 2
 }
 ],
 "serverList": [3, 57, 258, 29],
 "clientList": [],
 "partsList": [],
 "attributeList": [0, 1, 2, 3, 65533, 65532, 65531, 65529, 65528],
 "eventList": [],
 "acceptedCommandList": [],
 "generatedCommandList": []
 }
 }
 },

image

The crash during startup should be fixed.

The attributes don't look wrong tbh. I'll validate them tomorrow.

I've made some test with previous version.

With alpha-32 I still have the cover position + closed/opened state on GH.
image

Starting with alpha-33, only up/down button withtout state/position feedback.
image

The only differences I see from the dev tools log is "targetPositionLiftPercent100ths": 5000 with latest alpha, and "targetPositionLiftPercent100ths": 100, with alpha-32 working one

Hm. i was suspecting the `targetPositionLiftPercent100ths` to cause it, but that's why i reverted my change in `alpha.34`:

 URL

Here is the diff between `alpha.32` and `alpha.36`:
 URL

In the end, i am always setting it if your cover is position aware.

`targetPositionLiftPercent100ths` is not in percent. It’s `percent * 100`.
So 100 is 1% and 5000 is 50%.

I see. It shouldn't be at 50% as it's open, and 32 reports 1% at the same time.

@t0bst4r , do you prefer I create a separated issue for this ?

no let's just do it here. 👍
I'm currently looking into it again.

I just see no difference at all. With Alexa I get the level control, too.

Can you please try pairing a whole new bridge?
Maybe there is some kind of caching in place.

Damn it. Do you still have your test-setup running? I just don't understand, that it's working for me with Alexa.
Can you _again_ share the json from dev tools from both versions, 32 and current - for the SAME cover and with no changes to the cover in between of course 😁

I am not sure which attribute to use here.
To be honest: to "know" if its open or closed is already position aware, isn't it?

---

i just checked the matter specification and found that it is not recommended to use the "AbsolutePosition" feature. So I'll remove that, but keep the "PositionAwareLift" as it is for now.

So something strange. I've just opened GH app, and see my covers have now the correct slider with position.

Seems my GH speaker has updated to preview fw 444798.

However, if I move the cover position from HA, it doesn't update the state on GH side .

I'm on the Matter specs now, I'm also surprised there's no dedicated cluster for open/close state.
I think then it has to be simulated for devices with no position feedback by jumping CurrentPositionLiftPercentage to 100% when HA cover state is "closed" or 0% when "open".

Not totally related, but I also saw this endpoint for moving state:

- 5.3.5.3. OperationalStatusBitmap Type
This endpoint display opening/closing/not moving state

I see a problem on current implementation as this value comes from another ha entity.
Cover devices have cover entity , + can have additional sensors entities:
- moving state : STOP, UP, DOWN
- open/close binary sensor ( ie garage doors have this separated , I had to create a cover template to add this sensor as the cover state value )

Dunno on an entity based bridge how can it be implemented.
Device based bridge is probably needed for this ( this is how it's implemented on zigbee2mqtt matter bridge )

One more thing I'd like to test:
at the moment, position aware covers get the following features: "Lift", "PositionAwareLift" and "AbsolutePosition".
As per matter specification "Absolute Position" should not be used anymore:

for new implementations.

So I'll remove it, so maybe thiings get better with that.

I'm not sure how to check that. If I move a cover from HA, then it doesn't update on GH. Seems like GH is keeping its own states for whatever reason.
 Commands are only inverted when states are not in synch, like closed in HA and Open in GH.

This could be related to Absolute Positioning so let's try without.

I have not much time this week end but I'll try to gather some data about what's happening.

I have already released it to `alpha.38`, so give it a try.

---

Anyway i am now even more confused regarding inversion:

Alexa: open = 0% and close = 100%

Alexa shows as a title for the percentage: `Öffnungsgrad` (translates to `Degree of openness`)
As of my understanding `degree of openness` of `0%` would mean closed, but it's not 😀

So when Asking it to "close", it sets the position to 100% - as specified.
But from a natural language perspective it is counter-intuitive. 😀

Just tested, you won't like it ^^

- Now all position aware covers have only 2 buttons, but with state:
image
That's the UI the garage door should have then, but it still have the 2 buttons without state:
image
- State follows on HA when cover is triggered from GH But on the other way, when triggered from HA, states follows when achieving close or open, thereafter it switch back to the other state ( i.e. Cover is open, I close it from HA, I see cover state as closed when closed, then a sec after, it switch back to open state.
- after upgrading to 38, all devices were recognised as new devices, I had to remap them to each room. Btw, not really important in alpha stage. Got this on log at startup for each device:
` [ 2024-11-23T13:32:20.373Z ] [ WARN ] [ matter.js / EndpointStoreService ]: Stored number 42 is already allocated to another endpoint, ignoring
`

Just adding my 2 cents here. I have ratgdo's on 2 garage door openers that are old so they are setup in dry contact configuration/firmware. These are MQTT only devices in this configuration so no esphome. These 2 devices show up in HA as covers and I can control them just fine within HA. I added them to matterhub to expose them to alexa and they always just say device unresponsive. Feature set shows 11 in dev tools. Running alpha 45

i've added the absolute position feature again, since this seemed to remove the percentage in google home.
also i have added the position aware feature for non-position aware covers and (hopefully correctly) faked the open and close state.

Can please someone test with alpha.48 ?

In Alpha 49 My devices show available now. In alexa app I have only a slider and if I slide it all the way to 0 or 100% then I get an action on my door. 100% = closed 0% = open

Yes position aware are back. And garage door is ok now with state feedback 👍

For covers which don't support position, i implemented the handler to consider every `percentage > 0` as "close command" and `percentage == 0` as "open command".

So can we finally close this issue?

Here everything looks ok for what I could test so probably yes.


Question: Brisanje nepremičnine?

Hvala za opombe, `requests` smo odstranili url-je smo pa naredili tako kot smo se menili na vajah.
Imamo še eno vprašanje glede `binder`-ja, ali moramo spremeniti oz. dodati še kaj za delovanje le-tega
(poleg povezave z _javnost_ na bazo).

Brisanje nepremičnine
Potrebovale bi pomoč pri brisanju nepremičnine. Kljub temu, da smo uredile, da ko izbrišemo nepremičnino, da se izbriše tudi komitent, nam še vedno javlja napako, da izbris ni mogoč, ker se v komitentu sklicujemo na nepremičnino, ki bi jo rade izbrisale.
Že v naprej hvala za pomoč!

### 1. Brisanje nepremičnine
Težava je, da želite iz tabele `komitent` izbrisati vrstice, kjer se kupuje nepremičnina, ki jo želite izbrisati. Trenutno brišete iz tabele komitent vrstice, ki imajo v `id_komitent` vrednost `id`, namesto v `kupuje_nepremicnino`. To lahko rešite tako (namesto vaših vrstic 505-515):

python
cur.execute("DELETE FROM hisa WHERE id_hisa =%s" % (id))
cur.execute("DELETE FROM stanovanje WHERE id_stanovanje=%s" % (id))
cur.execute("DELETE FROM komitent WHERE kupuje_nepremicnino=%s" % (id))
cur.execute("DELETE FROM nepremicnina WHERE id =%s" % (id))
conn.commit()

### 2. Težava z vpisovanjem emša

Poleg tega sem opazil pri vas težavo: če med registracijo vpišem svoj emšo, mi vrne napako

python
psycopg2.errors.NumericValueOutOfRange: value "1812999500000" is out of range for type integer
LINE 3: VALUES ('1812999500000', 'Maj', 'Gaberšček',...

To se zgodi, ker imate stolpec `id` v tabeli `oseba` tipa `SERIAL`, ki omogoča samo števila do $2^{31} - 1$. Svetujem vam, da stolpcu spremenite tip na `BIGINT`, ki omogoča precej večja števila (do $2^{63} - 1$). To lahko storite z ukazi:

sql
ALTER TABLE oseba ALTER COLUMN id TYPE BIGINT;
ALTER TABLE agent ALTER COLUMN id_agent TYPE BIGINT;
ALTER TABLE komitent ALTER COLUMN id_komitent TYPE BIGINT;

Seveda pazite še na to, da ne odpirate možnosti napadov SQL injection - tako kot drugod podajte `id` v seznamu kot drugi argument metode `execute` (tj., ga ne vstavljate v niz s `%` ali na kak drug način), npr.

python
cur.execute("DELETE FROM hisa WHERE id_hisa = %s", [id])

Kar se tiče EMŠOv, kot je opozoril @majbc1999, bi predlagal, da jih imate kar v poljih tipa `TEXT`. Morda bo celo bolje, da pustite `id` v tabeli `oseba` tipa `SERIAL` (in tako ostanejo nespremenjene reference na ta stolpec), sam EMŠO pa imate v svojem stolpcu (z omejitvijama `NOT NULL UNIQUE`, da se vrednosti ne bodo ponavljale), ID-je pa pustite, da se vam sami generirajo.

Še to: vidim, da na več mestih uporabljate funkcijo `url`, ki pa ji podaste kar pot (tj., začne se z `/`). Prvi argument funkcije `url` naj bo kar ime ustrezne funkcije - tako se bodo zgradile ustrezne poti tudi, ko boste aplikacijo poganjale na Binderju. Seveda na isti način gradite poti tudi v predlogah. Za več podrobnosti si poglejte MatejRojec/Gamma#1.

Hvala za pomoč, smo popravile tako izbris nepremičnine, kot tudi url povezave.

Grajenje URL-jev
Svetujem, da za grajenje URL-jev (v predlogah in pri preusmeritvah) uporabite funkcijo `url`. Pri lokalnem poganjanju sicer ne bo nobene razlike, bodo pa tako povezave delovale pri poganjanju na Binderju. Za začetek bo tako treba namesto iz `bottle` uvažati iz `bottleext`:

python
from bottleext import *

Funkciji `url` podaste ime funkcije, ki prikaže želeno stran (kot niz), nato pa po potrebi še ostale poimenovane parametre. Tako namesto
 URL
naredite

python
 redirect(url('uporabnik_get', id_uporabnika=id_uporabnika))

Podobno naredite tudi pri vseh povezavah v predlogah (tj., atributi `href`, `action`, `src`), npr.

html

Mimogrede, da bo aplikacija tekla na Binderju, bo potrebno v `binder/start` popraviti ime glavnega programa:

bash
export BOTTLE_RUNTIME=gama.py

Opažam še, da v glavnem programu uvažate knjižnico `requests`, ki je pa nikjer ne uporabite, tako da svetujem, da njen uvoz odstranite. Če pa jo boste vendarle potrebovali (oziroma katerokoli knjižnico, ki ni privzeto nameščena s Pythonom), pa jo dodajte še v `binder/requirements.txt` (obstoječi vrstici seveda pustita), da se bo ustrezno pripravilo okolje za poganjanje. Ko boste želeli, lahko potem v `README.md` dodaste še povezavo za poganjanje v Binderju:

markdown
bottle.py


Question: Change Some expression that not contribute with inclusive language or antiracist language?

I don't think Mailcow is the right place for political discussions like this. While the intent may be laudable, it comes at a price in terms of clarity, brevity and unambiguity.

For example, replacing "whitelist" with "allow list" is ambiguous and unclear (you don't need to be on that list to be allowed to send mail) and "spam filter bypass list" is lengthy and not completely clear either.

There do not appear to be alternative terms in widespread use (Exchange has "safe senders", Gmail doesn't even have that feature), and as a small mail server platform, we are not in the position to define new terms. We need to make it as easy as possible for people migrating from other platforms. Once Exchange, Yahoo, Gmail, etc. converge on a new name, we will happily adopt it.

Change Some expression that not contribute with inclusive language or antiracist language
### Summary

Hi community!

In the view Spam Filter when you are editing a domain.

change words
White List for Enabled
Black List for Disabled

In Spanish
Lista Blanca: Habilitada
Lista Negra: Deshabilitada

Captura de pantalla de 2022-03-25 20-23-59

Captura de pantalla de 2022-03-25 20-22-02

### Motivation

contribute to a non-racist language

### Additional context

_No response_

I fear Mailcow maintainers aren't really sensitive to this, but maybe if you prepare a pull request with the newly translated strings it has better chances?

Dupe of URL

Also Enabled and Disabled (which btw is also a 'racist' word against disabled people) doesn't fit at all

rename "whitelist/blacklist" in spam settings to "allowlist/blocklist"
Use of the words "whitelist" to denote "good" and "blacklist" to denote bad has negative connotations, and does not describe very well what the actual action is.

please can you replace them with "Allow list" to signify email addresses that will always be allowed, and "block list" or "deny list" for email addresses that will always be blocked or denied.

This will improve usability.

I don't know. In mailing whitelist and blacklist are established terms.

No, it won't.

Postmasters already know what a blacklist and a whitelist are. Do not invent new terms.

Racism was once widely established as well. I'm very sure that we all can agree that 'but it is established' shouldn't be used as an argument to avoid any improvements.

If those Postmasters won't be able to adapt to 2 (I repeat: **two**!) 'new' words they will probably have a bad time.

Just a few examples why postmasters (or any other person in IT) will probably encounter replacements anyway:

* have a look on this document the IETF recently published, which argues

* or see what scientists think about it
* or what Microsoft thinks about it and what they changed in the Chromium engine (you know, one of the popular browser engines)
* what the Ruby on Rails members think about it (also this tweet)
* or the folks at the graphite project
* the HTML standard specification on whatwg
* Rack attack
* Roslyn
* or the folks at GitLab

So my impression is, that if a company like Microsofts doesn't believe that those terms have to be established and manages to remove it for a code base like Chromium, it is _probably_ possible for others as well.