Vv/8 removals/abstract test task

Fixes #?
Context

Contributor Checklist

[ ] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[ ] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[ ] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[ ] Provide unit tests (under <subproject>/src/test) to verify logic
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[ ] Ensure that tests pass sanity check: ./gradlew sanityCheck
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[x] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in licens

Fixes #?
Context
Contributor Checklist

[ ]  Review Contribution Guidelines
[ ]  Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[ ]  Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[ ]  Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ]  Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[ ]  Provide unit tests (under <subproject>/src/test) to verify logic
[ ]  Update User Guide, DSL Reference, and Javadoc for public-facing changes
[ ]  Ensure that tests pass sanity check: ./gradlew sanityCheck
[ ]  Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[ ]  Verify design and implementation
[ ]  Verify test coverage and CI build status
[ ]  Verify documentation
[ ]  Recognize contributor in licens

mi sofwer o aplicaciones es x que 3seros manipulan y yo no doy ninguna seguro o que regresen el articulo ya manipulado x otras personas o agencias guvernamentales un articulo manipulado no aseguro que tenga uso correcto no garantiso mis productos ya manipulados ni pueden regresar se tienen que pagar y ustedes arreglarlo ya que ustedes permitieron la manipulacion de otras personas y no es garantia de que trabaje 100% .


Galactic code review

Made most changes suggested in PR25 https://github.com/nobleo/full_coverage_path_planner/pull/25

ping

These improvements all look good, so approving.
But this PR is of course only a review of the improvements, not a full review. So that issue stays open.
I'll pick that up later this week.


Restore Intel MPI gatherv setting on Milan

As found by @pcolarco, occasionally with Intel MPI checkpoint writes will fail. Debugging by @bena-nasa found that the fix is an old favorite I_MPI_ADJUST_GATHERV=3 previously added back in #119.
This was removed on Milan nodes at NCCS as it didn't seem to be needed anymore. But it apparently still is at times.

Note: Keeping draft until @wmputman can review

We now have a second data point from @mmanyin that this helps. On a run with GMI he got:
borgk081:rank0: Exhausted 1048576 MQ irecv request descriptors, which usually indicates a user program error or insufficient request descriptors (PSM3_MQ_RECVREQS_MAX=1048576)

I had him try:
PSM3_MEMORY=large

which @wmputman had suggested to someone on Teams, but no help.
He then tried:
PSM3_MQ_RECVREQS_MAX=2097152

But nope. Only I_MPI_ADJUST_GATHERV=3 helped. As such, I think this might need to go (back) in.
I am undrafting.

and Mike Mehari just hit this too...


running vue-tsc with 1.7 takes 5min instead of 1.5min

I recently updated from vue-tsc v1.2 to the prereleased 1.7 and my ci went up from only 1.5min to a whopping 5min.
Since since is surely not by design, I wonder what changed that makes it so slow and if that is expected.
I will update this ticket with a more narrow version constraint to see with which version it got so slow
// EDIT:
The time increase happens from version 1.5 to version 1.5.1.
These are the changes made between the versions:
https://github.com/vuejs/language-tools/compare/v1.5.0...v1.5.1
Exact commit that caused it:
https://github.com/vuejs/language-tools/commit/6d8829980981b04f6ce69462e47c6be5825088b3

This should probably be reopened since the PR that closed this was reverted since it didn't fix this issue.


Refactor IPC API implementation

This is my go on the IPC API.
The driver events are now expressed by a Stream. This also allowes for multiple listeners.
Using the sync API, one can now add many receiver callbacks. The termination is now expressed using a boolean return value.
driver.add_event_receiver(|cmd| {
  ...
  if finished {
    false
  } else {
    true
  };
});

Maybe a subscription object is better?
let subscription = driver.add_event_receiver(|cmd| { ... });
...
subscription.cancel();

(Changes are not fully tested)

I was thinking about the possibility to easily revert the drivers state to the persistant state. There could be a method Client::revert() or Client::revert_to_persistant() that will load back the saved state from the registry.

I was thinking about the possibility to easily revert the drivers state to the persistant state. There could be a method Client::revert() or Client::revert_to_persistant() that will load back the saved state from the registry.

That's a good suggestion.
What do you think about having the method fetch and convert the persistent state to Vec<Monitor> and let the caller do what they want with it? We could keep the one that also reverts the driver in one call as well if it's still desirable

What do you think about having the method fetch and convert the persistent state to Vec<Monitor> and let the caller do what they want with it? We could keep the one that also reverts the driver in one call as well if it's still desirable

In any case, there could be a method on the Client that deserializes the persistend state: Client::read_persistent() -> Vec<Monitor> (also forwarded in DriverClient?).
Then, there can be a method on the DriverClient to read this state and write it in its own state: DriverClient::load_persiststent().
But Client::revert_to_persistant() is still good to have (also forwarded in DriverClient).

In any case, there could be a method on the Client that deserializes the persistend state: Client::read_persistent() -> Vec<Monitor> (also forwarded in DriverClient?).
Then, there can be a method on the DriverClient to read this state and write it in its own state: DriverClient::load_persiststent().
But Client::revert_to_persistant() is still good to have (also forwarded in DriverClient).

That sounds perfect. I'll add that after this pr is merged

I would prefer a subscription object instead

I have implemented this now.
One thing to note, there is no good way to cancel the subscription from the callback itself now. Doing this will involve creating some shared state where the subscription is moved into after subscribing, so something like Arc<Mutex<Option<EventsSubscription>>>.
Example:
let shared_sub = Arc::new(Mutex::new(None::<EventsSubscription>));

let sub = client.add_event_receiver({
    let shared_sub = shared_sub.clone();
    move |event| {
        println!("{:?}", event);
        // ...
        shared_sub.lock().unwrap().as_mut().unwrap().cancel();
    }
});

*shared_sub.lock().unwrap() = Some(sub);

I would prefer a subscription object instead

I have implemented this now.
One thing to note, there is no good way to cancel the subscription from the callback itself now. Doing this will involve creating some shared state where the subscription is moved into after subscribing, so something like Arc<Mutex<Option<EventsSubscription>>>.
Example:
let shared_sub = Arc::new(Mutex::new(None::<EventsSubscription>));

let sub = client.add_event_receiver({
    let shared_sub = shared_sub.clone();
    move |event| {
        println!("{:?}", event);
        // ...
        shared_sub.lock().unwrap().as_mut().unwrap().cancel();
    }
});

*shared_sub.lock().unwrap() = Some(sub);

Also: What should happen if the callback panics? Currently the task would just stop without notice. Maybe EventSubscription::cancel() could return a Result? What would the Error type be then?

I don't feel it matters much here if the callback panics. It does print a message, and the task exiting on panic is expected (similar to what would happen if a thread panicked). Though a note could be added if there's anything we want the user to be clear about. Do you feel it would be useful to catch unwind, mark the panic, resume unwind, and notify on cancel?
I just did some testing and found that the cb isn't getting executed at all.

I just did some testing and found that the cb isn't getting executed. The streams are receiving as expected, it seems to stop working at RUNTIME.spawn in EventsSubscription. A block_on does execute it all the way (just a test to see if that was the issue), but spawn seems to not

This is wired, because all unit tests pass and they do check if the callback is run or not. I need a bit more context to make sense of the situation here. Maybe the runtime was blocked somehow in your tests? Did you call the API from within the runtime? RUNTIME.spawn() does not immediately start execution, it just sends it of to be scheduled for execution.

This is wired, because all unit tests pass and they do check if the callback is run or not. I need a bit more context to make sense of the situation here. Maybe the runtime was blocked somehow in your tests? Did you call the API from within the runtime? RUNTIME.spawn() does not immediately start execution, it just sends it of to be scheduled for execution.
You can try tokio::task::yield_now().await after calling add_event_receiver() to give execution back to tokio.

So far from what I've been able to gather, the test event_receiver_cancel_from_cb() still passes after a panic is introduced into the callback. The first one however seems to properly fail when doing the same thing, so it applies only to this test. Hmm
      let sub = client.add_event_receiver({
            let shared_sub = shared_sub.clone();
            move |event| {
                panic!();
            }
        });

So far from what I've been able to gather, the test event_receiver_cancel_from_cb() still passes after a panic is introduced into the callback. The first one (event_receiver()) properly fails when doing the same thing, so it applies only to this test. Hmm

Yes, this is correct. This makes sense, because when the callback panics, the receiver used to cancel the callback is dropped and closed. If you now call cancel(), it returns false, which is actually the expected behaviour, because the callback was already "canceled".

Give me a moment to track this original problem down. I'll reply back when I have more context.

If you'd like to test what I was talking about earlier, here's how:
In the python bindings dir, lib.rs, change receive() to the following. Compile the program, change the extension to .pyd
    fn receive(&mut self, callback: Option<PyObject>) {
        if let Some(callback) = callback {
            self.client.add_event_receiver(move |cmd| {
                println!("{cmd:?}");
                let EventCommand::Changed(data) = cmd else {
                    unreachable!()
                };

                Python::with_gil(|py| {
                    let state = state_to_pylist(py, &data);
                    let Ok(state) = state else {
                        return;
                    };

                    if let Err(e) = callback.call1(py, (state,)) {
                        e.print(py);
                    }
                });
            });
        }
    }

Then run this python:
from vdd import *
c = DriverClient()

def recv(d):
    print(d)

c.receive(recv)

Edit 2: Okay I think we got it now. Not exactly surprising (obviously, give the behavior of receivers), but we need to add a comment explaining that the returned value needs to be saved and not dropped until done, otherwise the callback will stop firing. Not binding the value to something will also cause a drop before end of scope. Though obvious, it's an easy gotcha people may accidentally hit.

This is not the behavior I expected nor wanted. I tracked that issue down and fixed it. If the subscription gets dropped, the callback will still run. This behavior is in line with the behavior of thread::spawn or task::spawn. When you drop the JoinHandle, the thread/task will be detached.

The last remaining unresolved comment (below) is already taken care of, isn't it?

Basically, what I'm envisioning here is that read errors out, but it's then confusing to the library user on why they aren't receiving any messages (e.g. on their event stream).

As far as this, I can take care of handling the error and a callback notification system of sorts / letting user know they got disconnectd.

The senders should be fine since the caller will receive errors if they try to send, but since we still hold onto a broadcast sender, the subscribers won't receive a None when the stream should be closed.

Iirc, this is already fixed after you changed the Client to hold a receiver instead.

So I think the previous one can be marked as resolved.

Lgtm! If you feel it's good to go, I'm fine merging it right now.

Merged now. Thank you for the time you put into this contribution! <3


Telocyte and Lymphoblast do not have explicit parents

Current telocyte (CL:0017004) and lymphoblast (CL:0017005) do not have explicit parentage.
The only subclass they have is
lymphoblast:

telocyte:

I am guessing this is why they seem orphaned in the .obo files
Can we split these up into separate subClassOf restrictions? Is there any implications on this?

Split them up.  The split up axioms are logically equivalent to the combined one, in that there is an implicit 'and' between subclass axioms, in any case, but obviously tools are confused.

Oh, that is probably something I did! But somehow that slipped through review - sorry!


Unclear UI feedback when attempting to plot too many rows without downsampling

If you plot data that must be downsampled, then try to disable downsampling, you confusingly get a "downsampling failed" error in the UI. The downsampling icon stays in enabled, and nothing about the plot changes.
t = emptyTable(200_001).update("Time = currentTime()").update("Val = Math.random()")

plot = figure().plot("Plot", t, "Time", "Val").show()

Plot when first displayed:

After clicking to disable downsampling:

The console has this message:
b9fab0f5-89de-488c-bfd1-1590c687b0bd:1 Uncaught (in promise) Too many items to disable downsampling

Instead of "downsampling failed", the UI should at least have the explicit "Too many items to disable downsampling" message. Even better would be to actually toggle the 'downsampling' button to off, but gray-out the chart and show the "too many items" message over the chart. Or disable the option to turn off downsampling, or pop up the "too many messages" right on your mouse cursor when you click — anything to make it more obvious that we responded to your click but we can't do anything about it.
Relates to #1520.

@rbasralian - just curious, why are you disabling downsampling? Wondering if we should just disable the button altogether in this case, since we can't display the plot without downsampling.

Was disabling it while experimenting with the same case as #1520.
I think graying out the chart and showing a "too many items to plot without downsampling" message over it would be helpful because that covers charts that start out with < 200k rows but grow over the threshold. But I don't have any problem with disabling the button when we already know there are too many rows to plot without downsampling.


Zip/Git deploy should support multi-root workspaces

VSCode 1.17 introduces multi-root workspaces. However, our Zip deploy and Local Git deploy always use the "first" folder. Instead we should show a quick pick if there are multiple workspace roots

Zip deploy supports multiple workspace
https://github.com/Microsoft/vscode-azureappservice/blob/2ce5f8f0011c15657f7c68cc0dc297354e1c8b39/src/webAppZipPublisher.ts#L51
Git deploy needs to add support for multiple workspace.


New Device: WiFi Universal Door Controller

Universal door controller.
Controls motorised tilt, roller or sectional garage doors plus most doors with manual override.
I use it for a garage roller door, because a standard garage door controller only works for sectional garage doors.
Has two primary functions:

Opens or closes the door
Detects whether the door is open or closed

Has two primary components:

Main unit. Connects wirelessly to wifi network, wirelessly to magnetic open/closed sensor, and using a wire to the door control contacts.
Magnetic open/close sensor, consisting of a magnet and a wireless magnet proximity sensor.

Image1
Image2
Image3
Accessory type: Window/door controller
Have tried using homebridge-tuya device type Garage Door. Shows up in Homekit app but does not open/close the door and does not register open/close status correctly.
Schema data:
[TuyaAccessory] Sending first query to Garage door (3.3)
[TuyaAccessory] Socket had a problem and will reconnect to Garage door (ECONNRESET)
[TuyaAccessory] Sending first query to Garage door (3.3)
[[TuyaAccessory] Heard back from Garage door with command 10
[12/29/2020, 2:04:23 PM] [TuyaLan] Ready to handle Garage door (GarageDoor:3.3) with signature {"101":"fclose","102":"closed","104":100,"105":false,"110":"invalid","112":100,"113":true,"118":"invalid","120":100,"121":false,"125":"GD811"}

[TuyaAccessory] Heard back from Garage door with command 8
[TuyaAccessory] GarageDoor changed: {"101":"fclose","102":"closing","104":100,"105":false,"110":"invalid","112":100,"113":true,"118":"invalid","120":100,"121":false,"125":"GD811"}

[TuyaAccessory] Heard back from Garage door with command 8
[TuyaAccessory] GarageDoor changed: {"101":"fclose","102":"closed","104":100,"105":false,"110":"invalid","112":100,"113":true,"118":"invalid","120":100,"121":false,"125":"GD811"}

[TuyaAccessory] Sending Garage door {"1":true}

I'm not a coder, so any and all help will be appreciated.

Resolved using Kogan garage door opener implementation thanks to davidh2075#198.


[gamepad-controls] moving forwards in wrong direction

I discovered it while testing https://github.com/AdaRoseCannon/aframe-xr-boilerplate/pull/7
If I rotate the camera with right joystick, then move forwards with left joystick, it doesn't go in the correct direction.
I have only the issue in the glitch remix. I don't have the issue on my other project. Probably related to getting the camera entity.

This is an issue in some code in main.js in the aframe-xr-boilerplate glitch because when I comment the file, I don't have the issue. So this is not an issue in movement-controls. Getting the camera entity is working properly, I verified.


Impossible to transfer token MATIC from Polygon as "Insuffisiant balance"

same issue with ETH account

The first trial fails, wallet must redo if the send fails
second problem is that not all crypto is transfered


[Designer] AdaptiveCards 1.5 usage in Microsoft Teams

I urgently want to use the "style" flag "Password" introduced by AdaptiveCards 1.5 Update in Microsoft Teams.
Building my App with an AdaptiveCard Version 1.5 into the Bot Framework Emulator just displays an empty card sadly, and usage in Teams wouldn't work either so far.
Any help or information on this topic?

This issue has been copied over to Microsoft Teams repo here: https://github.com/MicrosoftDocs/msteams-docs/issues/4654


added /usr/lib64 to search paths

On some x86_64 Linux distributions the libaries are installed in /usr/lib64, e.g. Fedora. Without that notary does not work with the Yubikey on these Linux distributions. Adding that path to the search list fixes that issue and makes workrounds like copying/installing the libraries in /usr/lib or /usr/local/lib unnecessary.
Signed-off-by: Udo Seidel<EMAIL_ADDRESS>

LGTM!  Thank you for your contribution!


cast sig bug

Component
Cast
Have you ensured that all of these are up to date?

[ ] Foundry
[X] Foundryup

What version of Foundry are you on?
No response
What command(s) is the bug in?
No response
Operating System
Linux
Describe the bug
$ cast sig "aggregate((address,bytes)[])"
The application panicked (crashed).
Message:  called Result::unwrap() on an Err value: Message("Expected input args parentheses at aggregate((address,bytes)[])")
Location: cli/src/cast.rs:651

our current abi parser has some issues with tuple arrays...
but a fix for that should land shortly

Ref #1521 and #670


lib/modules: add applyExtraConfig

Adds a function to lib.nixvim.modules for applying "extraConfig" style configurations.
This allows us to be less rigid with how extraConfig is defined, without having to re-implement complex logic everywhere we use an extraConfig-style option.
Specifically, extraConfig is now allowed to be defined as:

A plain attrset, AttrSet
A 1-param function, cfg -> AttrSet
A 2-param function, cfg -> opts -> AttrSet

Where cfg and opts are the sub-section of config or options relevant to this specific context.
This flexibility allows most plugins to continue using the cfg: { } pattern, but those that do not need cfg need not specify it and those that also need opts no longer need to define it themselves via a let-in block.

@mergify queue

Good job !