Order of input messed up when auto typing

Which operating system does the issue occur on?
linux
If on linux, are you using X11 or Wayland?
X11
When auto typing with xdotools default delay (14ms) ordering of key strokes is not preserved most of the time and with even lower delays key presses are sometimes even dropped.
Depending on the alacritty version a delay around 30ms seems to be safe.
The glutin 0.18 PR improves the situation but does not fix it.
I tried this with several other terminals (xterm, termite, kitty) they all receive the simulated key presses without problems even when disabling the delay entirely.

@Arvedui that sounds bad. Would you mind trying to reproduce this with the winit window example?
Alternatively, can you provide detailed instructions to reproduce?

Steps to reproduce:

sleep 1; xdotool type --delay 12  "abcdefghijklmnopqrstuvwxyz" (sleep is only there to give one enough time to switch the window)
switch immediately to an alacritty window.
characters should appear in a messed up order. If not decrease delay and try again.

I could not reproduce this with the winit window example based on the terminal output.
I also ran alacritty with --print-events, the messed up order is clearly visible in the output as you can see.
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 30, state: Pressed, virtual_keycode: Some(A), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 30, state: Released, virtual_keycode: Some(A), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 48, state: Pressed, virtual_keycode: Some(B), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 48, state: Released, virtual_keycode: Some(B), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 46, state: Pressed, virtual_keycode: Some(C), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 46, state: Released, virtual_keycode: Some(C), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 32, state: Pressed, virtual_keycode: Some(D), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 32, state: Released, virtual_keycode: Some(D), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 18, state: Pressed, virtual_keycode: Some(E), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 18, state: Released, virtual_keycode: Some(E), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 33, state: Released, virtual_keycode: Some(F), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 33, state: Pressed, virtual_keycode: Some(F), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 34, state: Pressed, virtual_keycode: Some(G), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 34, state: Released, virtual_keycode: Some(G), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 38, state: Pressed, virtual_keycode: Some(L), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 16, state: Released, virtual_keycode: Some(Q), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 16, state: Pressed, virtual_keycode: Some(Q), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 25, state: Released, virtual_keycode: Some(P), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 25, state: Pressed, virtual_keycode: Some(P), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 24, state: Released, virtual_keycode: Some(O), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 24, state: Pressed, virtual_keycode: Some(O), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 49, state: Released, virtual_keycode: Some(N), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 49, state: Pressed, virtual_keycode: Some(N), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 50, state: Released, virtual_keycode: Some(M), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 50, state: Pressed, virtual_keycode: Some(M), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 38, state: Released, virtual_keycode: Some(L), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 35, state: Pressed, virtual_keycode: Some(H), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 35, state: Released, virtual_keycode: Some(H), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 23, state: Pressed, virtual_keycode: Some(I), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 23, state: Released, virtual_keycode: Some(I), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 36, state: Pressed, virtual_keycode: Some(J), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 36, state: Released, virtual_keycode: Some(J), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 37, state: Pressed, virtual_keycode: Some(K), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 37, state: Released, virtual_keycode: Some(K), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 19, state: Pressed, virtual_keycode: Some(R), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 19, state: Released, virtual_keycode: Some(R), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 31, state: Pressed, virtual_keycode: Some(S), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 31, state: Released, virtual_keycode: Some(S), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 20, state: Pressed, virtual_keycode: Some(T), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 20, state: Released, virtual_keycode: Some(T), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 22, state: Pressed, virtual_keycode: Some(U), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 17, state: Pressed, virtual_keycode: Some(W), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 17, state: Released, virtual_keycode: Some(W), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 45, state: Pressed, virtual_keycode: Some(X), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 45, state: Released, virtual_keycode: Some(X), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 44, state: Pressed, virtual_keycode: Some(Y), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 21, state: Released, virtual_keycode: Some(Z), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 21, state: Pressed, virtual_keycode: Some(Z), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(X(WindowId(62914565))), event: KeyboardInput { device_id: DeviceId(X(DeviceId(3))), input: KeyboardInput { scancode: 44, state: Released, virtual_keycode: Some(Y), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }

This means it is a problem in glutin, right?

I played around with the winit example a little and tried to mimic alacrittys event loop.
It looks like this now:
extern crate winit;

use std::{thread, time};

fn main() {
    let mut events_loop = winit::EventsLoop::new();
    let window = winit::Window::new(&events_loop).unwrap();

    loop {
        events_loop.run_forever(|event| {
            println!("forever: {:?}", event);

            winit::ControlFlow::Break
        });

        let sleep_time = time::Duration::from_millis(50);
        thread::sleep(sleep_time);

        events_loop.poll_events(|event| {
            println!("poll: {:?}", event);
            thread::sleep(time::Duration::from_millis(5));
        });
    }
}

With this and a xdotool type delay of 30 milliseconds I get … interesting results.
The event order is somewhat reliably completely flipped!
I than looked closer at the messed up character sequences I get in alacritty and it seems that most if not all can be put in their original order just by flipping consecutive characters.

Therefore I'd say this is a race condition somewhere in winit or below.

cc @francesca64

I believe I found the origin of this bug.
I stumbled upon this bug report for libx11, which winit uses for communication with x11.
It only occurs when using a xim, which I do.
I can reproduce this bug in other applications as well and it completely vanishes in all of them (including alacritty) when disabling the xim.
I only noticed this in alacritty because most applications I use use either gtk or qt. Both have their own input module apis that are preferred over xim and are obviously not affected, however when forcing them to use xim they are affected as well.
Sorry for the noise. :)

Thanks for keeping us updated.


FIX width of transform component content

I took a look at how unity does it (https://github.com/MattRix/UnityDecompiled/blob/master/UnityEditor/UnityEditor/TransformInspector.cs) and changed the inspector so it works the same way. Here is the difference:

Btw. I love the buttons on the right, really good addition to the inspector!

nice


Add 1.18.2 version tag to modrinth download

Hello,
First of all I would like to thank you for this amazing mod. It helps me a lot checking my servers performance and is simply the best way to integrate the servers TPS into a client.
I've tried switching to a CLI Mod Manager (Ferium) today and found it impossible to add Servertick to a Minecraft 1.18.2 profile because the Modrinth version is only tagged as compatible with 1.18. Because it doesn't seem like Ferium will add the ability to pick a specific mod version very soon, I would like to ask you if you could quickly tag the Modrinth version as 1.18.2 compatible. I've already used it extensively on my 1.18.2 Server and had no problems at all.
Thank you very much!

Thanks for the heads-up, I've added the missing tags. Glad you like the mod!


Move cohort re-labelling logic to Cohort.ts

Description
It looks like the functions getBasicFilterString and getCompositeFilterString operated on Cohort filters. So moving these functions into Cohort.ts as for explanations we use Cohort (not ErrorCohort) and the cohort labelling logic come handy if these functions are defined in Cohort.ts.
Checklist

[ ] I have added screenshots above for all UI changes.
[ ] I have added e2e tests for all UI changes.
[ ] Documentation was updated if it was needed.

Codecov Report

Merging #1773 (f196c78) into postga (d0d338e) will decrease coverage by 8.78%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           postga    #1773      +/-   ##
==========================================
- Coverage   84.07%   75.29%   -8.79%
==========================================
  Files          48        9      -39
  Lines        2776      255    -2521
==========================================
- Hits         2334      192    -2142
+ Misses        442       63     -379

Flag
Coverage Δ

unittests
75.29% <ø> (-8.79%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...ranalysis/erroranalysis/_internal/matrix_filter.py

...is/erroranalysis/_internal/surrogate_error_tree.py

...s/erroranalysis/_internal/error_report/__init__.py

erroranalysis/erroranalysis/report/error_report.py

raiwidgets/raiwidgets/error_handling.py

raiwidgets/raiwidgets/error_analysis_dashboard.py

raiwidgets/raiwidgets/model_analysis_dashboard.py

...idgets/raiwidgets/responsibleai_dashboard_input.py

raiwidgets/raiwidgets/error_analysis_constants.py

raiutils/raiutils/data_processing/__init__.py

... and 29 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


remote_write: send on closed channel

Bug Report
Running Prometheus 2.3.0 with graphite-remote-adapter and stopping it:
level=info ts=2018-06-13T06:49:24.26401728Z caller=queue_manager.go:258 component=remote queue="0:http://prometheus-meta-graphite-remote-adapter/write?graphite.default-prefix=sre.network.services.prometheus." msg="Stopping remote storage..."
level=info ts=2018-06-13T06:49:25.680587091Z caller=queue_manager.go:266 component=remote queue="0:http://prometheus-meta-graphite-remote-adapter/write?graphite.default-prefix=sre.network.services.prometheus." msg="Remote storage stopped."
level=info ts=2018-06-13T06:49:25.680647131Z caller=manager.go:464 component="rule manager" msg="Stopping rule manager..."
panic: send on closed channel

goroutine 932 [running]:
github.com/prometheus/prometheus/storage/remote.(*shards).enqueue(0xc42017b0e0, 0xc42e688c00, 0x5)
        /go/src/github.com/prometheus/prometheus/storage/remote/queue_manager.go:438 +0x8b
github.com/prometheus/prometheus/storage/remote.(*QueueManager).Append(0xc4202e41e0, 0xc439343918, 0x8, 0xc437844090)
        /go/src/github.com/prometheus/prometheus/storage/remote/queue_manager.go:222 +0x26e
github.com/prometheus/prometheus/storage/remote.(*Storage).Add(0xc420193420, 0xc429089100, 0x5, 0x8, 0x163f7e7f3cc, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/prometheus/prometheus/storage/remote/write.go:32 +0x11a
github.com/prometheus/prometheus/storage.(*fanoutAppender).Add(0xc426cafa40, 0xc429089100, 0x5, 0x8, 0x163f7e7f3cc, 0x0, 0x1c85b, 0x0, 0x0)
        /go/src/github.com/prometheus/prometheus/storage/fanout.go:140 +0x131
github.com/prometheus/prometheus/rules.(*Group).Eval.func1(0x1decdc0, 0xc420042118, 0x275dbd39, 0xed2b2b573, 0x2afd680, 0xc4208fa870, 0x10, 0x1df69e0, 0xc42109fcc0)
        /go/src/github.com/prometheus/prometheus/rules/manager.go:365 +0x6f8
github.com/prometheus/prometheus/rules.(*Group).Eval(0xc4208fa870, 0x1decdc0, 0xc420042118, 0x275dbd39, 0xed2b2b573, 0x2afd680)
        /go/src/github.com/prometheus/prometheus/rules/manager.go:406 +0xad
github.com/prometheus/prometheus/rules.(*Group).run.func1()
        /go/src/github.com/prometheus/prometheus/rules/manager.go:206 +0xc0
github.com/prometheus/prometheus/rules.(*Group).run(0xc4208fa870, 0x1decdc0, 0xc420042118)
        /go/src/github.com/prometheus/prometheus/rules/manager.go:235 +0x2e6
github.com/prometheus/prometheus/rules.(*Manager).Update.func1.1(0xc420179340, 0xc4208fa870)
        /go/src/github.com/prometheus/prometheus/rules/manager.go:509 +0x60
created by github.com/prometheus/prometheus/rules.(*Manager).Update.func1
        /go/src/github.com/prometheus/prometheus/rules/manager.go:504 +0x56

Environment
Linux 4.13.0-45-generic x86_64
prometheus, version 2.3.0 (branch: HEAD, revision: 290d71791a507a5057b9a099c9d48703d86dc941)
  build user:       root@d539e167976a
  build date:       20180607-08:46:54
  go version:       go1.10.2

I predict that the Remote storage is stopped before scrapeManager. It is only closed the queue in the QueueManager, but it does not prevent new sample appended into QueueManager.
So should Prometheus make sure that scrapeManager must be stopped before all components?

Yes, scrapes and rules should be shutdown before storage.

@jojohappy  As the log shows, this issue is caused by ruleManager. It did not stop rule evaluation after remote storage is stopped.

@codwu Yes, It is. As @brian-brazil said, both scrapeManager and ruleManager should be stopped before storage. I will try to fix this bug.

This sounds like it might be the same cause as #4133

https://github.com/prometheus/prometheus/blob/2bd510a63e48ac6bf4971d62199bdb1045c93f1a/vendor/github.com/oklog/oklog/pkg/group/group.go#L46-L48
The managers stop in sequence, so the ruleManager receives the stopping signal after storage. I think we can fix this by adding ruleManager into groups before storage


Make peer.sh more robust

PR #108 introduces a chaincode name prefix for private chaincodes. As this is a technical limitation and may disappear in the future we decided to hide this prefix from the end user.
PR #108 comes only with limited support for this name prefix and there is a lot room to improve this peer.sh and make it more robust against misuse and several situations. See the PR discussion for more details.

Here a summary of suggestions:

The "DOCKER_IMAGE_NAME can only be used within instantiate" is not really true, what is true is "version is only provided by instantiate" as invoke and query use the version from latest instanstiated/upgraded. So wouldn't the really robust way be to do in invoke/query a ../../fabric/bin/peer.sh chaincode list -C ${CHAN_ID} --instantiated | | awk "/Name: ${FPC_NAME}/ "'{ print $4 }' to get the version? (In fact, this could be right away the test, although doing a cross-check with DOCKER_IMAGE_NAME would make it even more robust) ...

Regarding upgrade changing FPC to non FPC-lang (or vice versa). I think this is simply something we cannot realistically support. Also not sure where it ever makes sense. I guess what could work eventually is upgrade from one FPC language to another one (e.g., if ever we would add go or wasm or alike ...)

Regarding chaincode list, override of course would solve it. I agree that we should be careful not to go overboard with peer.sh, though overriding chaincode list might just be a simple sed s/fpc_// ? (this of course assumes no other code ever uses fpc_ as prefix but i guess that's a reasonably safe assumption we can do for now?)

What about about double prefix situations?

addressed in PR #113


route_handler sometimes refuses to set goal on parking

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I'm convinced that this is not my fault but a bug.

Description
Example here on the sample map extended parking (lanelet2_map.txt)
The ego vehicle is somewhere on the parking and I try to set the goal somewhere else on the parking:
Screencast from 12-26-2023 03_16_00 PM.webm
All the goals should be reachable and accepted but many are refused by the route_handler node. It looks like this mostly depend on the ego pose.
Expected behavior
All goal set in the video above should be accepted
Actual behavior
sometimes refused
Steps to reproduce
planning simulator with a parking lot polygon (e.g. the one linked above.)
Versions
No response
Possible causes
No response
Additional context
No response

So the root cause is the way RouteHandler::planPathLaneletsBetweenCheckpoints is implemented or/and used in default_planner:
https://github.com/autowarefoundation/autoware.universe/blob/1d6e7e82ffc948fcf8c8f325947eec1785259088/planning/mission_planner/src/lanelet2_plugins/default_planner.cpp#L411-L415
The planPathLaneletsBetweenCheckpoints get the closest lanelets from start and goal poses and try to generate a path between the lanelets. If no path is found the goal is refused. The thing is that this does not makes sense at all if the vehicle is on a parking area, outside lanelets.
I think the default_planner should not use RouteHandler::planPathLaneletsBetweenCheckpoints if the start and goal poses happen to be on the same parking area. In the later case, the goal pose should be accepted for any initial/goal pose.

Quick and dirty fix by trying the planning up to 3 times:

from start to goal current lanelets (must be on lanelet)
from start to goal if on the same parking lot
from start to goal closest lanelets (legacy behavior)

This way lanelet based routing is prioritized if start/goal are both on lanelets and parking lots (like on the sample map), but "loose" routing (i.e. with the closest lanelet) is only tried if the parking "routing" is not possible.
Screencast from 12-26-2023 05_20_56 PM.webm
There is still an issue if the vehicle is on a lanelet but not oriented properly.
I don't know what would be the clean way to support this (have route_handler consider parking lots in the routing?)
diff --git a/planning/mission_planner/src/lanelet2_plugins/default_planner.cpp b/planning/mission_planner/src/lanelet2_plugins/default_planner.cpp
index d074e9cc83..fda14e2212 100644
--- a/planning/mission_planner/src/lanelet2_plugins/default_planner.cpp
+++ b/planning/mission_planner/src/lanelet2_plugins/default_planner.cpp
@@ -411,10 +411,29 @@ PlannerPlugin::LaneletRoute DefaultPlanner::plan(const RoutePoints & points)
     const auto start_check_point = points.at(i - 1);
     const auto goal_check_point = points.at(i);
     lanelet::ConstLanelets path_lanelets;
+    // first try to find "strict" path from start to goal, i.e. for which start and goal poses are expected to be on lanelets
     if (!route_handler_.planPathLaneletsBetweenCheckpoints(
-          start_check_point, goal_check_point, &path_lanelets, param_.consider_no_drivable_lanes)) {
-      RCLCPP_WARN(logger, "Failed to plan route.");
-      return route_msg;
+          start_check_point, goal_check_point, &path_lanelets, param_.consider_no_drivable_lanes, true)) {
+      // otherwise check if both points belong to the same parking area
+      lanelet::BasicPoint2d start_point{start_check_point.position.x, start_check_point.position.y};
+      lanelet::BasicPoint2d goal_point{goal_check_point.position.x, goal_check_point.position.y};
+      const auto all_parking_lots = lanelet::utils::query::getAllParkingLots(route_handler_.getLaneletMapPtr());
+      lanelet::ConstPolygon3d start_parking_lot;
+      lanelet::ConstPolygon3d goal_parking_lot;
+      bool start_on_parking = lanelet::utils::query::getLinkedParkingLot(start_point, all_parking_lots, &start_parking_lot);
+      bool goal_on_parking = lanelet::utils::query::getLinkedParkingLot(goal_point, all_parking_lots, &goal_parking_lot);
+      if (start_on_parking || goal_on_parking || start_parking_lot.id() == goal_parking_lot.id()) {
+        // stay within the parking area
+        path_lanelets.clear();
+      } else {
+        // otherwise try to find a "non-strict" path from start to goal, i.e. for which start and goal poses may be outside lanelets. In such case the closest lanelet is used.
+        if (!route_handler_.planPathLaneletsBetweenCheckpoints(
+          start_check_point, goal_check_point, &path_lanelets, param_.consider_no_drivable_lanes, false)) {
+          // tried our best :(
+          RCLCPP_WARN(logger, "Failed to plan route.");
+          return route_msg;
+        }
+      }
     }
     for (const auto & lane : path_lanelets) {
       all_route_lanelets.push_back(lane);
@@ -455,6 +474,7 @@ PlannerPlugin::LaneletRoute DefaultPlanner::plan(const RoutePoints & points)
 geometry_msgs::msg::Pose DefaultPlanner::refine_goal_height(
   const Pose & goal, const RouteSections & route_sections)
 {
+  if (route_sections.empty()) return goal; // free goal
   const auto goal_lane_id = route_sections.back().preferred_primitive.id;
   lanelet::Lanelet goal_lanelet = lanelet_map_ptr_->laneletLayer.get(goal_lane_id);
   const auto goal_lanelet_pt = lanelet::utils::conversion::toLaneletPoint(goal.position);
diff --git a/planning/mission_planner/src/mission_planner/mission_planner.cpp b/planning/mission_planner/src/mission_planner/mission_planner.cpp
index a1536a1beb..d2db266cba 100644
--- a/planning/mission_planner/src/mission_planner/mission_planner.cpp
+++ b/planning/mission_planner/src/mission_planner/mission_planner.cpp
@@ -389,8 +389,9 @@ void MissionPlanner::on_set_route_points(

   // Check planned routes
   if (route.segments.empty()) {
-    throw component_interface_utils::ServiceException(
-      ResponseCode::ERROR_PLANNER_FAILED, "The planned route is empty.");
+    // throw component_interface_utils::ServiceException(
+    //   ResponseCode::ERROR_PLANNER_FAILED, "The planned route is empty.");
+    RCLCPP_WARN(get_logger(), "The planned route is empty");
   }

   // Update route.
diff --git a/planning/route_handler/include/route_handler/route_handler.hpp b/planning/route_handler/include/route_handler/route_handler.hpp
index 7f7961f438..bece73534c 100644
--- a/planning/route_handler/include/route_handler/route_handler.hpp
+++ b/planning/route_handler/include/route_handler/route_handler.hpp
@@ -81,7 +81,7 @@ public:
   // for routing
   bool planPathLaneletsBetweenCheckpoints(
     const Pose & start_checkpoint, const Pose & goal_checkpoint,
-    lanelet::ConstLanelets * path_lanelets, const bool consider_no_drivable_lanes = false) const;
+    lanelet::ConstLanelets * path_lanelets, const bool consider_no_drivable_lanes = false, const bool strict = false) const;
   std::vector<LaneletSegment> createMapSegments(const lanelet::ConstLanelets & path_lanelets) const;
   static bool isRouteLooped(const RouteSections & route_sections);

diff --git a/planning/route_handler/src/route_handler.cpp b/planning/route_handler/src/route_handler.cpp
index 0e6464a81f..7015ee9099 100644
--- a/planning/route_handler/src/route_handler.cpp
+++ b/planning/route_handler/src/route_handler.cpp
@@ -2090,7 +2090,7 @@ lanelet::ConstLanelets RouteHandler::getNextLaneSequence(

 bool RouteHandler::planPathLaneletsBetweenCheckpoints(
   const Pose & start_checkpoint, const Pose & goal_checkpoint,
-  lanelet::ConstLanelets * path_lanelets, const bool consider_no_drivable_lanes) const
+  lanelet::ConstLanelets * path_lanelets, const bool consider_no_drivable_lanes, const bool strict) const
 {
   // Find lanelets for start point. First, find all lanelets containing the start point to calculate
   // all possible route later. It fails when the point is not located on any road_lanelet (e.g. the
@@ -2100,13 +2100,14 @@ bool RouteHandler::planPathLaneletsBetweenCheckpoints(
   lanelet::ConstLanelets start_lanelets;
   if (!lanelet::utils::query::getCurrentLanelets(
         road_lanelets_, start_checkpoint, &start_lanelets)) {
-    if (!lanelet::utils::query::getClosestLanelet(
+    if (strict || !lanelet::utils::query::getClosestLanelet(
           road_lanelets_, start_checkpoint, &start_lanelet)) {
       RCLCPP_WARN_STREAM(
         logger_, "Failed to find current lanelet."
                    << std::endl
                    << " - start checkpoint: " << toString(start_checkpoint) << std::endl
-                   << " - goal checkpoint: " << toString(goal_checkpoint) << std::endl);
+                   << " - goal checkpoint: " << toString(goal_checkpoint) << std::endl
+                   << " - strict: " << strict << std::endl);
       return false;
     }
     start_lanelets = {start_lanelet};
@@ -2114,14 +2115,20 @@ bool RouteHandler::planPathLaneletsBetweenCheckpoints(

   // Find lanelets for goal point.
   lanelet::ConstLanelet goal_lanelet;
-  if (!lanelet::utils::query::getClosestLanelet(road_lanelets_, goal_checkpoint, &goal_lanelet)) {
-    RCLCPP_WARN_STREAM(
-      logger_, "Failed to find closest lanelet."
-                 << std::endl
-                 << " - start checkpoint: " << toString(start_checkpoint) << std::endl
-                 << " - goal checkpoint: " << toString(goal_checkpoint) << std::endl);
-    return false;
+  lanelet::ConstLanelets goal_lanelets;
+  if (!lanelet::utils::query::getCurrentLanelets(road_lanelets_, goal_checkpoint, &goal_lanelets)) {
+    if (strict || !lanelet::utils::query::getClosestLanelet(road_lanelets_, goal_checkpoint, &goal_lanelet)) {
+      RCLCPP_WARN_STREAM(
+        logger_, "Failed to find closest lanelet."
+                  << std::endl
+                  << " - start checkpoint: " << toString(start_checkpoint) << std::endl
+                  << " - goal checkpoint: " << toString(goal_checkpoint) << std::endl
+                  << " - strict: " << strict << std::endl);
+      return false;
+    }
+    goal_lanelets = {goal_lanelet};
   }
+

   lanelet::Optional<lanelet::routing::Route> optional_route;
   std::vector<lanelet::ConstLanelets> candidate_paths;
@@ -2147,22 +2154,25 @@ bool RouteHandler::planPathLaneletsBetweenCheckpoints(
       }
     }

-    optional_route = routing_graph_ptr_->getRoute(st_llt, goal_lanelet, 0);
-    if (!optional_route || !is_proper_angle) {
-      RCLCPP_ERROR_STREAM(
-        logger_, "Failed to find a proper route!"
-                   << std::endl
-                   << " - start checkpoint: " << toString(start_checkpoint) << std::endl
-                   << " - goal checkpoint: " << toString(goal_checkpoint) << std::endl
-                   << " - start lane id: " << st_llt.id() << std::endl
-                   << " - goal lane id: " << goal_lanelet.id() << std::endl);
-    } else {
-      is_route_found = true;
+    for (const auto & gl_llt: goal_lanelets) {
+      optional_route = routing_graph_ptr_->getRoute(st_llt, gl_llt, 0);
+      if (!optional_route || !is_proper_angle) {
+        RCLCPP_ERROR_STREAM(
+          logger_, "Failed to find a proper route!"
+                    << std::endl
+                    << " - start checkpoint: " << toString(start_checkpoint) << std::endl
+                    << " - goal checkpoint: " << toString(goal_checkpoint) << std::endl
+                    << " - start lane id: " << st_llt.id() << std::endl
+                    << " - goal lane id: " << gl_llt.id() << std::endl);
+      } else {
+        is_route_found = true;

-      if (optional_route->length2d() < shortest_path_length2d) {
-        shortest_path_length2d = optional_route->length2d();
-        shortest_path = optional_route->shortestPath();
-        start_lanelet = st_llt;
+        if (optional_route->length2d() < shortest_path_length2d) {
+          shortest_path_length2d = optional_route->length2d();
+          shortest_path = optional_route->shortestPath();
+          start_lanelet = st_llt;
+          goal_lanelet = gl_llt;
+        }
       }
     }
   }
@@ -2225,6 +2235,7 @@ std::vector<LaneletSegment> RouteHandler::createMapSegments(
 lanelet::ConstLanelets RouteHandler::getMainLanelets(
   const lanelet::ConstLanelets & path_lanelets) const
 {
+  if (path_lanelets.empty()) return {}; // prevent crash on empty route
   auto lanelet_sequence = getLaneletSequence(path_lanelets.back());
   lanelet::ConstLanelets main_lanelets;
   while (!lanelet_sequence.empty()) {


fix: use same paths as vscode for settings

VSCode stores its settings in these places (with schema user-store):

This PR changes our settings to store them there as well, so custom file providers for user data store can put/retrieve settings from there. This should make it possible to persist settings between sessions, if users decide to replace the user-store schema with e.g. an IndexedDB filesystem.
It would've been even better if we would get the userRoamingDataHome variable directly from the EnvironmentService, but since that service is only initialized lazily this is the best next thing.
Code is inspired from here: https://github.com/microsoft/vscode/blob/8cb6def308c41b2b2fd09c14fbbc49d3ec3d5d01/src/vs/platform/userDataProfile/common/userDataProfile.ts#L286-L289

Thank you!
is the user filesystem provider still required then?

Good point, I've removed those filesystem providers and also updated the references in the demo to use the new location.

Why was the cache fs provider removed?


file_target does not contain Share folder

Describe the bug
As compared to oc10 backend, if system config share_folder is set, share create response data value file_target contains share_folder path before resource path, but ocis response only contains resource path
Steps to reproduce
Steps to reproduce the behavior:

create three users uu1, uu2, uu3
using user uu1 create a file with the filename testfile.txt
using user uu2 create a file with the filename testfile.txt
using user uu1 share file testfile.txt with user uu3

curl -k -u uu1:uu1 https://localhost:9200/ocs/v1.php/apps/files_sharing/api/v1/shares -d 'path=testfile.txt' -d 'shareWith=uu3' -d 'shareType=0' | xmllint --format -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1332  100  1289  100    43   6748    225 --:--:-- --:--:-- --:--:--  6937
<?xml version="1.0" encoding="UTF-8"?>
<ocs>
  <meta>
    <status>ok</status>
    <statuscode>100</statuscode>
    <message>OK</message>
  </meta>
  <data>
    <id>0cb58b99-bae9-4f10-9396-a3e95ec370f3</id>
    <share_type>0</share_type>
    <uid_owner>uu1</uid_owner>
    <displayname_owner>uu1</displayname_owner>
<EMAIL_ADDRESS>    <permissions>19</permissions>
    <stime>1623074243</stime>
    <parent/>
    <expiration/>
    <token/>
    <uid_file_owner>uu1</uid_file_owner>
    <displayname_file_owner>uu1</displayname_file_owner>
<EMAIL_ADDRESS>    <state>0</state>
    <path>/testfile.txt</path>
    <item_type>file</item_type>
    <mimetype>text/plain</mimetype>
    <storage_id>1284d238-aa92-42ce-bdc4-0b0000009157</storage_id>
    <storage>0</storage>
    <item_source>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OmI0YzgyYmFmLWQ4NGQtNGU3MS1iMzBiLWEwM2E1NzQ4YjAzMQ==</item_source>
    <file_source>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OmI0YzgyYmFmLWQ4NGQtNGU3MS1iMzBiLWEwM2E1NzQ4YjAzMQ==</file_source>
    <file_parent/>
    <file_target>/testfile.txt</file_target>
    <share_with>uu3</share_with>
    <share_with_displayname>uu3</share_with_displayname>
<EMAIL_ADDRESS>    <mail_send>0</mail_send>
    <name/>
  </data>
</ocs>

Expected behavior
create share response in oc10:
curl -k -u admin:admin http://localhost/core/ocs/v1.php/apps/files_sharing/api/v1/shares -d 'path=lorem.txt' -d 'shareWith=uu2' -d 'shareType=0' | xmllint --format -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1085  100  1045  100    40   2542     97 --:--:-- --:--:-- --:--:--  2633
<?xml version="1.0"?>
<ocs>
  <meta>
    <status>ok</status>
    <statuscode>100</statuscode>
    <message/>
    <totalitems/>
    <itemsperpage/>
  </meta>
  <data>
    <id>1790</id>
    <share_type>0</share_type>
    <uid_owner>admin</uid_owner>
    <displayname_owner>admin</displayname_owner>
    <permissions>19</permissions>
    <stime>1623075023</stime>
    <parent/>
    <expiration/>
    <token/>
    <uid_file_owner>admin</uid_file_owner>
    <displayname_file_owner>admin</displayname_file_owner>
    <additional_info_owner/>
    <additional_info_file_owner/>
    <path>/lorem.txt</path>
    <mimetype>text/plain</mimetype>
    <storage_id>home::admin</storage_id>
    <storage>1</storage>
    <item_type>file</item_type>
    <item_source>2147523314</item_source>
    <file_source>2147523314</file_source>
    <file_parent>3</file_parent>
    <file_target>/Shares/lorem.txt</file_target>
    <share_with>uu2</share_with>
    <share_with_displayname>uu2</share_with_displayname>
    <share_with_additional_info/>
    <mail_send>0</mail_send>
    <attributes/>
  </data>
</ocs>

Actual behavior

same file_target for both backends

if this is expected feature, please close the issue

Setup
Please describe how you started the server and provide a list of relevant environment variables.

OCIS_VERSION=latest
BRANCH=master
STORAGE_FRONTEND_UPLOAD_DISABLE_TUS=false

Additional context
related test is covered here

issued already at https://github.com/owncloud/ocis/issues/2112

@dpakach please get someone to check what tests we still have that fail because of this.
Then we can sort out what to do.

@phil-davis  Following tests are failing because of this issue

apiShareUpdateToShares/updateShare.feature:159
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:138
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:139
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:171
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:172
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:196
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:218
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:240
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:262
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:283
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:305
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:327
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:349
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:370
apiShareManagementBasicToShares/createShareToSharesFolder.feature:504
apiShareManagementBasicToShares/createShareToSharesFolder.feature:505
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:39
apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:40

@kulmann and whoever is interested.
See the diffs in https://github.com/owncloud/core/pull/39137 - we have adjusted the test scenarios so that they "accept" the different response in the file_target field in oCIS. That will help the scenarios get through more steps, and either fail for a "new/later" reason, or some might pass now.
A lot of responses in oCIS are "shorter" than in oC10. The value is missing the Shares or PARENT folder at the start of the path to the share.
I wonder if this difference will be difficult for current clients that are "in the wild"? And will clients need to code-around these differences?
I will leave this issue open for discussion - I don't feel comfortable just closing it.

ok I think I now found the right issue. I commentet in https://github.com/owncloud/core/pull/39241#issuecomment-930155337 but will reproduce here

IMNSHO the sharer should never see where a recipient mounted a share. It discloses the path parents that exists in the recipients trees to the sharer. AFAIK that information is neither used by the web ui nor the clients.

I would drop the file_path property when listing shares as the sharer. The path property is used everywhere and contains the owners path.
As a recipient the path is used as well, but this time as a mount point.

Assigned myself so that I see this and look into exactly what the current situation is.

Seems like oCIS now have Shares in file_target. see https://github.com/owncloud/ocis/issues/2540

Seems like oCIS now have Shares in file_target. see #2540
What to do with the changes made in PR owncloud/core#39137 ?
CC @individual-it @phil-davis @SwikritiT @kiranparajuli589

If this is the expected behavior from now on. Maybe we should refactor the tests again.

Raising this to @pmaier1: why can the admin see the mount path (file_target) of the recipient. This exposes the recipients path to the sharer. While it looks innocent enough when the receiver moves the mount point the sharer can see the new location (in OC10).
Again, IMO we should drop the file_target for sharers. https://github.com/owncloud/ocis/issues/2133#issuecomment-930161068

Any update on this issue?

Again, IMO we should drop the file_target for sharers.

If that's not needed for anything else, I agree. I've called it 'obsolete' earlier https://github.com/owncloud/ocis/issues/2133#issuecomment-897011414. Unless I got something wrong, of course.

Again, IMO we should drop the file_target for sharers.

If that's not needed for anything else, I agree. I've called it 'obsolete' earlier #2133 (comment). Unless I got something wrong, of course.

@phil-davis @individual-it so we adjust our tests to current ocis behaviour which is

Seems like oCIS now have Shares in file_target.
files_target: /Shares/
Confirmed actions: create share, list share and others as sharee see https://github.com/owncloud/ocis/issues/2540

If I understand @butonic correctly that whole field file_target should disappear in ocis, so the expectation for ocis would be
Then the fields of the last response about user "Carol" sharing with user "Alice" should not include
| file_target |

Is that correct @butonic ?
@SwikritiT could you find out (git bisect) when Shares was added to the file-target?

If I understand @butonic correctly that whole field file_target should disappear in ocis, so the expectation for ocis would be
Then the fields of the last response about user "Carol" sharing with user "Alice" should not include
| file_target |

Is that correct @butonic ?
@SwikritiT could you find out (git bisect) when Shares was added to the file-target?

Okay I can do that

@individual-it f2d36f663815e9a7cc41c5bbb0cfa827aef9f1e2 is the first bad commit. After this the shares got added to file_target

That is very old and its an update of reva, who knows what really happened in reva
I think we can take off the QA-team assignment for now, we need first to find out what is really the requirement.


Wallet > Token Creation - Inconsistent Max Amount Validation Errors

Hello,
Issue Impact: Minor
Apk: v0.98.24
Wallet: v1.1.2
Minor issue with inconsistent max amount validation errors.
What Happened?
Attempting to input between up to 19 zeroes results in "1000000000000 MAX..." error but attempting to input 20 zeroes results in java error.
Beyond 20 zeroes, the red validation text shows (no issues here)
What Did You Expect To Happen?
Error message for 20 zeroes would show the MAX error instead of Java error.
Steps to recreate:

Input 1+19 zeroes - try to create the token - Max error (screenshot 1)
Input 1+20 zeroes - try to create the token - Java error (screenshot 2)

Thanks
Jazmin

@eliasnemr Has the form validation been updated?


VSCode: JSX {} dynamic operator isn't higlighted

What package manager are you using?
yarn
What operating system are you using?
Windows
Describe the Bug
The JSX {} dynamic operator isn't higlighted
Steps to Reproduce
The JSX {} dynamic operator should be higlighted
Link to Minimal Reproducible Example (Optional)
No response

@RafidMuhymin can you provide an example of how this is highlighted in JSX but is not being highlighted in Astro? In my theme there is no special color provided to either of these. If there's a theme you use where that's not the case please let me know so I can check it out.

@matthewp Astro:

JSX:

Minimal repro:
---
// Please view the code in VSCode. Highlighting in GitHub is different from VSCode
---

<!DOCTYPE html>

Hello {src}!

    {()}

This was fixed, however something to note is that you very rarely see native highlighting for brackets these days due to VS Code's bracket colorization. So to see the updated colors, you'd have to disable that


Update steering council membership

cc @pangeo-data/pangeo-steering-council

I've put this up a bit prematurely. We are missing one procedural measure. Will convert this from a draft when ready.

Hi @jhamman - very happy to see all these new additions.
I decided to step down as well. I can modify the PR or maybe it's just easier you update it accordingly.
Thanks!

I think this needs approval of the current steering council, including those who are stepping down, so I have added @amanda-tan, @RPrudden, and @guillaumeeb to the approvers list.

A little sad, but this needs more time than I have, and I'll stay around.

😢  Guillaume you will always be part of the Pangeo family!

@RPrudden & @amanda-tan, would you mind clicking "approve" so that we can finalize this?

Great! This is done! Thanks everyone! I'll merge this and we will move forward with announcing the new steering council membership.


def scrape_fortinet(self, url):

Please add this only after a successful test. I am getting different errors on compiling same code multiple times.
Great thanks, and really appreciated for your dedicated and prompt follow up on this.

Merging with alpha branch

Thank you..!!
On Wednesday, 5 April 2017, shamlik<EMAIL_ADDRESS>wrote:

Merged #5
https://github.com/shamlikt/New-vulnerable-report-scraper-/pull/5.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/shamlikt/New-vulnerable-report-scraper-/pull/5#event-1030022019,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGmIr77H4VX0BplYgD0CqzYfDfBUEXllks5rs16kgaJpZM4MzN5Y
.

--
Best Regards,
Nooh Ibrahim
Cloud specialist
0097433312041
Sent from my iphone


bug with 'ignore_water' power

makes drowned not target players who have it(the lurker from [FABRIC] Monster Of The Ocean Depths mod as well, i guess same targetting system since guardians, elder guardians and land mobs are fine)

Fixed in 0.7.2. :)


[TC-ACE-1.2] Subscriptions,  Expected Outcome is Unsupported Access(0X7e) but TH2 receives a Subscription report from the DUT .

Test Case ID
[TC-ACE-1.2] Subscriptions
Describe Issue:
Step 18 , Step 19 :  Expected Outcome is Unsupported Access(0X7e) but TH2 receives a Subscription report from the DUT .

TH2 Subscribes to all test attributes and events expecting Unsupported Access  for privileges less than 5.

Step 24, Step 29,Step 33 :  (Steps 18 and 19 are Repeating )

I just tried this using chip-tool interactive mode:
accesscontrol write acl '[{"privilege": 4, "authMode": 2, "subjects":[112233], "targets":null}]' 17 0

operationalcredentials subscribe nocs 2 10 17 0

During the priming read I get:
[1659635146155] [78210:5525239] CHIP: [DMG] ReportDataMessage =
[1659635146155] [78210:5525239] CHIP: [DMG] {
[1659635146155] [78210:5525239] CHIP: [DMG] 	SubscriptionId = 0x1497d9ab,
[1659635146155] [78210:5525239] CHIP: [DMG] 	AttributeReportIBs =
[1659635146155] [78210:5525239] CHIP: [DMG] 	[
[1659635146156] [78210:5525239] CHIP: [DMG] 		AttributeReportIB =
[1659635146156] [78210:5525239] CHIP: [DMG] 		{
[1659635146156] [78210:5525239] CHIP: [DMG] 			AttributeStatusIB =
[1659635146156] [78210:5525239] CHIP: [DMG] 			{
[1659635146156] [78210:5525239] CHIP: [DMG] 				AttributePathIB =
[1659635146156] [78210:5525239] CHIP: [DMG] 				{
[1659635146156] [78210:5525239] CHIP: [DMG] 					Endpoint = 0x0,
[1659635146156] [78210:5525239] CHIP: [DMG] 					Cluster = 0x3e,
[1659635146156] [78210:5525239] CHIP: [DMG] 					Attribute = 0x0000_0000,
[1659635146156] [78210:5525239] CHIP: [DMG] 				}
[1659635146156] [78210:5525239] CHIP: [DMG]
[1659635146156] [78210:5525239] CHIP: [DMG] 				StatusIB =
[1659635146156] [78210:5525239] CHIP: [DMG] 				{
[1659635146156] [78210:5525239] CHIP: [DMG] 					status = 0x7e (UNSUPPORTED_ACCESS),
[1659635146156] [78210:5525239] CHIP: [DMG] 				},
[1659635146156] [78210:5525239] CHIP: [DMG]
[1659635146156] [78210:5525239] CHIP: [DMG] 			},
[1659635146156] [78210:5525239] CHIP: [DMG]
[1659635146156] [78210:5525239] CHIP: [DMG] 		},
[1659635146156] [78210:5525239] CHIP: [DMG]
[1659635146156] [78210:5525239] CHIP: [DMG] 	],
[1659635146156] [78210:5525239] CHIP: [DMG]
[1659635146156] [78210:5525239] CHIP: [DMG] 	InteractionModelRevision = 1
[1659635146156] [78210:5525239] CHIP: [DMG] }
[1659635146156] [78210:5525239] CHIP: [TOO] Response Failure: IM Error 0x0000057E: General error: 0x7e (UNSUPPORTED_ACCESS)

@aswathygrl   What exact results are you seeing?  What exact commands are you running?

commit f98f73380c22f410ff6f323f182774a78154b1ce (HEAD -> main, origin/main)  , I had run below test steps in Interactive mode. logs are attached from Step 16 to 19.
[TC-ACE - 1.2 ] Issues  IN STEPS 18 AND 19 .txt](https://github.com/project-chip/connectedhomeip/files/9266310/TC-ACE.-.SDK.ISSUE.IN.STEPS.18.AND.19.txt)

@aswathygrl Looking at that log, the commands are doing the following:

Set ACLs as follows:
a. Allow node 112233 to Administer endpoint 0.
b. Allow node 112233 to Manage endpoint 0.
Do various things with endpoint 0.

Since node 112233 is explicitly allowed to both Manage and Administer EP0, it can do all the "various things".
Just to be clear, an action is allowed if there is any ACL in the list allowing the action.

@cjandhyala The verification steps here need fixing.

I would like to know why instruction ./chip-tool interactive start operationalcredentials subscribe nocs  1 30 2 0 --fabric-filtered false  --keepSubscriptions 0 in the ACE-1.2 use case appears timeout after execution. Does TH2 mean to restart a new pc？

@lisaaaas ./chip-tool interactive start operationalcredentials subscribe nocs 1 30 2 0 --fabric-filtered false --keepSubscriptions 0 is not a valid command.  What actual commands are being run?

I am testing the ACE-1.2, first with networking, then with instruction accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": [{ "cluster": null, "endpoint": 0, "deviceType": null }]}]' 1 0， then with instruction  ./chip-tool interactive start operationalcredentials subscribe nocs  1 30 2 0 --fabric-filtered false  --keepSubscriptions 0 with timeout.

`Pls run this test in chip tool interactive mode  using the command  ./chip-tool interactive start
accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": [{ "cluster": null, "endpoint": 0, "deviceType": null }]}]' 1 0
On TH(Chiptool)1,Verify successfully  ACL attribute with a list of AccessControlEntryStruct entries containing 1 element.
[1659508250.468539][10228:10233] CHIP:EM: Removed CHIP MessageCounter:188603873 from RetransTable on exchange 14900i
[1659508250.468582][10228:10233] CHIP:DMG: WriteClient moving to [ResponseRe]
[1659508250.468646][10228:10233] CHIP:DMG: WriteResponseMessage =
[1659508250.468679][10228:10233] CHIP:DMG: {
[1659508250.468706][10228:10233] CHIP:DMG:      AttributeStatusIBs =
[1659508250.468745][10228:10233] CHIP:DMG:      [
[1659508250.468775][10228:10233] CHIP:DMG:              AttributeStatusIB =
[1659508250.468809][10228:10233] CHIP:DMG:              {
[1659508250.468841][10228:10233] CHIP:DMG:                      AttributePathIB =
[1659508250.468881][10228:10233] CHIP:DMG:                      {
[1659508250.468922][10228:10233] CHIP:DMG:                              Endpoint = 0x0,
[1659508250.468964][10228:10233] CHIP:DMG:                              Cluster = 0x1f,
[1659508250.469005][10228:10233] CHIP:DMG:                              Attribute = 0x0000_0000,
[1659508250.469044][10228:10233] CHIP:DMG:                      }
[1659508250.469087][10228:10233] CHIP:DMG:
[1659508250.469124][10228:10233] CHIP:DMG:                      StatusIB =
[1659508250.469163][10228:10233] CHIP:DMG:                      {
[1659508250.469202][10228:10233] CHIP:DMG:                              status = 0x00 (SUCCESS),
[1659508250.469240][10228:10233] CHIP:DMG:                      },
[1659508250.469279][10228:10233] CHIP:DMG:
[1659508250.469310][10228:10233] CHIP:DMG:              },
[1659508250.469354][10228:10233] CHIP:DMG:
[1659508250.469384][10228:10233] CHIP:DMG:              AttributeStatusIB =
[1659508250.469417][10228:10233] CHIP:DMG:              {
[1659508250.469448][10228:10233] CHIP:DMG:                      AttributePathIB =
[1659508250.469485][10228:10233] CHIP:DMG:                      {
[1659508250.469523][10228:10233] CHIP:DMG:                              Endpoint = 0x0,
[1659508250.469564][10228:10233] CHIP:DMG:                              Cluster = 0x1f,
[1659508250.469604][10228:10233] CHIP:DMG:                              Attribute = 0x0000_0000,
[1659508250.469644][10228:10233] CHIP:DMG:                              ListIndex = Null,
[1659508250.469682][10228:10233] CHIP:DMG:                      }
[1659508250.469723][10228:10233] CHIP:DMG:
[1659508250.469759][10228:10233] CHIP:DMG:                      StatusIB =
[1659508250.469796][10228:10233] CHIP:DMG:                      {
[1659508250.469834][10228:10233] CHIP:DMG:                              status = 0x00 (SUCCESS),
[1659508250.469873][10228:10233] CHIP:DMG:                      },
[1659508250.469912][10228:10233] CHIP:DMG:
[1659508250.469943][10228:10233] CHIP:DMG:              },
[1659508250.469979][10228:10233] CHIP:DMG:
[1659508250.470007][10228:10233] CHIP:DMG:      ],
[1659508250.470048][10228:10233] CHIP:DMG:
[1659508250.470077][10228:10233] CHIP:DMG:      InteractionModelRevision = 1
[1659508250.470105][10228:10233] CHIP:DMG: }
[1659508250.470228][10228:10233] CHIP:DMG: WriteClient moving to [AwaitingDe]
[1659508250.470299][10228:10233] CHIP:EM: Sending Standalone Ack for MessageCounter:48929405 on exchange 14900i
[1659508250.470380][10228:10233] CHIP:IN: Prepared secure message 0xffff994999e8 to 0x0000000000000001 (1)  of type 0x10 and protocolId (0, 0) on exchange 14900i with MessageCounter:188603874.
[1659508250.470426][10228:10233] CHIP:IN: Sending encrypted msg 0xffff994999e8 with MessageCounter:188603874 to 0x0000000000000001 (1) at monotonic time:<PHONE_NUMBER>98DDBE msec
[1659508250.470575][10228:10233] CHIP:EM: Flushed pending ack for MessageCounter:48929405 on exchange 14900i
[1659508250.470779][10228:10228] CHIP:CTL: Shutting down the commissioner
[1659508250.470818][10228:10228] CHIP:CTL: Stopping commissioning discovery over DNS-SD
[1659508250.470842][10228:10228] CHIP:CTL: Shutting down the controller
[1659508250.470874][10228:10228] CHIP:IN: Expiring all sessions for fabric 0x1!!
[1659508250.470904][10228:10228] CHIP:IN: SecureSession[0xffff84001930]: MarkForEviction Type:2 LSID:16459
[1659508250.470931][10228:10228] CHIP:SC: SecureSession[0xffff84001930]: Moving from state 'kActive' --> 'kPendingEviction'
[1659508250.470959][10228:10228] CHIP:IN: SecureSession[0xffff84001930]: Released - Type:2 LSID:16459
[1659508250.470990][10228:10228] CHIP:FP: Forgetting fabric 0x1
[1659508250.471029][10228:10228] CHIP:TS: Pending Last Known Good Time: 2022-08-01T09:44:35
[1659508250.471248][10228:10228] CHIP:TS: Previous Last Known Good Time: 2022-08-01T09:44:35
[1659508250.471279][10228:10228] CHIP:TS: Reverted Last Known Good Time to previous value
[1659508250.471327][10228:10228] CHIP:CTL: Shutting down the commissioner`
Pls run this test in chip tool interactive mode  using the command  ./chip-tool interactive start  operationalcredentials subscribe nocs  1 30 2 0 --fabric-filtered false  --keepSubscriptions 0 On TH(Chiptool)2,Verify TH  subscribes to the Node Operational Credentials cluster NOCs attribute, min interval 1, max interval 30, keep subscriptions false, fabric-filtered false and save SubscriptionId as subscription_noc [1659598415.554714][3022:3027] CHIP:DMG: ReportDataMessage = [1659598415.554746][3022:3027] CHIP:DMG: { [1659598415.554771][3022:3027] CHIP:DMG:        SubscriptionId = 0x692ae42d, [1659598415.554821][3022:3027] CHIP:DMG:        AttributeReportIBs = [1659598415.554857][3022:3027] CHIP:DMG:        [ [1659598415.554883][3022:3027] CHIP:DMG:                AttributeReportIB = [1659598415.554920][3022:3027] CHIP:DMG:                { [1659598415.554948][3022:3027] CHIP:DMG:                        AttributeDataIB = [1659598415.554981][3022:3027] CHIP:DMG:                        { [1659598415.555012][3022:3027] CHIP:DMG:                                DataVersion = 0xc0e77b57, [1659598415.555045][3022:3027] CHIP:DMG:                                AttributePathIB = [1659598415.555076][3022:3027] CHIP:DMG:                                { [1659598415.555111][3022:3027] CHIP:DMG:                                        Endpoint = 0x0, [1659598415.555146][3022:3027] CHIP:DMG:                                        Cluster = 0x3e, [1659598415.555182][3022:3027] CHIP:DMG:                                        Attribute = 0x0000_0000, [1659598415.555215][3022:3027] CHIP:DMG:                                } [1659598415.555251][3022:3027] CHIP:DMG: [1659598415.555284][3022:3027] CHIP:DMG:                                Data = [ [1659598415.555317][3022:3027] CHIP:DMG: [1659598415.555352][3022:3027] CHIP:DMG:                                ], [1659598415.555380][3022:3027] CHIP:DMG:                        }, [1659598415.555415][3022:3027] CHIP:DMG: [1659598415.555441][3022:3027] CHIP:DMG:                }, [1659598415.555481][3022:3027] CHIP:DMG: [1659598415.555507][3022:3027] CHIP:DMG:                AttributeReportIB = [1659598415.555542][3022:3027] CHIP:DMG:                { [1659598415.555570][3022:3027] CHIP:DMG:                        AttributeDataIB = [1659598415.555630][3022:3027] CHIP:DMG:                        { [1659598415.555667][3022:3027] CHIP:DMG:                                DataVersion = 0xc0e77b57, [1659598415.555696][3022:3027] CHIP:DMG:                                AttributePathIB = [1659598415.555729][3022:3027] CHIP:DMG:                                { [1659598415.555763][3022:3027] CHIP:DMG:                                        Endpoint = 0x0, [1659598415.555799][3022:3027] CHIP:DMG:                                        Cluster = 0x3e, [1659598415.555834][3022:3027] CHIP:DMG:                                        Attribute = 0x0000_0000, [1659598415.555868][3022:3027] CHIP:DMG:                                        ListIndex = Null, [1659598415.555901][3022:3027] CHIP:DMG:                                } [1659598415.555936][3022:3027] CHIP:DMG: [1659598415.555968][3022:3027] CHIP:DMG:                                Data = [1659598415.556026][3022:3027] CHIP:DMG:                                { [1659598415.556065][3022:3027] CHIP:DMG:                                        0xfe = 1, [1659598415.556100][3022:3027] CHIP:DMG:                                }, [1659598415.556128][3022:3027] CHIP:DMG:                        }, [1659598415.556163][3022:3027] CHIP:DMG: [1659598415.556189][3022:3027] CHIP:DMG:                }, [1659598415.556228][3022:3027] CHIP:DMG: [1659598415.556253][3022:3027] CHIP:DMG:                AttributeReportIB = [1659598415.556286][3022:3027] CHIP:DMG:                { [1659598415.556312][3022:3027] CHIP:DMG:                        AttributeDataIB = [1659598415.556343][3022:3027] CHIP:DMG:                        { [1659598415.556376][3022:3027] CHIP:DMG:                                DataVersion = 0xc0e77b57, [1659598415.556407][3022:3027] CHIP:DMG:                                AttributePathIB = [1659598415.556439][3022:3027] CHIP:DMG:                                { [1659598415.556472][3022:3027] CHIP:DMG:                                        Endpoint = 0x0, [1659598415.556507][3022:3027] CHIP:DMG:                                        Cluster = 0x3e, [1659598415.556542][3022:3027] CHIP:DMG:                                        Attribute = 0x0000_0000, [1659598415.556576][3022:3027] CHIP:DMG:                                        ListIndex = Null, [1659598415.556640][3022:3027] CHIP:DMG:                                } [1659598415.556678][3022:3027] CHIP:DMG: [1659598415.556713][3022:3027] CHIP:DMG:                                Data = [1659598415.556746][3022:3027] CHIP:DMG:                                { [1659598415.556781][3022:3027] CHIP:DMG:                                        0x1 = [ [1659598415.556889][3022:3027] CHIP:DMG:                                                        0x15, 0x30, 0x1, 0x1, 0x1, 0x24, 0x2, 0x1, 0x37, 0x3, 0x24, 0x13, 0x1, 0x18, 0x26, 0x4, 0x80, 0x22, 0x81, 0x27, 0x26, 0x5, 0x80, 0x25, 0x4d, 0x3a, 0x37, 0x6, 0x24, 0x15, 0x1, 0x24, 0x11, 0x2, 0x18, 0x24, 0x7, 0x1, 0x24, 0x8, 0x1, 0x30, 0x9, 0x41, 0x4, 0x8f, 0x5c, 0x62, 0xe1, 0x1e, 0xbe, 0x31, 0xab, 0xc3, 0xaa, 0x8, 0x98, 0x87, 0xc9, 0x26, 0x99, 0x98, 0x9a, 0xa2, 0x7c, 0xa, 0xfa, 0xa, 0xb1, 0x44, 0x6f, 0x5e, 0x78, 0x26, 0x74, 0xb1, 0x2a, 0xfe, 0x16, 0xc5, 0x7c, 0x24, 0x14, 0xce, 0x0, 0xb6, 0xe0, 0xdc, 0x96, 0x91, 0x60, 0x8c, 0xd2, 0xdb, 0xca, 0x9f, 0x8f, 0x2d, 0x7, 0xcd, 0x89, 0x9, 0xbb, 0xe3, 0x9a, 0x22, 0x57, 0xb6, 0x3e, 0x37, 0xa, 0x35, 0x1, 0x28, 0x1, 0x18, 0x24, 0x2, 0x1, 0x36, 0x3, 0x4, 0x2, 0x4, 0x1, 0x18, 0x30, 0x4, 0x14, 0xe1, 0x31, 0xf4, 0x95, 0xda, 0x55, 0x40, 0x59, 0xd4, 0xb4, 0x6d, 0x62, 0xbf, 0x7e, 0xab, 0xef, 0x88, 0x3c, 0x84, 0x3, 0x30, 0x5, 0x14, 0xc7, 0xe9, 0x58, 0xd6, 0x86, 0xe, 0x58, 0xeb, 0xff, 0xc5, 0x3, 0x75, 0x69, 0x5f, 0xa1, 0xd, 0x8d, 0x1f, 0x7b, 0xa5, 0x18, 0x30, 0xb, 0x40, 0x89, 0x44, 0xb0, 0x49, 0x79, 0x3f, 0x7, 0x29, 0xe5, 0xd9, 0xee, 0xeb, 0x6f, 0x18, 0xcf, 0x20, 0xb5, 0x63, 0x97, 0xef, 0xb4, 0x2, 0xc2, 0x73, 0xba, 0x17, 0xbe, 0x9, 0xcc, 0xcd, 0x4d, 0xd0, 0x6d, 0x6d, 0xd, 0x33, 0xf, 0xd7, 0xe9, 0x15, 0x16, 0x82, 0x79, 0x3d, 0x69, 0x38, 0x3d, 0x82, 0xbd, 0x7f, 0x17, 0x22, 0x1b, 0xc3, 0xf6, 0xc7, 0xe6, 0x8, 0x4c, 0x7b, 0xab, 0x39, 0x5c, 0xa0, 0x18, [1659598415.556962][3022:3027] CHIP:DMG:                                        ] (241 bytes) [1659598415.557011][3022:3027] CHIP:DMG:                                        0x2 = [ [1659598415.557121][3022:3027] CHIP:DMG:                                                        0x15, 0x30, 0x1, 0x1, 0x0, 0x24, 0x2, 0x1, 0x37, 0x3, 0x24, 0x14, 0x0, 0x18, 0x26, 0x4, 0x80, 0x22, 0x81, 0x27, 0x26, 0x5, 0x80, 0x25, 0x4d, 0x3a, 0x37, 0x6, 0x24, 0x13, 0x1, 0x18, 0x24, 0x7, 0x1, 0x24, 0x8, 0x1, 0x30, 0x9, 0x41, 0x4, 0xb2, 0x61, 0xc9, 0x38, 0xb9, 0x32, 0x73, 0xcc, 0x48, 0x95, 0x79, 0x1, 0x93, 0xd5, 0xa1, 0x54, 0x52, 0x9a, 0x3, 0x9d, 0x23, 0xe5, 0x52, 0x26, 0x3b, 0x7a, 0xa9, 0x4a, 0x8f, 0x34, 0x44, 0x81, 0x30, 0xe7, 0xa4, 0xc8, 0x8e, 0xe7, 0x1a, 0xe2, 0x91, 0xbb, 0xc6, 0x89, 0xe9, 0xb7, 0xd1, 0xf8, 0xc8, 0x1f, 0xe3, 0xfe, 0x8c, 0x5d, 0xad, 0xff, 0x98, 0x66, 0x5d, 0xbf, 0x57, 0xd0, 0x73, 0x9e, 0x37, 0xa, 0x35, 0x1, 0x29, 0x1, 0x18, 0x24, 0x2, 0x60, 0x30, 0x4, 0x14, 0xc7, 0xe9, 0x58, 0xd6, 0x86, 0xe, 0x58, 0xeb, 0xff, 0xc5, 0x3, 0x75, 0x69, 0x5f, 0xa1, 0xd, 0x8d, 0x1f, 0x7b, 0xa5, 0x30, 0x5, 0x14, 0xf6, 0xef, 0x1d, 0x69, 0xa5, 0xf7, 0x79, 0x7d, 0x53, 0x4a, 0xb6, 0x55, 0xe8, 0xe8, 0xbf, 0xa3, 0x90, 0xcb, 0x56, 0x20, 0x18, 0x30, 0xb, 0x40, 0xf2, 0xb2, 0xe6, 0xa0, 0xc2, 0xf, 0x81, 0x9d, 0xaa, 0x4d, 0xa6, 0xc5, 0xc9, 0x4b, 0x1f, 0x63, 0x68, 0x6c, 0x3e, 0x11, 0xbe, 0xd7, 0xfe, 0xf4, 0xe3, 0x56, 0x43, 0xe7, 0x95, 0xff, 0xa3, 0xae, 0xe4, 0x33, 0x3a, 0xd7, 0x26, 0xee, 0x1e, 0xc4, 0x92, 0xa2, 0x9a, 0x45, 0x62, 0x8e, 0xe9, 0x5d, 0x88, 0xcc, 0xba, 0xb0, 0x78, 0x6, 0xb, 0xfd, 0x56, 0x5c, 0xa5, 0x22, 0x98, 0xa9, 0xb0, 0xaf, 0x18, [1659598415.557195][3022:3027] CHIP:DMG:                                        ] (231 bytes) [1659598415.557234][3022:3027] CHIP:DMG:                                        0xfe = 2, [1659598415.557268][3022:3027] CHIP:DMG:                                }, [1659598415.557299][3022:3027] CHIP:DMG:                        }, [1659598415.557335][3022:3027] CHIP:DMG: [1659598415.557361][3022:3027] CHIP:DMG:                }, [1659598415.557393][3022:3027] CHIP:DMG: [1659598415.557417][3022:3027] CHIP:DMG:        ], [1659598415.557458][3022:3027] CHIP:DMG: [1659598415.557482][3022:3027] CHIP:DMG:        InteractionModelRevision = 1 [1659598415.557505][3022:3027] CHIP:DMG: } [1659598415.557850][3022:3027] CHIP:TOO: Endpoint: 0 Cluster: 0x0000_003E Attribute 0x0000_0000 DataVersion:<PHONE_NUMBER> [1659598415.560482][3022:3027] CHIP:TOO:   NOCs: 2 entries [1659598415.560556][3022:3027] CHIP:TOO:     [1]: { [1659598415.560586][3022:3027] CHIP:TOO:       Noc: [1659598415.562570][3022:3027] CHIP:TOO:       Icac: null [1659598415.562663][3022:3027] CHIP:TOO:       FabricIndex: 1 [1659598415.562690][3022:3027] CHIP:TOO:      } [1659598415.562741][3022:3027] CHIP:TOO:     [2]: { [1659598415.562781][3022:3027] CHIP:TOO:       Noc:<PHONE_NUMBER>240201370324130118260480228127260580254D3A370624150124110218240701240801300941048F5C62E11EBE31ABC3AA089887C92699989AA27C0AFA0AB1446F5E782674B12AFE16C57C2414CE00B6E0DC9691608CD2DBCA9F8F2D07CD8909BBE39A2257B63E370A350128011824020136030402040118300414E131F495DA554059D4B46D62BF7EABEF883C8403300514C7E958D6860E58EBFFC50375695FA10D8D1F7BA518300B408944B049793F0729E5D9EEEB6F18CF20B56397EFB402C273BA17BE09CCCD4DD06D6D0D330FD7E9151682793D69383D82BD7F17221BC3F6C7E6084C7BAB395CA018 [1659598415.562823][3022:3027] CHIP:TOO:       Icac:<PHONE_NUMBER>240201370324140018260480228127260580254D3A37062413011824070124080130094104B261C938B93273CC4895790193D5A154529A039D23E552263B7AA94A8F34448130E7A4C88EE71AE291BBC689E9B7D1F8C81FE3FE8C5DADFF98665DBF57D0739E370A3501290118240260300414C7E958D6860E58EBFFC50375695FA10D8D1F7BA5300514F6EF1D69A5F7797D534AB655E8E8BFA390CB562018300B40F2B2E6A0C20F819DAA4DA6C5C94B1F63686C3E11BED7FEF4E35643E795FFA3AEE4333AD726EE1EC492A29A45628EE95D88CCBAB078060BFD565CA52298A9B0AF18 [1659598415.562851][3022:3027] CHIP:TOO:       FabricIndex: 2 [1659598415.562875][3022:3027] CHIP:TOO:      } [1659598415.562929][3022:3027] CHIP:DMG: MoveToState ReadClient[0xffff8c008e40]: Moving to [AwaitingSu] [1659598415.563006][3022:3027] CHIP:EM: Piggybacking Ack for MessageCounter:207708623 on exchange: 29451i [1659598415.563092][3022:3027] CHIP:IN: Prepared secure message 0xffff8c005878 to 0x0000000000000002 (1)  of type 0x1 and protocolId (0, 1) on exchange 29451i with MessageCounter:125509363. [1659598415.563139][3022:3027] CHIP:IN: Sending encrypted msg 0xffff8c005878 with MessageCounter:125509363 to 0x0000000000000002 (1) at monotonic time:<PHONE_NUMBER>820B0B msec [1659598415.565134][3022:3027] CHIP:EM: Received message of type 0x4 with protocolId (0, 1) and MessageCounter:207708624 on exchange 29451i [1659598415.565183][3022:3027] CHIP:EM: Found matching exchange: 29451i, Delegate: 0xffff8c008e40 [1659598415.565222][3022:3027] CHIP:EM: Rxd Ack; Removing MessageCounter:125509363 from Retrans Table on exchange 29451i [1659598415.565249][3022:3027] CHIP:EM: Removed CHIP MessageCounter:125509363 from RetransTable on exchange 29451i [1659598415.565301][3022:3027] CHIP:DMG: SubscribeResponseMessage = [1659598415.565330][3022:3027] CHIP:DMG: { [1659598415.565355][3022:3027] CHIP:DMG:        SubscriptionId = 0x692ae42d, [1659598415.565388][3022:3027] CHIP:DMG:        MaxInterval = 0x1e, [1659598415.565414][3022:3027] CHIP:DMG:        InteractionModelRevision = 1 [1659598415.565438][3022:3027] CHIP:DMG: } [1659598415.565467][3022:3027] CHIP:DMG: Subscription established with SubscriptionID = 0x692ae42d MinInterval = 1s MaxInterval = 30s Peer = 01:0000000000000002 [1659598415.565496][3022:3027] CHIP:DMG: MoveToState ReadClient[0xffff8c008e40]: Moving to [Subscripti] [1659598415.565552][3022:3027] CHIP:DMG: Refresh LivenessCheckTime for 55000 milliseconds with SubscriptionId = 0x692ae42d Peer = 01:0000000000000002 [1659598415.565587][3022:3027] CHIP:EM: Sending Standalone Ack for MessageCounter:207708624 on exchange 29451i [1659598415.565652][3022:3027] CHIP:IN: Prepared secure message 0xffffa0dbb9e8 to 0x0000000000000002 (1)  of type 0x10 and protocolId (0, 0) on exchange 29451i with MessageCounter:125509364. [1659598415.565690][3022:3027] CHIP:IN: Sending encrypted msg 0xffffa0dbb9e8 with MessageCounter:125509364 to 0x0000000000000002 (1) at monotonic time:<PHONE_NUMBER>820B0E msec [1659598415.565811][3022:3027] CHIP:EM: Flushed pending ack for MessageCounter:207708624 on exchange 29451i

Why is it not a valid instruction, is there a change in the test case, which is the result of me executing the latest test case

Why is it not a valid instruction

The only non-optional argument "chip-tool interactive" takes is "start", and the optional arguments it takes do not include --keepSubscriptions.  So trying to run chip-tool interactive start operationalcredentials subscribe nocs 1 30 2 0 --fabric-filtered false --keepSubscriptions 0 will just give you an error like so:
[1674055141708] [59951:41441089] [TOO] InitArgs: Optional argument operationalcredentials does not exist.
Usage:
  ./out/debug/standalone/chip-tool interactive start [--paa-trust-store-path] [--cd-trust-store-path] [--commissioner-name] [--commissioner-nodeid] [--use-max-sized-certs] [--only-allow-trusted-cd-keys] [--trace_file] [--trace_log] [--trace_decode] [--ble-adapter]

I don't know where the instructions you are following come from, but if they say to run that command, they are wrong.
Also, none of this has to do with this initial issue, and should probably be in a new issue....

This test step is in the test documentation

The first instruction is executed on terminal 1 and the second instruction is executed on terminal 2

@lisaaaas Please file issues with the test plan verification steps in https://github.com/CHIP-Specifications/chip-test-plans/

But that said, what those instructions are trying to say, and not saying very clearly, is to run chip-tool interactive start and then at the interactive mode prompt to run operationalcredentials subscribe nocs 1 30 2 0 --fabric-filtered false --keepSubscriptions 0.  Whether it should work depends most immediately on whether the node was in fact commissioned with node id 2.

But that said, what those instructions are trying to say, and not saying very clearly, is to run chip-tool interactive start and then at the interactive mode prompt to run operationalcredentials subscribe nocs 1 30 2 0 --fabric-filtered false --keepSubscriptions 0. Whether it should work depends most immediately on whether the node was in fact commissioned with node id 2. And again, none of that has to do with this long-closed issue.

yeah，I am not sure why I operate on node 2 in interactive mode. I would like to know whether there are preconditions for executing test case TC-ACE-1.2

@lisaaaas Please file issues with the test plan verification steps in https://github.com/CHIP-Specifications/chip-test-plans/

This link opens with an error

This link opens with an error

That probably means you don't have access to that repository.  Please talk to CSA about that.

commit f98f73380c22f410ff6f323f182774a78154b1ce (HEAD -> main, origin/main) , I had run below test steps in Interactive mode. logs are attached from Step 16 to 19. [TC-ACE - 1.2 ] Issues IN STEPS 18 AND 19 .txt](https://github.com/project-chip/connectedhomeip/files/9266310/TC-ACE.-.SDK.ISSUE.IN.STEPS.18.AND.19.txt)

After looking at your test log,I am not sure why I operate on node 2 in interactive mode. I would like to know whether there are preconditions for executing test case TC-ACE-1.2


layout: some droplevels are not reachable

I started, adding a video left to the standard white text area in VIPIN. Afterwards I wasn’t able to add e.g. a text above or beneath as a new line over the complete width. (CouldnÄt meka the black line appear)

/close due to inactivity


Update bundle to 2.10.1

Merge / deployment checklist

[ ] Confirm this change is backwards compatible with existing workflows.
[ ] Confirm the readme has been updated if necessary.
[ ] Confirm the changelog has been updated if necessary.

Why r u sending me this
Eric

From: Alexander Eyers-Taylor @.>
Sent: Tuesday, July 19, 2022 9:39:11 AM
To: github/codeql-action @.>
Cc: Subscribed @.***>
Subject: Re: [github/codeql-action] Update bundle to 2.10.1 (PR #1143)
Merged #1143https://github.com/github/codeql-action/pull/1143 into main.
—
Reply to this email directly, view it on GitHubhttps://github.com/github/codeql-action/pull/1143#event-7021351354, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZ4MCPIMC4M5BATTXUH6AYDVU24Y7ANCNFSM53SPZZVQ.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

@Ep262626 you are receiving notifications for this GitHub repository because you are currently subscribed to it, according to https://github.com/github/codeql-action/watchers. If you'd like to stop receiving notifications from this repository, please click the Unsubscribe link in the email you received. Alternatively, sign into your GitHub account, go to https://github.com/github/codeql-action, click Unwatch at the top of the page, then Ignore.


remove unused remark from locale files - fix issue #5415

Closes #5415
1-liner summary:
I had checked for limit validation on the name and there was no validation so that we could remove the unused remark.

@Mac3n thank you!


Update README.rst

The Cricsheet Matches site indicates it's data about cricket, not baseball.

Thanks for your correction! :)


operator project-quay (3.9.0-nightly.20230221)

Add 3.9.0-nightly.20230221 to community operators

/merge possible

/merge possible


How to replicate an instance of console application?

Hi,
I am having an issue with the replication of a console app instance as in console app i have integrated some api and i am getting a respond from the server and it is getting replicated to my console application but i am unbale to see it on my SFB UI so how to replicate that instance of a console application to SFB UI.

the console app and SfB are totally separate application, and we do not have control to replicate them.

Thanx for the help!!!


Remove the use of CBOR in Merkle Trie

Remove the reliance on CBOR and encode the merkle nodes using protocol
buffers. Introduces the messages MerkleNode and MerklePath, which
provide the serializable containers for what is stored in the dict
version of the nodes.
This only replaces the nodes at the serialization seam.  The nodes
during the operation of the trie are materialized into standard python
dicts, as per previous operation.

This results in far slower behavior, so closing


Use Ember.keys over Object.keys for polyfill support on older browsers

https://github.com/emberjs/ember.js/blob/v1.11.1/packages/ember-metal/lib/keys.js#L3

If you want to polyfill older browsers you'll need to drop .forEach as well. Maybe there's more.

Seems like Ember has that covered for you since they add forEach to Array.prototype. Unless ES5_SHIM is explicitly set to false, it will add those polyfills for you.
https://github.com/emberjs/ember.js/blob/614cfdc131b3c60d19747c80d8c7c8d7da17619d/packages/ember-metal/lib/array.js#L113
https://github.com/emberjs/ember.js/blob/614cfdc131b3c60d19747c80d8c7c8d7da17619d/packages/ember-metal/lib/core.js#L176

:+1:  Can we move forward on this?

@mmun is the one to answer that question ;)

:shipit:

@jamiebikies did you need me to do anything else? Would :heart: to get this merged! Thanks.

ping @jamiebikies @mmun

Thanks @dasnixon!


Dictionary not working properly

Description
When a selected cell of a field/column referenced to the value list with a foreign key is NULL, it works - i.e. all values in the dictionary are displayed in the Value panel, double clicking fills the desired value into the selected cell of the referenced field/column.
When/Once the cell of a referenced field/column contains a value, the Value panel only shows this one value or only values of the dictionary starting with the same character as the cell value.
This can temporarily be fixed with clicking Define Description and (instantly) closing the pop-up window for editing the value/description (not doing anything except clicking OK). However, leaving the cell of the referenced field/column and re-selecting it, same problem...
The field/column name in my table serving as dictionary is equal to the name of the referenced field/column. I renamed it to "value" thinking there might be a problem caused by the column name - same behaviour, dictionary does not work properly. So this obviously doesn’t cause the problem.
UPDATE: The problem occurs (seemingly) when leaving the column and re-selecting it (or the cell respectively) with the value filled with a dictionary entry.
DBeaver Version
Community Edition <IP_ADDRESS>302180832
Operating System
macOS Ventura 13.2.1
Database and driver

SQLite
sqlite-jdbc-<IP_ADDRESS>.jar

Steps to reproduce
No response
Additional context
No response
https://user-images.githubusercontent.com/74900017/222704182-d82950d5-378a-4579-9a90-1b1c9ec92881.mp4

Sure - edited my initial post and added a demonstration video.
Seemingly, the behaviour is a little different and only occurs when leaving the cell/column and then re-selecting it. Hope the video shows this clearly.

Could you please send me the log files? You can find instructions here: https://dbeaver.com/docs/wiki/Log-files/. Thank you.

I just send you all available log files by mail, since I didn’t won't to post them here publicly.

java.lang.NumberFormatException: For input string: "IN (659,493,139,143,324,367,373,482,504,505,649,658,553,537,545,613,684,633)"
	at java.base/java.lang.NumberFormatException.forInputString(Unknown Source)
	at java.base/java.lang.Integer.parseInt(Unknown Source)
	at java.base/java.lang.Integer.valueOf(Unknown Source)
	at org.jkiss.dbeaver.utils.GeneralUtils.convertString(GeneralUtils.java:211)
	at org.jkiss.dbeaver.model.DBUtils.compareDataValues(DBUtils.java:2195)
	at org.jkiss.dbeaver.model.exec.DBCLogicalOperator$1.evaluate(DBCLogicalOperator.java:37)
	at org.jkiss.dbeaver.ui.controls.resultset.ResultSetModel$AttributeColorSettings.evaluate(ResultSetModel.java:102)
	at org.jkiss.dbeaver.ui.controls.resultset.ResultSetModel.updateRowColors(ResultSetModel.java:825)
	at org.jkiss.dbeaver.ui.controls.resultset.ResultSetModel.updateColorMapping(ResultSetModel.java:774)
	at org.jkiss.dbeaver.ui.controls.resultset.colors.ColorSettingsDialog.okPressed(ColorSettingsDialog.java:674

java.lang.NumberFormatException: For input string: "659,493,139,143,324,367,373,482,504,505,649,658,553,537,545,613,684,633"
	at java.base/java.lang.NumberFormatException.forInputString(Unknown Source)
	at java.base/java.lang.Integer.parseInt(Unknown Source)
	at java.base/java.lang.Integer.valueOf(Unknown Source)
	at org.jkiss.dbeaver.utils.GeneralUtils.convertString(GeneralUtils.java:211)
	at org.jkiss.dbeaver.model.DBUtils.compareDataValues(DBUtils.java:2195)
	at org.jkiss.dbeaver.model.exec.DBCLogicalOperator$1.evaluate(DBCLogicalOperator.java:37)
	at org.jkiss.dbeaver.ui.controls.resultset.ResultSetModel$AttributeColorSettings.evaluate(ResultSetModel.java:102)
	at org.jkiss.dbeaver.ui.controls.resultset.ResultSetModel.updateRowColors(ResultSetModel.java:825)
	at org.jkiss.dbeaver.ui.controls.resultset.ResultSetModel.appendData(ResultSetModel.java:878)
	at org.jkiss.dbeaver.ui.controls.resultset.ResultSetModel.setData(ResultSetModel.java:734)
	at org.jkiss.dbeaver.ui.controls.resultset.ResultSetViewer.setData(ResultSetViewer.java:2360)
	at org.jkiss.dbeaver.ui.controls.resultset.ResultSetDataReceiver.fetchEnd(ResultSetDataReceiver.java:180)
	at org.jkiss.dbeaver.model.impl.jdbc.struct.JDBCTable.readData(JDBCTable.java:213)

@CommunyAS, It looks like these are the exceptions which may be the issue, not entirely sure how they happen for now.

Yes there is color formatting. But they do not cause the problem, the problem with the dictionary existed (and still exists) before I set row colors and the formatting apply to a different table that I currently work with.

@CommunyAS, Could you see if the issue still exists in the release version of DBeaver?

@Destrolaric, I just installed the latest DBeaver Community built <IP_ADDRESS>304091457 and tried. The problem still exists.
I now realised that when selecting an empty field (NULL) of a column with dictionary reference, all dictionary entry are displayed and they remain displayed when selecting fields containing a value (with the respective value highlighted in the dictionary). If first selecting a field already containing a value, only this value appears in the dictionary (i.e. situation as described above).
... unfortunately, I do not no if this behaviour existed before.

Unfortunately, we can't reproduce your issue. Could you provide a DDL to recreate an issue? We need to know at least create statements for the table where the reference from and the target table on which the issue appears.

It's been a long time since no update here, so I'm closing this issue.
Please, let me know if the issue is still actual and provide some minimal example to reproduce your issue.


Replace vulnerable satori/go.uuid with google/uuid

It's essentially a drop-in replacement.
with google/uuid, uuid.New() produces a v4 uuid by default, so produces the same behavior.
this is the relevant CVE: https://pkg.go.dev/vuln/GO-2022-0244

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 61.23%. Comparing base (b435f4d) to head (b3e58bb).
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #221      +/-   ##
==========================================
+ Coverage   61.00%   61.23%   +0.22%
==========================================
  Files          18       20       +2
  Lines        2072     1816     -256
==========================================
- Hits         1264     1112     -152
+ Misses        680      576     -104
  Partials      128      128

Files
Coverage Δ

pkg/loadtest/worker.go
60.96% <100.00%> (+2.13%)
:arrow_up:

... and 18 files with indirect coverage changes


New syntax tests

Some extra testing for the recent updates.
In the same order as they appear in the file

Stuff like E and Pi is really a numeric constant, not a function
If there is a comparison category, why are < and > not there?
/; and /: are not being parsed together as operators
Red cannot be a constant as it has evaluation semantic attached
I don't think options should have the same scope as function parameters
The patter at line 131 is breaking the definition scope (see test at 135)
Placeholder in strings are not supported

I think the most serous issue is the function definition scope at point 6.

Hello. Thanks for your syntax tests. It really helped.
Some changes were made in commit 42346646a820acd2c0a667bbabb5e8fa6809c6d0.

Stuff like E and Pi is really a numeric constant, not a function

Good issue. Fixed. I will tell you how I categorize build-in symbols. Take any symbol foo as an example:

If foo::usage begins with \!\(\*RowBox, we assume foo as an function
If foo::usage contains regex is an? (\w+ )?option, we assume foo as an option
In other cases, we assume foo as an constant

Hope you can optimize my categorization method.

If there is a comparison category, why are < and > not there?
/; and /: are not being parsed together as operators

Good issue. Fixed. My mistake.
About /:, I haven't come up with a good idea to render parameters as parameters. But the good thing is, Mathematica doesn't render them as parameters either. (smile

Red cannot be a constant as it has evaluation semantic attached

I'm not sure I get your point. (I'm a English learner) But if you mean Red = RGB[1, 0, 0], my answer is no, because Red is a built-in constant.

I don't think options should have the same scope as function parameters

However, I don't think options should have the same scope as functions or constants either. What scope do you think is proper?
Besides, in python, if you write foo(bar = 1) as a function call, you will find bar be recognized as variable.parameter.python, so options and parameters sharing the same scope makes sense to some extent.

The patter at line 131 is breaking the definition scope (see test at 135)

I'm not sure if the bug is fixed or not. The syntax file has been changed. If not, tell me.

Placeholder in strings are not supported

Sorry, but I just don't know what placeholder is displayed in raw texts. Isn't it \[Placeholder]?

I don't think options should have the same scope as function parameters

However, I don't think options should have the same scope as functions or constants either. What scope do you think is proper?
Besides, in python, if you write foo(bar = 1) as a function call, you will find bar be recognized as variable.parameter.python, so options and parameters sharing the same scope makes sense to some extent.

Maybe what I mean by parameter is more a Pattern in the language. My point is that I wouldn't like to have options highlighted in a different way then functions are they are all built-in system symbols.

Red cannot be a constant as it has evaluation semantic attached

I'm not sure I get your point. (I'm a English learner)
But if you mean Red = RGBColor[1, 0, 0], my answer is no, because Red is a built-in constant.

Red is fundamentally different from 1 because it does have evaluation rule attached. It the same reason why I think MachinePrecision is a (numeric) constant while $MachinePrecision is not.
Overall, it's not a bad heuristic what you are using.
I am trying to put together some improvements with @chere005 in this branch.

@batracos Try to fork from the develop branch and send you prs to that branch.
I'll merge your pr, it really helped. But see this:

The patter at line 131 is breaking the definition scope (see test at 135)

Try again to see if the problem exist till now.


[docs] Update the website 12/6/2017

Recipes concerning CI integration added + new font for Linux
Preview at: https://vasilystrelyaev.github.io/testcafe
Merge to update the website.
\cc @DevExpress/testcafe-docs

Umph, it's only fixed in Chrome on Linux, not Firefox. Wait a bit.

Oh, now these line endings


Fix lint failure on travis ci

Fails with System limit for number of file watchers reached, which is weird because there should be no watchers involved at all.

Fixed by PR #76.


Fixing tabular test

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/platform_tests ref=tabular_fix

/platform_tests ref=tabular_fix


support asterix syntax

instead of endewenn, endeAnweisung, etc. there is also a variant with *wenn, *Anweisung, ... especially in legacy code.
Adding support for this syntax shouldn't add too much complexity.

implemented in 9f7ac47b45a324c0931420b41ce64f31c4ade117


move-vnc-logs-to-dir-for-session-files

!test

!test

Refer to this link for build results (access rights to CI server needed):
http://jenkins.2gis.local/job/vmmaster.performance.test/159/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
http://jenkins.2gis.local/job/vmmaster.regression/404/
Test PASSed.

:+1:


[KYUUBI #5599] Correct the parameter name of fetching op log in RESTful API

Why are the changes needed?

It corrects the fetching op log Rest API documentation to match request parameter case in code, solving issue #5599
How was this patch tested?
No tests needed.
Was this patch authored or co-authored using generative AI tooling?

No AI tool has been used for this patch.

Codecov Report

Merging #5673 (f134af0) into master (eb84e15) will decrease coverage by 0.10%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #5673      +/-   ##
============================================
- Coverage     61.47%   61.38%   -0.10%
  Complexity       23       23
============================================
  Files           603      603
  Lines         35644    35644
  Branches       4875     4875
============================================
- Hits          21913    21880      -33
- Misses        11358    11387      +29
- Partials       2373     2377       +4

see 15 files with indirect coverage changes
:mega: Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!

Thanks, merged to master(1.9.0)/branch-1.8(1.8.1)/branch-1.7(1.7.4)


Built in policy definitions have been updated, instructions no longer work

"Azure Active Directory only authentication" should be changed to "Microsoft Entra-only authentication" to match the updated names of built-in policy definitions.

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

ID: 74335d6e-1b9a-6780-b5e6-a2c3744b1039
Version Independent ID: 94205b52-65fc-a8fa-b74a-0a2897741ec1
Content: Using Azure Policy to enforce Microsoft Entra-only authentication - Azure SQL Database & Azure SQL Managed Instance
Content Source: azure-sql/database/authentication-azure-ad-only-authentication-policy-how-to.md
Service: sql-db-mi
Sub-service: security
GitHub Login: @nofield
Microsoft Alias: nofield

Thanks for your feedback! We're aware of this and are working to update the docs. There are additional changes to our policies which are rolling out shortly, which is why we held off on making the rebranding changes to date. Apologies if this has been impactful on your productivity!

Didn't cause too much delay.  Thank you, fellow Jordan.


runtime: Replace "process is stopped" with "process exits"

proc(5) describes the following state entries in
proc/[pid]/stat (for modern kernels):

R Running
S Sleeping in an interruptible wait
D Waiting in uninterruptible disk sleep
Z Zombie
T Stopped (on a signal)
t Tracing stop
X Dead

and ps(1) has a bit more context (for modern kernels):

D uninterruptible sleep (usually IO)
R running or runnable (on run queue)
S interruptible sleep (waiting for an event to complete)
T stopped by job control signal
t stopped by debugger during the tracing
X dead (should never be seen)
Z defunct ("zombie") process, terminated but not reaped by its
parent

So I expect "stopped" to mean "process still exists but is paused,
e.g. by SIGSTOP".  And I expect "exited" to mean "process has finished
and is either a zombie or dead".
After this commit, git grep -i stop only turns up poststop-hook
stuff, a reference in principles.md, a "stoppage" in LICENSE, and some
ChangeLog entries.
This also replaces "container's process" with "container process" to
match usage in the rest of the repository.  After this commit:
$ git grep -i "container process" | wc -l
13
$ git grep -i "container's process" | wc -l
1

LGTM

Looks fine. Needs rebase.

On Tue, May 31, 2016 at 09:41:40AM -0700, Mrunal Patel wrote:

Looks fine. Needs rebase.

Rebased with 23009bb → a95eb3b, although again 1 I don't see any changes
to the patch.

Maybe needs a reroll with my suggested updates to #462.

Rebased and adjusted along the lines of my #464 comments with a95eb3b
→ 5816f31.

Rebased onto master with 5816f31 → 7797b33.

@crosbymichael PTAL

LGTM

@hqhq, @mrunalp, now that @crosbymichael has LGTMed this, do either of you want to re-approve it?

LGTM


Anchor free on edgetpu

As ancor free One stage object detection and kpts regression are going to be more and more popular can you add some kind of example on how to standardize ti handle these kind of models without using any Google/Coral team "canned solution"?
Generally all these research papers prefer pythorch code relase so It would be really useful to know to handle these models in Coral with an optimized pieline.
Also point 2 at coral-posenet mention some optimized custom ops for heatmap handling that instead It could be useful in general for anchor-free models.
See also:
https://github.com/tensorflow/hub/issues/424
https://github.com/google-coral/tutorials/issues/1
https://github.com/google-coral/project-posenet/issues/16

Hi, thanks for suggesting some alternative models. They're definitely interesting as are many other models. Unfortunately, given the small size of our team, we're able to test only a limited number of models, and this one is currently not a priority.
All the tools necessary to convert and compile models are available publicly, so we encourage you to experiment with different model architectures.

@mtyka At least could you plan expand class/bbox to support also arbitrary keypoints regression in support classes?
https://github.com/google-coral/edgetpu/blob/master/edgetpu/detection/engine.py#L24

Ok the new ticket on this specific subtopic is at https://github.com/google-coral/edgetpu/issues/51