FGWP102 ZW5 v3.2 - wrong measurements/reports

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?
NO, my problem is NOT within Home Assistant or the ZWave JS integration
Is your problem within ZWaveJS2MQTT?
YES, BUT a ZWaveJS2MQTT developer has told me to come here
Checklist

[X] I have checked the troubleshooting section and my problem is not described there.

[X] I have read the changelog and my problem was not mentioned there.

Describe the bug
What causes the bug?
i dont know
What do you observe?
wrong measurements

What did you expect to happen?
there is a missing V,
electric consumption is reported in Power which should be in V instead of W
more details here>
https://community.home-assistant.io/t/fgwp102-zw5-v3-2-bug-in-reports/406169
Device information
Manufacturer: fibaro
Model name:  FGWP102 ZW5 v3.2
Node ID in your network: 7
How are you using node-zwave-js?

[ ] zwavejs2mqtt Docker image (latest)
[ ] zwavejs2mqtt Docker image (dev)
[ ] zwavejs2mqtt Docker manually built (please specify branches)
[ ] ioBroker.zwave2 adapter (please specify version)
[X] HomeAssistant zwave_js integration  (please specify version)
[ ] pkg
[ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
[ ] Manually built from GitHub (please specify branch)
[ ] Other (please describe)

Which branches or versions?
version:
node-zwave-js branch:
Driver Version: 8.11.9
Server Version: 1.15.0
zwavejs2mqtt branch: Current version: 0.37.0
Did you change anything?
no
If yes, what did you change?
No response
Did this work before?
Don't know, this is a new device
If yes, where did it work?
No response
Attach Driver Logfile
dont think its required here.

This seems to be a duplicate of https://github.com/zwave-js/node-zwave-js/issues/4362 which has additional discussion.
TLDR: The device exposes the power twice, once via the Meter CC (not updated) and once via Multilevel Sensor CC (updated automatically).
FWIW, Power has the correct unit: https://en.wikipedia.org/wiki/Electric_power

The SI unit of power is the watt, one joule per second.

As for the "missing" measurements mentioned in the forum post - the device does not measure or expose those, see device manual, page 9.

@AlCalzone thanks, well just wondering why V / A are missing as cheap 20euro zwave socket do that ;-(

We have a simple work around if you use zwavejs2mqtt: use a Parse Send value: https://github.com/zwave-js/zwavejs2mqtt/issues/2626#issuecomment-1236161413. Works like charm!
Parse Send can be found at Devices values configuration. It creates a function that parses the value sent via MQTT.

Requires you to use MQTT though. The recommended connection to HA is the websocket API.


[Question] Are/will OSM containers be located on MCR?

Today the various OSM container images are available via Docker Hub (ref: https://hub.docker.com/r/openservicemesh/). I'm curious if they are also available yet via MCR. If they are, can you provide the reference to it?  If not, do you expect them to be mirrored/hosted there as well at some point in the near future?
Obviously, consumers should be importing into/sourcing from their own auth'd registry. The reason I ask is that I've now dealt with AKS customers that restrict their images to MCR and their own private ACR instances exclusively. If they are taking a dependency on a public container registry (tsk tsk), the request is that MCR is that source.  This would likely be akin to other similar addons (or near add-ons) for AKS -- such as upstream CSI Secret Store Drivers (and also the azure key vault provider).

hey @ckittel - yes great question. We do have osm images on MCR. See below:

mcr.microsoft.com/oss/openservicemesh
mcr.microsoft.com/oss/fluent

hey @ckittel - yes great question. We do have osm images on MCR. See below:

mcr.microsoft.com/oss/openservicemesh
mcr.microsoft.com/oss/fluent

Perfect, thank you.

Perfect, thank you.

@michelleN has shared the image with @ckittel, closing the issue


[bug]: Database error on login

Prerequisites

[X] I have searched for existing issues that already report this problem, without success.

EmbassyOS Version
0.3.0
Device
Laptop/Desktop
Device OS
Other
Device OS Version
n/a
Browser
Tor Browser
Browser Version
n/a
Current Behavior

Error is not helpful to user
Expected Behavior
Report that password is incorrect
Steps to Reproduce
On Embassy login page, enter a bad password
Anything else?
No response

@dr-bonez it sounds like this is a P1 since you're doing a bugfix release solely for this issue, right?

no, the issue I'm addressing is database is locked. this is different. looks like an I/O issue.

I'm getting a similar message:  "Database Error error returned from database: disk I/O error".   The only way around it is to power cycle the Embassy, but the issue shows up again after the first logout.   I was in the process of re-syncing the Bitcoin blockchain, so I'm sure there's a lot of I/O activity.  But the download didn't move at all overnight after I saw this issue, so I believe the issue may be affect all disk I/O when it gets into this state.

@ProofOfKeags   I had just done the 0.3.0 upgrade and followed the instructions on the Start9 upgrade video.  In addition to the SSD, there is the old micro sd card plugged into the micro sd card reader that came with the kit.  So my Embassy has 2 SD cards and the new 2TB SSD, all plugged in as the video suggests.  After completing the 0.3.0 upgrade, I'm not sure if that old SD card is required anymore??  Before power cycling, I unplugged the old micro SD and booted with only the new 2TB SSD.  That actually may have solved the problem.  I'm waiting to try logging in/out until the blockchain sync is complete.  Is there a reason to keep the old SD card plugged in after the upgrade is complete?

Is there a reason to keep the old SD card plugged in after the upgrade is complete?

No.

@ProofOfKeags I had just done the 0.3.0 upgrade and followed the instructions on the Start9 upgrade video. In addition to the SSD, there is the old micro sd card plugged into the micro sd card reader that came with the kit. So my Embassy has 2 SD cards and the new 2TB SSD, all plugged in as the video suggests. After completing the 0.3.0 upgrade, I'm not sure if that old SD card is required anymore?? Before power cycling, I unplugged the old micro SD and booted with only the new 2TB SSD. That actually may have solved the problem. I'm waiting to try logging in/out until the blockchain sync is complete. Is there a reason to keep the old SD card plugged in after the upgrade is complete?

Hi there, @Asaradel, I just wanted to verify that you issue was resolved?

Closing as expected fixed by upgrade to postgres


govim: move to use channel commands

We currently simulate channel commands in our callback handler in order that meaningful responses can be sent back to the plugin.
However we should really be using the native Vim channel commands because they do not trigger a redraw. Put another way, they force the caller (the plugin author) to explicitly call redraw when "done".
However, as observed in https://github.com/vim/vim/issues/4139, channel commands do appear to automatically trigger a redraw.
Depending on the outcome of that issue, we should shift to the native Vim channel commands because ideally plugin authors using channel commands should be forced to call redraw.
If we do shift back to the native channel commands, we should strongly consider simulating all of the commands via the "call" with response call, again in order that meaningful responses can be sent back to the plugin.

On hold pending the discussion in https://github.com/vim/vim/issues/4139

Per https://github.com/vim/vim/issues/4139#issuecomment-476390970 it is potentially unnecessary to move to using the official channel commands. Instead we could set lazyredraw for the duration of a "batch" window.

Relabelled this from being a bug to being a question; not clear we need to do anything here.

Closing this now. With the new event loop, I don't think this is required/desirable.


Generated code shouldn't assume Ok and Err are available

@dtolnay has previously pointed out the perils of assuming certain types are available when generating Rust code. serde and syn have their own hidden re-exports which they reference when needing types or variants from the std library.
At the moment, the generated code makes bare reference to Ok and Err if it thinks it's found a result. This should probably point to a hidden export from this crate instead. That will require moving the macro itself to a new crate that log-derive re-exports the macro from, as proc macro crates still can't export anything but proc macros.
Also, sadly using std::result::Result::Ok won't work either, as then the library no longer functions on no_std.

I think you could sidestep this by using the map and map_err methods to avoid ever referencing the variant. Something like:
quote! {
    fn temp() {
        (#closure)()
            .map(|result| { #ok_expr; result })
            .map_err(|err| { #err_expr; err })
    }
}

I think the map trick is your best bet

A quick test shows it's the exact same ASM code so I'll do that, Thanks!
https://godbolt.org/z/PDq2Bq


Add Atlantis support

Users who want to make IaC CI/CD easier and want to use Atlantis would find this addition very useful.
https://www.runatlantis.io/
https://github.com/runatlantis/atlantis

I'd be interested in this. :)

Atlantis doesn't seem to have a way for 3rd parties to integrate into it. However, if Atlantis is run via their Docker image, we can create a custom atlantis image to install infracost, then infracost can be run as a custom command, probably before apply? I guess we'd then want infracost to detect the git application being used and post a comment with the diff of master vs PR costs?
Anyone have other thoughts on this?

Since Atlantis holds the plan after comment command is run like atlantis plan it is possible to grab the plan and send it over to infracost for evaluation it will be ideal not to use a custom docker image and instead an integration is build on atlantis or better yet a plugin/integration feature could be build to integrate things like infracost.

@jamengual that's an interesting idea! If we had an HTTP API that would accept similar options as the CLI, curl can be used to send the plan JSON file and get back the response (table, json, html). Depending on how the terraform project is structured, the plan json file might have cloud creds, but those could be stripped out before being sent to the HTTP API as Infracost doesn't want/need them. How does that sound?

I find that I run a custom atlantis docker image for my deployments. We needed some external things provided on the base image for custom providers. While it's not the easiest plug & play experience to document, it wasn't too bad for me since I already took these steps.
Sample simple Dockerfile:
FROM runatlantis/atlantis

RUN \
    curl -s -L https://github.com/infracost/infracost/releases/latest/download/infracost-linux-amd64.tar.gz | tar xz -C /tmp && \
    mv /tmp/infracost-linux-amd64 /usr/local/bin/infracost

I was able to get some basics of this setup (just last night) this way. We use this terraform module for managing our Atlantis rollout - https://registry.terraform.io/modules/terraform-aws-modules/atlantis/aws/latest
Couple of steps:

I provide the INFRACOST_API_KEY in the custom_environment_variables parameter
Rather than baking in a server-side repo config for the custom workflow I put the following in the ATLANTIS_REPO_CONFIG_JSON custom_environment_variables:

locals {
  server_side_repo_config = {
    repos = [
      {
        id = "/.*/"
        workflow = "infracost"
      }
    ]
    workflows = {
      infracost = {
        plan = {
          steps = [
            "init",
            "plan",
            {run = "TERRAFORM_BINARY=/home/atlantis/.atlantis/bin/terraform$ATLANTIS_TERRAFORM_VERSION infracost --no-color --tfplan $PLANFILE 2>/dev/null"}
          ]
        }
      }
    }
  }
}
...snip...
  custom_environment_variables = [
    {
      name  = "ATLANTIS_REPO_CONFIG_JSON",
      value = jsonencode(local.server_side_repo_config)
    },
...snip...

I find that I run a custom atlantis docker image for my deployments. We needed some external things provided on the base image for custom providers. While it's not the easiest plug & play experience to document, it wasn't too bad for me since I already took these steps.
Sample simple Dockerfile:
FROM runatlantis/atlantis

RUN \
    curl -s -L https://github.com/infracost/infracost/releases/latest/download/infracost-linux-amd64.tar.gz | tar xz -C /tmp && \
    mv /tmp/infracost-linux-amd64 /usr/local/bin/infracost

I was able to get some basics of this setup (just last night) this way. We use this terraform module for managing our Atlantis rollout - https://registry.terraform.io/modules/terraform-aws-modules/atlantis/aws/latest
Couple of steps:

I provide the INFRACOST_API_KEY in the custom_environment_variables parameter
Rather than baking in a server-side repo config for the custom workflow I put the following in the ATLANTIS_REPO_CONFIG_JSON custom_environment_variables:

locals {
  server_side_repo_config = {
    repos = [
      {
        id = "/.*/"
        workflow = "infracost"
      }
    ]
    workflows = {
      infracost = {
        plan = {
          steps = [
            "init",
            "plan",
            {run = "TERRAFORM_BINARY=/home/atlantis/.atlantis/bin/terraform$ATLANTIS_TERRAFORM_VERSION infracost --no-color --tfplan $PLANFILE 2>/dev/null"}
          ]
        }
      }
    }
  }
}
...snip...
  custom_environment_variables = [
    {
      name  = "ATLANTIS_REPO_CONFIG_JSON",
      value = jsonencode(local.server_side_repo_config)
    },
...snip...

@jamengual and @mwarkentin I just released the Infracost API so curl can be used with a Terraform plan JSON: https://www.infracost.io/docs/integrations#infracost-api Please let me know if you find it useful. I'm setting up a test Atlantis deployment so I can write better docs for that integration.
@magichair that is awesome - thank you! I'll take it for a spin and include it as an option in the Atlantis integration docs.

@jamengual and @mwarkentin I just released the Infracost API so curl can be used with a Terraform plan JSON: https://www.infracost.io/docs/integrations#infracost-api Please let me know if you find it useful. I'm setting up a test Atlantis deployment so I can write better docs for that integration.
@magichair that is awesome - thank you! I'll take it for a spin and include it as an option in the Atlantis integration docs.

Awesome, @alikhajeh1 I think a bit more detail on the payload will be useful but it can be still worked out from the curl output.

Awesome, @alikhajeh1 I think a bit more detail on the payload will be useful but it can be still worked out from the curl output.

A big thank you to everyone for their feedback so far! The Infracost Atlantis integration has been released 🎉
See this pull-request for a demo, expand the Show Output sections and scroll down to see the Infracost output.
Please see this repo's README for the docs, which describe the two usage methods:

Using a custom Docker image, thanks to @magichair for sharing the script he used with us.
Sending the $PLANFILE from Atlantis to the Infracost API with curl, thanks to @jamengual for this idea.

I'm going to close this issue but feel free to add comments here or create new issues for follow-ups. This is just the start, we have plans to keep iterating on this integration; I've also joined the Atlantis Community Slack and am happy to help anyone who runs into issues.
cc @mwarkentin, @robh007, @JoshiiSinfield, @lindsaygrace, @aelbozie, @magichair, @mhmdio, @dawidmalina, @rexrafa, @jamengual


Change when we check the sampler.

Change when do we apply the sampling decision and simplify the PrioritySampler to not depend on the previous sampling decision.
This is the first part of solving the issue https://github.com/census-instrumentation/opencensus-java/issues/656

Codecov Report

Merging #657 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #657      +/-   ##
============================================
+ Coverage      76.5%   76.58%   +0.07%
- Complexity      719      722       +3
============================================
  Files           132      132
  Lines          3431     3434       +3
  Branches        325      324       -1
============================================
+ Hits           2625     2630       +5
  Misses          742      742
+ Partials         64       62       -2

Impacted Files
Coverage Δ
Complexity Δ

.../opencensus/trace/samplers/ProbabilitySampler.java
90.9% <ø> (+6.29%)
8 <0> (-1)
:arrow_down:

.../io/opencensus/implcore/trace/SpanBuilderImpl.java
87.32% <100%> (+0.96%)
20 <5> (+4)
:arrow_up:

...census/implcore/trace/export/SpanExporterImpl.java
91.66% <0%> (+1.66%)
6% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e153ff0...c52b401. Read the comment docs.

Coverage increased (+0.02%) to 78.393% when pulling c52b4017cd22f58a910aeb584404d7015e83615a on bogdandrutu:prioritysampler into e153ff07a36b684dc4638ac1c7a27bc8d88c4652 on census-instrumentation:master.

Coverage increased (+0.002%) to 78.376% when pulling 619021d1f98a978fdc3f42077211c1c11feb89ee on bogdandrutu:prioritysampler into e153ff07a36b684dc4638ac1c7a27bc8d88c4652 on census-instrumentation:master.

@adriancole they can do that by using AlwaysSample/NeverSample samplers if they have an external mechanism to do sampling.
Also I am working on some documentation about how the library does sampling.


Configure default language options and localSubPath

react-i18next:: i18n.languages were undefined or empty undefined This error might be the reason why by default the correct default locale is not picked. Well I ll be not looking much into this now.  https://github.com/isaachinman/next-i18next/issues/374

This issue is not related to the code, but it occurs due to a racing condition in react-i18next. See this.


fix(versions): update Activiti/activiti-cloud-full-chart-security versions into master

UpdateBot pushed helm dependency: activiti-cloud-full-example to: 7.1.76

UpdateBot commands:
updatebot push-version --kind helm activiti-cloud-full-example 7.1.76


Remove non-blocking SPI code

Code from the current Forward<T> implementation calls non-blocking SPI traits in embedded_hal-0.2.7, potentially returning nb::Error::WouldBlock and then getting caught in an infinite recursion.
Note: I haven't tested it extremely thoroughly but at least reading and writing seem to work. Looking at the implementation in embedded_hal-0.2.7, their transfer function essentially calls the non-blocking .send() and .read() functions until successful, accomplishing essentially what the previous version of this code was trying to do.
Fixes #27

It could be that your hal implementation never returns WouldBlock while using SPI


Prefix apollo react

Inorder the preset to work for typescript-react-apollo. However, this may not be the best way and it would be better the core visitor class can handle preset configuration so that all plugins uniformly get the same prefix. Relates to #2165

@dotansimha Wondering if you got chance to review this PR and other one #2344

@veeramarni please see my comments. Thanks!

@dotansimha Will update the PR shortly.

@dotansimha Can you please respond to my comments?

Hi @veeramarni ! Thank you for the answer. Can you please just rebase and resolve the conflicts?


Fix nested transitions

Transition will now wait for all ChildTransition components underneath to finish transitioning before removing itself. This also fixes early transitionEnd calls by cancelling transition/animation event bubbling. (e.g. if you have a button that you hover over which causes a transition event, this would be accidentally listened to.)

Should also fix #15.

Thanks for making this PR! I would like to suggest one thing though: add comments. I know that I don't add it myself (to which I'll do in the foreseeable future) but the reason I would want comments is because I would like to know how this works myself too 🤣

Added a couple comments/renamed some variables to hopefully improve the code readability.
Another transition example also sounds like a good idea-maybe might be good to create some more pages to the solid-headless website as well, or be able to view all the examples on there.

solid-headless site itself is collecting dusts. I'll be recreating it from scratch again since I found an SSR setup I liked


Update cloudwatch, dynamodb, kinesis, s3, sns, ... to 2.17.238

Updates

software.amazon.awssdk:cloudwatch
software.amazon.awssdk:dynamodb
software.amazon.awssdk:kinesis
software.amazon.awssdk:s3
software.amazon.awssdk:sns
software.amazon.awssdk:sqs
software.amazon.awssdk:sts

from 2.17.198 to 2.17.238.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "software.amazon.awssdk" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #901.


Add support for eventstream-like objects

Add support for listening to eventstream like objects. E.g. eventstreams from bacon.js or event-stream.
Under the hood we only need to check if the listenable object has a map function (which means also arrays may be listened to as well).
Motivating example
You will now be able to simply create eventstreams to be used as "automatic" actions or stores. E.g. resize event in bacon.js:
var resizeStream = $(window).asEventStream('resize');

var ResizeComponent = React.createClass({
    mixins: [Reflux.ListenerMixin],
    componentDidMount: function() {
        this.listenTo(resizeStream, this.onAppResize);
    },
    onAppResize: function() {
       // is called everytime the window resizes
    },
    render: function() { /* ... */ }
});

Thoughts?

@spoike I would love to see the rxjs example in the README. :)

Is there an example on how to do this with Bacon or RxJs with the latest reflux?

Keep an eye on the v0.3 branch. Hoping to have the alpha release finished by the end of this coming weekend.


[redgifs] Fix extractor

Description of your pull request and other information

I figured out the backend OAuth token that is used by their website. Further testing identified this as to be a long-lived and static token. Other issues I encountered were specific to my setup, and this fix should be all that is needed.
In addition, the tests were not quite working because slightly different metadata is returned now. Fixed those while I was in there.
Fixes #4805
Template

Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[X] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense

What is the purpose of your pull request?

[x] Fix or improvement to an extractor (Make sure to add/update tests)

I believe OAuth token must be acquired somehow than hardcoding it...

@Lesmiscore and @pukkandan, I believe I have addressed all review comments, including acquiring the token.

Ah, I missed one: I will make it a class var.

Okay, now I've fixed all review comments.

Pls avoid force-pushing

Sorry about that, I am used to people saying to squash all changes together. I will keep that in mind for the future.

I have resolved all comments except one that I don't understand.

Hi @pukkandan, I have resolved all the comments on this, except one of yours that I don't think is a problem. Could you review and clarify or approve?


FastCGI sent in stderr: Primary script unknown

Error description:
FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: <IP_ADDRESS>, server: , request: "HEAD / HTTP/1.1", upstream: "fastcgi://<IP_ADDRESS>:9000", host: "www.xxx.fr", referrer: "https://www.xxx.fr/
Steps to reproduce

Clone and start this repo
Start a nginx & php-fpm container
Start e second nginx & php-fpm container

Randomly I've got this error and a 404 on both websites.
Comments
My first website works with Slim Framework 3 and second with Symfony 5.1.
My nginx config:
server_tokens off;

map $http_x_request_id $request_uid {
    default $http_x_request_id;
    "" $request_id;
}

log_format docker '$remote_addr - [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time "$http_x_forwarded_for" $request_uid';

server {
    root /var/www/html/public;

    access_log /var/log/nginx/access.log docker;
    error_log /var/log/nginx/error.log error;

    add_header X-Request-Id $request_uid;

    client_max_body_size 20M;

    location / {
        try_files $uri /index.php$is_args$args;

        proxy_buffer_size 128k;
        proxy_buffers 4 256k;
        proxy_busy_buffers_size 256k;
    }

    location ~ ^/index.php(/|$) {
        fastcgi_pass php:9000;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param HTTP_X_REQUEST_ID $request_uid;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        internal;
    }

    location ~ \.php$ {
        return 404;
    }
}

If you need more information tell me.
Thanks

My bad, it's a conflict with my nginx conf and php-fpm. I used the same service name for php-fpm in my both docker-compose and nginx conf on both websites.
And when nginx tried to connect to php, he tried with php:9000 but he found two service on the same network.
So I've used an alias for my network and I've changed my nginx conf.

@babeuloula hi! maybe you could help me on this: https://github.com/evertramos/nginx-proxy-automation/issues/262

Here is a working example:
php-fpm


CraftTweaker Support Not Functioning For Animal Harvest/Pacifist

Unknown if anything beyond pacifist and animal harvest are broken, but those two are both broken.
Forge: <IP_ADDRESS>38
Mods: modlist.txt
All other useful files:
crafttweaker.log
RootsAnimalHarvest.zs
import mods.roots.AnimalHarvest;

//Waddles
AnimalHarvest.addEntity(<entity:waddles:adelie_penguin>);

RootsPacifist.zs
import mods.roots.Pacifist;

//Waddles
Pacifist.addEntity(<entity:waddles:adelie_penguin>);

Caused by #182 and a typo. Will be fixed in next release, see #182 for updates.


Error to Send Message

Please help. I was try send message but FAILED. In messages tab show RESULT_NO_DEFAULT_SMS_APP

Done. you have to set Default SIM for send sms in SIM CARD SETTING

Hello!
Thank you for reporting this issue.
I'll add an entry to the FAQ regarding this error for future reference.
May I close this issue?

Hello!
Thank you for reporting this issue. I'll add an entry to the FAQ regarding this error for future reference.
May I close this issue?

Yes Sir!


Improved AIM-54

Materials and model replaced with War Thunders models and materials. collision model was modified to fit the slightly different shape

I never really noticed than this model was on the main addon. Could it be possible for you to make this change on the missiles repository instead? I'll deal with the model on this one.

Also, just give it a different name (aim54a, for example) to still allow the old model to be used by people if they want to.

like add it to your repository?

Yeah, it makes sense that missile content remains on the missile repository.

by the looks of it, it doesn't exist in TwistedTail/ACF-Missiles

Yeah.


Upgrade to Oqtane 3.0.0 & .NET 6.0

/cc @sbwalker

PR #17 might not be needed any more

I just updated the Oqtane.Blogs version 2.0.0 coz the runtime version has been changed

@sbwalker can we merge this?

sorry for the delay

You can close #17 for now


Duplicate user error text

The following text appears when a user tries to register who is already a member of the platform

Should be something like.
A user is already registered with this email address. Please try and sign in or reset your password to access FutureNHS

MVC issue - Registration work should resolve this, and other known language string errors.

Test: @richarddabin

Closed as this was an MVC forum related problem


Modify the behavior when execution date is Sunday

If Xronor is executed at Sunday, generated result is difference from the expected one.

Codecov Report

Merging #21 into master will increase coverage by 0.3%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master      #21     +/-   ##
=========================================
+ Coverage    96.4%   96.71%   +0.3%
=========================================
  Files          31       31
  Lines         891      912     +21
=========================================
+ Hits          859      882     +23
+ Misses         32       30      -2

Impacted Files
Coverage Δ

spec/lib/xronor/dsl/schedule_converter_spec.rb
100% <100%> (ø)
:arrow_up:

lib/xronor/dsl/schedule_converter.rb
100% <100%> (+1.51%)
:arrow_up:

spec/lib/xronor/parser_spec.rb
100% <0%> (+4.54%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5a250b1...deb87a2. Read the comment docs.


fix(versions): update Activiti/example-runtime-bundle versions into master

UpdateBot pushed maven dependency: org.activiti.cloud.rb:activiti-cloud-runtime-bundle-dependencies to: 7.1.183

UpdateBot commands:
updatebot push-version --kind maven org.activiti.cloud.rb:activiti-cloud-runtime-bundle-dependencies 7.1.183


Use std::ops::Range instead of a custom type

This commit removes wasmparser::Range and instead uses
std::ops::Range<usize> instead. This is inspired by review on
bytecodealliance/wasmtime#4005 where it's more convenience to have all
the libstd methods available.

What if we just had
pub type Range = std::ops::Range<usize>;

in src/lib.rs?

I personally find typedefs like that confusing unless they're well-known which I figure this one probably won't be. I would hope that there wouldn't be too much churn for downstream consumers since this type isn't so common to work with, but are you thinking it'll have a bigger impact?

Nah it was just an idea. We can go ahead with this.


Convert Session Page to a LIveView

NOTE #126 should be merged first, as this branch is based off of that one
This PR converts a character's session page to a liveview, and pushes certain events to the Event Log as we receive them. See SacaStatsWeb.CharacterView.build_event_log_item/4 for all the events that are mapped into the Event Log.
How to Test

[ ] Start the app
[ ] Login on a character
[ ] View your character's sessions page (character/:character_name/sessions)

[ ] You should see your current session listed as the first item - click on it

[ ] Play the game and trigger an event that appears in the Event Log, (e.g. get a kill/kill assist, destroy a vehicle, capture/defend a facility, etc.)
[ ] You should see the corresponding event in the event log

To Do for 1.0.0

Update the other sections of the session page (e.g. increment kill counter(s) when getting a kill)
We might want to convert the sessions page to a LiveView at some point. This would only be useful when a user is viewing their session list, then logs on, and the new current session would appear. A LiveView just for that instance might be a bit overkill though

@dm0896665 ^ feel free to add items to this To Do that you think we should have before 1.0.0. Otherwise I think another issue for post-MVP session features would be appropriate

Would we want to add a styling pass over this before v1.0.0? There's not much we can really do (that I can think of) besides throwing the event log into a table and add weapon images though.

Yeah if you want to do a styling pass after this is merged that's good with me, though it's not a priority for me for 1.0.0 if you think it can wait

Okay, I'll wait on it.


Error: remove-statements failing for SQS

Appears to only fail when removing the last statement from an SQS resources. Presumably mirrors issue #1779 for SNS (receiving the same error). Have not checked other resources that use a variation of this action (i.e. lambda, s3, etc), but might be worth checking if others that inherit from theRemovePolicyBase class in Actions.py have the same issue.

what's the traceback? Exception?

@kapilt I get the following error:
File "/Users/hjq382/fork_custodian/cloud-custodian/.tox/py27/lib/python2.7/site-packages/c7n/resources/sqs.py", line 142, in process
    results += filter(None, [self.process_resource(client, r)])
  File "/Users/hjq382/fork_custodian/cloud-custodian/.tox/py27/lib/python2.7/site-packages/c7n/resources/sqs.py", line 163, in process_resource
    'Policy':json.dumps(p)
  File "/usr/local/lib/python2.7/site-packages/botocore/client.py", line 312, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/usr/local/lib/python2.7/site-packages/botocore/client.py", line 605, in _make_api_call
    raise error_class(parsed_response, operation_name)
ClientError: An error occurred (InvalidAttributeValue) when calling the SetQueueAttributes operation: Invalid value for the parameter Policy.

This appears to mirror the issue described by issue #1779. It only appears to fail when removing the last (or all) permission(s) from an SQS queue. I opened a PR that simply switched to remove_permission instead of set_queue that appears to work for both.

Fixed by PR #1838


Fix checking if token with large offset begins its line

Fixes #11582.
50 is pretty reasonable number, I think. For bigger offsets we just fallback to the previous behavior.

Can you add a repro test case?

Added a repro test case.

Thanks!


Dev release

Coverage decreased (-0.02%) to 49.643% when pulling e4f4f4ee53358d1b15c9416ae490f357418a1020 on tuluxmu:dev-release into ee41d4cebfcf15dee690dbe29ff1ba01a0860f64 on ringcentral:master.


Swap OpenSSL pod with OpenSSL-Universal

The OpenSSL-Universal pod is a much better choice than the current OpenSSL pod as it will allow for macOS & Bitcode support.

Well shoot. I'm already doing this. My mistake.


chore: release main

:robot: I have created a release beep boop
autonat: 1.1.2
1.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

bootstrap: 10.1.2
10.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17

circuit-relay-v2: 1.1.2
1.1.2 (2024-07-13)
Bug Fixes

expose progress events in dial/dialProtocol types (#2614) (e1f0b30)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/peer-collections bumped from ^5.2.5 to ^5.2.6
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/peer-record bumped from ^7.0.21 to ^7.0.22
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

crypto: 4.1.6
4.1.6 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1

dcutr: 1.1.2
1.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devtools-metrics: 0.2.2
0.2.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/simple-metrics bumped from ^1.1.1 to ^1.1.2

devDependencies

@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

echo: 1.1.2
1.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17

fetch: 1.1.2
1.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

floodsub: 9.1.2
9.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/pubsub bumped from ^9.0.22 to ^9.0.23

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-collections bumped from ^5.2.5 to ^5.2.6
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

identify: 2.1.2
2.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/peer-record bumped from ^7.0.21 to ^7.0.22

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

interface: 1.6.1
1.6.1 (2024-07-13)
Bug Fixes

expose progress events in dial/dialProtocol types (#2614) (e1f0b30)

Documentation

fix metrics example typo (#2613) (3805a20)

interface-compliance-tests: 5.4.9
5.4.9 (2024-07-13)
Dependencies

bump p-limit from 5.0.0 to 6.0.0 (#2609) (151bc46)
The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/multistream-select bumped from ^5.1.13 to ^5.1.14
@libp2p/peer-collections bumped from ^5.2.5 to ^5.2.6
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

interface-internal: 1.3.1
1.3.1 (2024-07-13)
Bug Fixes

expose progress events in dial/dialProtocol types (#2614) (e1f0b30)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-collections bumped from ^5.2.5 to ^5.2.6

kad-dht: 12.1.2
12.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^4.1.5 to ^4.1.6
@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/peer-collections bumped from ^5.2.5 to ^5.2.6
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1
@libp2p/peer-store bumped from ^10.1.1 to ^10.1.2

keychain: 4.1.2
4.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^4.1.5 to ^4.1.6
@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

logger: 4.0.17
4.0.17 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1

devDependencies

@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1

mdns: 10.1.2
10.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

mplex: 10.1.2
10.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17

multistream-select: 5.1.14
5.1.14 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17

peer-collections: 5.2.6
5.2.6 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

peer-id: 4.2.1
4.2.1 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1

peer-id-factory: 4.2.1
4.2.1 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^4.1.5 to ^4.1.6
@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1

peer-record: 7.0.22
7.0.22 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^4.1.5 to ^4.1.6
@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

peer-store: 10.1.2
10.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-collections bumped from ^5.2.5 to ^5.2.6
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/peer-record bumped from ^7.0.21 to ^7.0.22

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

perf: 3.1.2
3.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17

ping: 1.1.2
1.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^4.1.5 to ^4.1.6
@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

plaintext: 1.1.2
1.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

prometheus-metrics: 3.1.2
3.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

pubsub: 9.0.23
9.0.23 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^4.1.5 to ^4.1.6
@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/peer-collections bumped from ^5.2.5 to ^5.2.6
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

simple-metrics: 1.1.2
1.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/logger bumped from ^4.0.16 to ^4.0.17

tcp: 9.1.2
9.1.2 (2024-07-13)
Bug Fixes

expose progress events in dial/dialProtocol types (#2614) (e1f0b30)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17

tls: 1.1.2
1.1.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^4.1.5 to ^4.1.6
@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

upnp-nat: 1.2.2
1.2.2 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

utils: 5.4.6
5.4.6 (2024-07-13)
Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^4.1.5 to ^4.1.6
@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/logger bumped from ^4.0.16 to ^4.0.17

devDependencies

@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1

webrtc: 4.1.2
4.1.2 (2024-07-13)
Bug Fixes

expose progress events in dial/dialProtocol types (#2614) (e1f0b30)
limit default WebRTC STUN servers to 4x (#2615) (3319ff4)
remove deprecated multihashes library (#2522) (e9b6a24)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/circuit-relay-v2 bumped from ^1.1.1 to ^1.1.2
@libp2p/identify bumped from ^2.1.1 to ^2.1.2
@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1
@libp2p/websockets bumped from ^8.1.1 to ^8.1.2
libp2p bumped from ^1.8.0 to ^1.8.1

websockets: 8.1.2
8.1.2 (2024-07-13)
Bug Fixes

expose progress events in dial/dialProtocol types (#2614) (e1f0b30)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/logger bumped from ^4.0.16 to ^4.0.17

webtransport: 4.1.2
4.1.2 (2024-07-13)
Bug Fixes

expose progress events in dial/dialProtocol types (#2614) (e1f0b30)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1
@libp2p/ping bumped from ^1.1.1 to ^1.1.2
libp2p bumped from ^1.8.0 to ^1.8.1

libp2p: 1.8.1
1.8.1 (2024-07-13)
Bug Fixes

expose progress events in dial/dialProtocol types (#2614) (e1f0b30)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^4.1.5 to ^4.1.6
@libp2p/interface bumped from ^1.6.0 to ^1.6.1
@libp2p/interface-internal bumped from ^1.3.0 to ^1.3.1
@libp2p/logger bumped from ^4.0.16 to ^4.0.17
@libp2p/multistream-select bumped from ^5.1.13 to ^5.1.14
@libp2p/peer-collections bumped from ^5.2.5 to ^5.2.6
@libp2p/peer-id bumped from ^4.2.0 to ^4.2.1
@libp2p/peer-id-factory bumped from ^4.2.0 to ^4.2.1
@libp2p/peer-store bumped from ^10.1.1 to ^10.1.2
@libp2p/utils bumped from ^5.4.5 to ^5.4.6

devDependencies

@libp2p/circuit-relay-v2 bumped from ^1.1.1 to ^1.1.2
@libp2p/identify bumped from ^2.1.1 to ^2.1.2
@libp2p/interface-compliance-tests bumped from ^5.4.8 to ^5.4.9
@libp2p/mplex bumped from ^10.1.1 to ^10.1.2
@libp2p/plaintext bumped from ^1.1.1 to ^1.1.2
@libp2p/tcp bumped from ^9.1.1 to ^9.1.2
@libp2p/websockets bumped from ^8.1.1 to ^8.1.2

This PR was generated with Release Please. See documentation.

:robot: Created releases:

plaintext-v1.1.2
tls-v1.1.2
crypto-v4.1.6
interface-v1.6.1
interface-compliance-tests-v5.4.9
interface-internal-v1.3.1
kad-dht-v12.1.2
keychain-v4.1.2
libp2p-v1.8.1
logger-v4.0.17
devtools-metrics-v0.2.2
prometheus-metrics-v3.1.2
simple-metrics-v1.1.2
multistream-select-v5.1.14
peer-collections-v5.2.6
bootstrap-v10.1.2
mdns-v10.1.2
peer-id-v4.2.1
peer-id-factory-v4.2.1
peer-record-v7.0.22
peer-store-v10.1.2
autonat-v1.1.2
dcutr-v1.1.2
echo-v1.1.2
fetch-v1.1.2
identify-v2.1.2
perf-v3.1.2
ping-v1.1.2
pubsub-v9.0.23
floodsub-v9.1.2
mplex-v10.1.2
circuit-relay-v2-v1.1.2
tcp-v9.1.2
webrtc-v4.1.2
websockets-v8.1.2
webtransport-v4.1.2
upnp-nat-v1.2.2
utils-v5.4.6
:sunflower:


chore(main): release snaefell-ui 1.0.0

:robot: I have created a release beep boop
1.0.0 (2024-05-28)
Features

bridge-ui: release  (#17071) (2fa3ae0)
nfts: add initial snaefell-ui implementation (#17223) (52a6fe1)
nfts: snaefell fix to wagmi config (#17319) (104cbfa)
nfts: snaefell-ui code cleanup (#17380) (7da80c5)
nfts: snaefell-ui figma design upgrade (#17377) (53c4672)
nfts: snaefell-ui geoblock + updated list of countries (#17368) (51f90c3)
nfts: snaefell-ui mainnet integration (#17390) (ec073ac)
nfts: snaefell-ui release (#17394) (dba9c65)
nfts: snaefell-ui release texts (#17392) (582e280)
nfts: snaefell-ui sections re-org (#17365) (c7aa1bc)
snaefell-ui: ui deployment (#17227) (2a42aac)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/taikoxyz/taiko-mono/releases/tag/snaefell-ui-v1.0.0 :sunflower:


Migrate to spago@next

For this to work we are going to need a spagolock2nix function.

This is mostly ready but the CI needs fixing.
Also the command spago build protoc-plugin doesn't work, and the spago sources command doesn't work.


Import iree_amdgpu_library.cmake from users/benvanik/amdgpu

you're not building elfs, correct?

Oh I see, you're warning me about the custom_command running LLD. Hadn't seen that one. I'll need to carve out the part that I need.

yeah, that's the expensive part usually - I originally wanted to have iree_amdgpu_library + iree_amdgpu_binary that did the linking but hadn't got around to it

i could implement that suggestion, but now that would mean that the new iree_amdgpu_library would be different from the one in your branch. For now I'll just close this and instead import the correct clang bits out of this, into our existing AMDGPU-ukernels custom command currently doing clang -x hip. Later on we will properly deduplicate.


[Enhancement] upgrade staros to v3.1-rc7

upgrade staros related module to v3.1-rc7 with variant fixes, including:

storage volume compatibility fixes
shard info bugfix
ttl calculation fix

Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[X] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[X] I have checked the version labels which the pr will be auto-backported to the target branch

[X] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

@mergifyio backport branch-3.1

@Mergify backport branch-3.1

@Mergify backport branch-3.1

@Mergifyio backport branch-3.1


CDAP-10600 complete dynamic partitioner plugin

https://issues.cask.co/browse/CDAP-10600

Added support for avro output format.
Added unit tests for pipeline configuration.
Explore queries now load in UI.
Added jump links in explore window.
Writing to same partition the second time fails is a CDAP issue because it doesn't check whether a partition exists before creating a new partition. It treats all incoming partitions as new partitions. Therefore, a dynamic partitioning pipeline would fail if it attempts to write to an existing partition.

Added macro support for dataset name, schema, and base path.
Restructured code.

Can you make sure this is noted on the jira about macro parsing so we know
to clean this up when it is fixed?
On Mon, Jun 26, 2017 at 11:10 AM, caskchester<EMAIL_ADDRESS>wrote:

@caskchester commented on this pull request.
In src/main/java/co/cask/hydrator/plugin/common/MacroParser.java
https://github.com/hydrator/dynamic-partitioner/pull/1#discussion_r124079837
:

@@ -0,0 +1,218 @@
+/*

This code originally resides in app-fabric. It is better not to include
app-fabric code in a plugin.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hydrator/dynamic-partitioner/pull/1#discussion_r124079837,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AElVbX25X2f-DRQt918RzIEh9n-GdrfVks5sH_QAgaJpZM4N9CGu
.

addressed comments from @russorat and @bdmogal

Replace it with an actual example. So show the data coming into the plugin,
then show the dataset (indicating the partitions) that the sink created.
On Mon, Jun 26, 2017 at 11:54 AM, caskchester<EMAIL_ADDRESS>wrote:

@caskchester commented on this pull request.
In docs/DynamicPartitionedORCFileSet-batchsink.md
https://github.com/hydrator/dynamic-partitioner/pull/1#discussion_r124090885
:

+If it doesn't exist, it will be created.

+schema: The Avro schema of the record being written to the sink as a JSON Object.
+
+basePath: Base path for the PartitionedFileSet. Defaults to the name of the dataset.
+
+compressionCodec: Optional parameter to determine the compression codec to use on the resulting data.
+Valid values are None, Snappy, GZip, and LZO.
+
+Example
+-------
+This example will write to a PartitionedFileSet named 'users' using the original
+'create_date' of the record as the partition:
+

{

   "name": "DynamicPartitionedORCFileSet",

So do we remove the whole Example. Or should we just replace the json with
something else?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hydrator/dynamic-partitioner/pull/1#discussion_r124090885,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AElVbQIpFFX3cDNcigR3wOxidxo88Lllks5sH_6CgaJpZM4N9CGu
.

@russorat There are currently 2 somewhat minor issues related to the CDAP explore UI that I don't know how to fix.
https://issues.cask.co/browse/CDAP-12007
Updated the docs file.

@russorat
I don't know if using screenshots in the md files is a good idea. It shows up fine on github, but they don't resize properly in the cdap UI.
Renamed class and method names.
Please review

removed screenshots in the markdown files. This looks better IMO

Minor spelling mistake, otherwise LGTM

@russorat
Fixed wording in docs.


remove persistent buffers

Buffers shouldn't be persistent

True, I thought we already fixed this :)

I don't understand, the fix is literally right here https://github.com/ebetica/openfold/commit/1b5afb6b3d433ea550fa5a4900313f8a61c33298

Ok I'm so confused I think it wasn't in main, but you're not on main, but I checked the file change and it says that all the persistent=True lines are new even though they're clearly in the file...
Whatever, I'll just close this - sorry!


Enhance Attached File Display (增强附件显示)

Pull Request: Enhance Attached File Display
The new feature adds a visually enhanced display for attached files, presenting the file name within a styled circular border to improve user experience and clarity.
新功能为文件附件显示添加了视觉增强效果，文件名现在以圆形边框和按钮样式呈现，以提高用户体验和可识别性。

Overview:
This PR enhances the file attachment feature by styling the attached file name for better visibility and user experience.
Key Changes:

The attached file name is now displayed with a circular border and button-like appearance.
CSS styles include:

Rounded corners for a circular effect.
Padding for a button-like look.
Background color adjustments for improved contrast.

Impact:
This enhancement makes it clearer for users when files are attached, contributing to a more intuitive chat interface.
Testing:
The feature has been tested across various browsers to ensure consistent functionality and appearance.

Summary by CodeRabbit

新功能

更新了附件部分的图标，改为使用 PaperClipOutlined。
新增接口 AttachedFile，定义附加文件的结构，包括 uid、name 和 size 属性。
新增状态变量 attachedFiles，用于管理已附加文件的数组。
实现了文件选择处理功能，能够根据选择更新已附加文件的状态。
附件部分现在支持文件上传，并在界面上条件性显示已附加文件的名称。
在 Sender.Header 组件中新增了附件组件，支持拖放功能。

@YumoImer  I've made the updates in the current push:

Let me know if it satisfies the guidelines.
我已经进行了更新。如果符合指南要求，请告诉我。

Thank you very much! I have reviewed the preview page, and the attachment style now conforms to the RICH specification.
Regarding the attachment upload interaction, I have recorded an example from the official website Attachment - Combination which can be implemented as shown.

The final UI should look like this:

If possible, could you adjust the interaction in this PR? Thank you very much!

Thank you so much! I’ve reviewed the preview page, and it now fully aligns with the RICH design specifications! 🎉
Additionally, there are a couple of details that might need adjustment:

Add overflow: scroll; to the placeholder.
Add render control for Bubble.List:

{!!items.length && <Bubble.List items={items} roles={roles} className={styles.messages} />}

The issue caused by the first point:

The issue caused by the second point:

Once these adjustments are made, I will merge this PR.
This update means a lot to us!  You are the first overseas contributor to X!
Wishing you all the best, and this is a blessing from your friends in China!

@YumoImer I've made the adjustments you suggested. I also fixed a bug I discovered that was causing an attempt to remove an attached file to add/multiply the file instead.

Thank you for appreciating me. I've been contributing to some antd projects passively (antd mobile and antd), and I am excited to also contribute to a new project.  I truly appreciate the opportunity to collaborate with such a talented team.
Warm Regards from Zimbabwe 🇿🇼

I have reviewed the PR preview page and identified some areas for improvement, which I will address through another PR.
It has been a pleasant collaboration, and thanks again! 😄


organize all localStorage-persisted UI settings into one subtree of AppUIState

Currently, when a new setting is added to the UI, e.g., autofit, then one must remember to add the boilerplate code that saves/retrieves it from localStorage. It is easy to forget, e.g. #230, and worse yet, not fast to implement. This issue proposed making it as simple as adding an extra implements line to appropriate actions.
Since settings like this are not much data, it is not expensive to write them all at once each time any of them changes.
So, this would be simpler to organize as follows: put all such settings under a single subtree of AppUIState, called AppUIStateStorable. Not all of AppUIState would go there, e.g., strands_move, mouseover_datas, dialog, strand_creation, side_view_grid_position_mouse_cursor, and others are ephemeral and don't need to be persisted.
But many do need to be persisted, e.g., show_dna, show_modifications, loaded_filename, etc. The SelectMode and EditMode are also under here.
Then, the only boilerplate needed is to introduce a new Action interface called AppUIStateStorableAction.
Any Action changing one of these settings should implement AppUIStateStorableAction. Unlike StorableAction, there's no need to have a method storables() indicating which data to store. An AppUIStateStorableAction triggers all of AppUIStateStorable to be written into localStorage.

Should loaded_filename be included in AppUIStateStorableAction? It seems to have some special treatment in the local_storage.dart middleware as it is not an enum of Storage and seems to be tied in with dna_design. Can you explain why loaded_filename is not an enum of Storage?

I'm not sure why it's different. I think it should be treated the same as the others. It's probably just older.
I think when it's done, there will be only two things that localStorage stores: state.dna_design, and state.ui_state.storables.


:seedling: Print uncleaned appliedmanifestworks for unjoin cmd

Summary

Print uncleaned appliedmanifestworks for unjoin cmd to debug the e2e failure https://github.com/open-cluster-management-io/clusteradm/actions/runs/6438519995/job/17485094856?pr=378

the output will be like:
╰─# clusteradm unjoin --cluster-name=clusteradm-e2e-test-c1
Remove applied resources in the managed cluster clusteradm-e2e-test-c1 ...
appliedManifestWorks [3daff609dbcd11c89247c1cc38b168b09c27af2e18ddcc2a705b5f38aa6eeb8c-test 3daff609dbcd11c89247c1cc38b168b09c27af2e18ddcc2a705b5f38aa6eeb8c-test-123-e-56] still exist on the managed cluster,you should manually clean them, uninstall kluster will cause those works out of control.

fix flaky e2e test: https://github.com/open-cluster-management-io/clusteradm/actions/runs/6440424883/job/17489222068?pr=381

Related issue(s)
Fixes #

/cc @qiujian16

/approve
/lgtm


Why Not Always Expected Switching Behavior?

Hi and thanks for this project!
I added a couple of cameras to the grid. Double-clicked on one of them to expand to full screen. The camera switched to a stream of good quality. Then double-clicked again. And I noticed that the camera is still in good quality and does not return to the secondary stream even on a grid
Is it possible to get the expected behavior always: good quality of one camera if it is full screen. And the secondary (bad quality) stream for ALL cameras when they are not full screen grid?

I've done some testing with source code, and found the cause for this problem.
Every few seconds, each camera feed is tested for Width & Height Value of the video feed, vs Width & Height of the viewer/player dimensions which it is in. If the viewer height & width is larger than the video height & width, it assumes you are in full screen mode
Sometimes the feed dimensions are larger than viewer dimensions for that video even if you are not in full screen mode but matrix mode, so the feed switches to (or remains on) HQ feed.  I am investigating for possible fix while author is away. If I find a good workaround I will advise here

@fragtion
I'm not in a hurry. Let's hope the author accepts your corrections. Thanks for participating

added in 1.0.3

Greetings @grigory-lobkov
I understand you are very busy! Thanks for the new release and bugfix 👍
Please note that git repo source was not updated to reflect the changes yet, and also source zip for v1.0.3 on the Releases page seems to be the source code for v1.0.2 (no changes?). Please will you push source changes to git when you have a moment:)
Many thanks & Regards

Sorry. Updated. Should I re-release it ?
You can pull your requests - no problem)
I thought a lot about this new function, how to do it: in camera or in program options. I have no such options window for now, and there is no other options to add there.
Of cause, this option will make user to think, that's why it's better to move it somewhere. Maybe it would be better to leave it only in config file...


Model Wrapper [PostAPIModelWrapperBase] is missing the required format method[Bug]:

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

You code
How to execute
See error

Expected behavior
A clear and concise description of what you expected to happen.
Error messages
Detailed error messages.
Environment (please complete the following information):

AgentScope Version: [e.g. 0.0.2 via print(agentscope.__version__)]
Python Version: [e.g. 3.9]
OS: [e.g. macos, windows]

Additional context
Add any other context about the problem here.

Please set the model_type to post_api_chat and try again.

Okay, the previous POST API wasn't well-suited for Azure's API, but I've made the necessary adjustments myself.


[KBM] Remap logic requires unit tests

Currently KBM contains no unit tests. The first set of tests required on the hook logic should be to validate the key to key remap logic and the shortcut remap logic.

Fixed in 0.19.0, please visit https://github.com/microsoft/PowerToys/releases/ for the latest release


Experimental implementation of async hooks.

This is my first crack at implementing a solution for #243. The API is certainly up for discussion, but I designed it to be fairly unobtrusive and very straightforward.
The idea behind my approach is that each hook is considered either synchronous, or asynchronous. By default, any value implementing Hook is considered synchronous, and if it also implements AsyncHook (effectively a no-op interface), then the hook is considered asynchronous instead and its Fire() method will be run in a separate goroutine.
A new HooksDone channel is added to Entry as a notification mechanism for knowing that all hooks have finished processing. It will always provide a value, but if you only have synchronous hooks registered, or none at all, then it will provide a value almost immediately. Errors are logged directly to standard error for both synchronous and asynchronous hooks.
As an aside, my original idea was to make all hooks run asynchronously, but that broke the hook's ability to modify the entry's data, so any hook that wants to do that must remain synchronous.

I like the idea, but the implementation needs some work. In general, avoid modifying the interface of exported symbols. Also, avoid adding new exported types (I think all hooks should be async, don't need a new type).

Thanks for the feedback. I agree with most of it, though I think there is one big reason to keep some hooks synchronous: asynchronous hooks break the hook's ability to modify log entry data. Since log() returns before the asynchronous hooks run, the value is passed back to the caller before anything can be modified. It could be fixed by having it take a pointer receiver, but as the comment above the method states, doing so could introduce a race condition.

You can make your hook run async by just running it in a goroutine, so I don't quite understand the value of this, except if you have a use-case where you want to make sure all the hooks are completed at the same time (which is still possible if you own all the hooks without this PR)?

I suppose this functionality could be moved to the individual hooks, but when I looked through the ones listed on the README, none of them actually did that.
If nothing else, the documentation for hooks should call out the fact that logrus fires them synchronously, so anything posting to a remote service should execute that post in a new goroutine. Right now it seems like most users assume that hooks are asynchronous by default, which is not the case.

I agree with @dradtke on that point, I think it'd be a saner default that every hook be fired asynchronously. It's a bit off putting when you think about it that hooks be blocking events in someone's code, especially since they're configured quite far away (in main usually) from where they get triggered.

The simplest Logrus core comes from core having no assumptions about when they're run. The hooks should be implemented properly as asynchronous if that is required, instead of polluting core with that logic. I'm going to keep tracking this issue within the community, but for now it won't make it upstream.


Why lockfile is not created by default?

it is?

@kennethreitz No lockfile created after initialising project:
Creating a Pipfile for this project...
Creating a virtualenv for this project...
Running virtualenv with interpreter /tmp/workdir-0128-2240-pipenv-hash/pipenv/.venv/bin/python3
Using real prefix '/usr'
Path not in prefix '/tmp/workdir-0128-2240-pipenv-hash/pipenv/.venv/include/python3.5m' '/usr'
New python executable in /tmp/workdir-0129-0005-lockfile/.venv/bin/python3
Also creating executable in /tmp/workdir-0129-0005-lockfile/.venv/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /tmp/workdir-0129-0005-lockfile/.venv
(pipenv)vadim@vadim-K56CB /t/workdir-0129-0005-lockfile> pipenv install requests
Installing requests...
Collecting requests
  Using cached requests-2.13.0-py2.py3-none-any.whl
Installing collected packages: requests
Successfully installed requests-2.13.0

Adding requests to Pipfile's [packages]...
P.S. You have excellent taste! ✨🍰✨
(pipenv)vadim@vadim-K56CB /t/workdir-0129-0005-lockfile> ls -al
total 4
drwxrwxr-x  3 vadim vadim   80 Jan 29 00:05 .
drwxrwxrwt 47 root  root  1380 Jan 29 00:05 ..
-rw-rw-r--  1 vadim vadim   95 Jan 29 00:05 Pipfile
drwxrwxr-x  5 vadim vadim  140 Jan 29 00:05 .venv
(pipenv)vadim@vadim-K56CB /t/workdir-0129-0005-lockfile>

Is it desired behaviour? What are reasons behind that?

@vadimadr, the install command by default will only update the Pipfile and install them in your virtualenv. If you'd like to update your lock file each time you add a dependency you can use the --lock parameter to do so.

@nateprewitt I'm wondering what if anything we can do to make --lock the default behavior. According to https://github.com/kennethreitz/pipenv/issues/50#issuecomment-274637993

the only downside is that currently locking is a rather expensive (time-wise) operation.

Does this still hold true?

@jpadilla, locking is still not a fast action.
I believe the default of not locking is the correct one. If the user is playing around with adding one package at a time, we don't want to wait for a whole lock rebuild every time they add or delete a dependency. Especially since the environment is already updated for them.
When they're ready to lock it, the user can use pipenv lock, or if they know they definitely want the dependencies, they can tell pipenv to make it permanent with pipenv install <dependencies> --lock.


Cut 2.2.0-rc.0

@fabxc @Gouthamve @brian-brazil @krasi-georgiev

probbaly not important but can also add this one
https://github.com/prometheus/prometheus/pull/3821
up ==bool 1
before
up{instance="localhost:9090",job="prometheus"}
after
{instance="localhost:9090",job="prometheus"}

@krasi-georgiev added it as a [CHANGE] let me know if you think that applies.

yep , I can't think of anything else so looks good I think.

I think I applied all requested changes and changed the date to today. Let me know if there is anything else.

:+1:

👍


Remove old import

Coverage increased (+0.1%) to 86.291% when pulling 052dbc6b251fb89bea810031f8c9218284bccab8 on bcail:remove_old_import into ae460aa6bc23bb49e8b6b85e12617983a9c162f1 on dyve:develop.


cdparanoiaIII: Cleanup

Description of changes
Handle CC the normal way, unset CC was from quite old
28b6fb61e651a3e2cca57d087781e7ba6ab45e7c during early macOS experiments
and no longer needed.
Regenerate autoconf stuff unconditionally because it is so old, and
unconditional is just simpler.
Put conditional patches after unconditional ones as is more idiomatic.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Should target staging. Diff LGTM.

@ofborg build cdparanoia

The .isDarwin part of patches won't even apply anymore:
https://hydra.nixos.org/build/175468127

I'm sorry. I'll go fix that right away.

OK see https://github.com/NixOS/nixpkgs/pull/171997


support slack two-factor authentication

I'm a member of a Slack workspace requiring two-factor authentication. When I send login <team> <login> <pass> to slack, I get the reply missing_pin_sms. I do get the PIN code at the same time.

Google gives me no hits for missing_pin_sms except for this issue :(
You could try the work around here to get a token: https://twitter.com/42wim/status/1005200618808586240

I just tried again using the token to login, and it does work. It failed because I was using the same IRC user as I use for mattermost.

oh great, so we can close this :)


Model registry

Implements a proper model registry.
Solves #189

Codecov Report
Attention: Patch coverage is 99.27007% with 1 line in your changes missing coverage. Please review.

Please upload report for BASE (main@84211df). Learn more about missing BASE report.

Files with missing lines
Patch %
Lines

autoemulate/model_registry.py
96.55%
1 Missing :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #245   +/-   ##
=======================================
  Coverage        ?   94.02%
=======================================
  Files           ?       48
  Lines           ?     2796
  Branches        ?        0
=======================================
  Hits            ?     2629
  Misses          ?      167
  Partials        ?        0

Flag
Coverage Δ

94.02% <99.27%> (?)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


(Mostly) Lock-Free Buffer Manager

This PR implements a lightweight buffer manager as described in #748, with some minor modifications.
The buffer manager now handles pinning and unpinning in two separate stages. First a block is registered. This is done by calling either RegisterBlock with a block_id as parameter (pointing to a block in the base file), or by calling RegisterMemory with an allocation size. This returns a shared pointer to a BlockHandle (shared because multiple columns can point to the same block on disk). Registering a block requires a global lock, but generally happens rarely (when new memory is allocated or new data is added to a table).
After that, Pin and Unpin of a block no longer require a global lock. Instead, the block handle itself holds any state required for pinning and unpinning itself, which limits contention significantly as generally multiple connections will not be pinning the same blocks.
The LRU is replaced by a lock-free concurrent queue. When a block is unpinned and has no readers left, it is added to the eviction queue together with an eviction_timestamp. The eviction timestamp is incremented whenever this happens. Note that the same block can be present in the eviction queue multiple times. This can e.g. happen when a block is pinned, unpinned, pinned, unpinned.
To evict blocks to free up space, we pull blocks from the (lock-free) eviction queue and check their eviction timestamp. If (1) the block has no readers, and (2) the eviction timestamp has not been incremented since it has been added to the queue, we can unload the block to free up memory. This is entirely lock free as well, and if required multiple threads can evict blocks in parallel.
This has the potential side effect that slightly too much memory could be freed (e.g. when we have 16 threads, every thread besides one could be freeing a block too much). This is generally not too important though, as this would be around 256KB*n, which would be a difference of 4MB for 16 threads.
There is still one location where we require a lock, which is loading data from the base file. In the future we should move to a better way of parallel loading here, but for now our IO is sequential.

@jtommaney-alibaba

Extremely strong feature release!  Notables:

10x faster possible depending on query (best was 28x faster)
Near-perfect linear scaling for single tables
Good scaling with joins, subqueries

10x faster vs Nov 30 release at SF100 6 best scaling queries: 42 seconds to 3.88 seconds averaged.
Comparison vs prior release:

Raw timings at SF100 Nov30 vs build dev65, some regressions 12, 19 to follow up on.
dev65_speedup.xlsx
Grouped results into 4 categories:

Thanks for the benchmarks, looking quite good now :)
I believe the queries that are not showing any scaling are primarily the queries that have correlated subqueries. They use duplicate eliminated joins internally which are not (yet) parallelized, so them not scaling is not very surprising. The delim joins can actually be eliminated in all of the TPC-H queries and rewritten to SEMI/ANTI joins, but we haven't gotten to that optimization yet.
Q19 not scaling well is a bit surprising to me. That one should be rather straightforward to scale up. Perhaps something we missed there.


custom-checkbox and is-valid/is-invalid not working due to priority clashs

Version
Bootstrap 4.0.0
Problem
Using a custom checkbox and the server side validation classes is-valid/is-invalid does not work.
The CSS definitions for this behavior are:
.custom-checkbox .custom-control-input:checked ~ .custom-control-label::before {
￼    background-color: #007bff;
}
￼
.custom-control-input.is-invalid:checked ~ .custom-control-label::before {
    background-color: #e4606d;
}

The first definition provides the blue color on the normal checked checkbox.
The second definition is supposed to override the color to the invalid red.
If I count correctly, they have the same priority, so the second definition never applies.

  <input checked type="checkbox" class="custom-control-input is-invalid" id="box1">

Possible solutions

In the mixin form-validation-state specify also .custom-checkbox and others to match the full definition and make it more specific.

they have the same priority, so the second definition never applies.

If the second of two definitions has the same specificity, the second would override the first.
More importantly, you haven't provided a live example of the problem. Please comment with one and we can re-open to take another look.

Here's an example: http://jsbin.com/buseke/3/edit?html,output

@mdo this problem is still exhibited in v4.1.1: http://jsbin.com/buseke/7/edit?html,output

@mdo this problem is still exhibited in v4.1.2: http://jsbin.com/buseke/8/edit?html,output

@mdo this problem is still exhibited in v4.1.3: http://jsbin.com/buseke/10/edit?html,output

The issue is clearly reproduced and visible online. Please reopen it and review


fixed button alignment

I fixed this bug, these two buttons are aligned properly on the right side of the FOSSCU Website which can be seen in following snap.
@Mr-Sunglasses, Sir if you need any more changes please mention it.

LGTM Thx @anshika0987

Fix - #154

LGTM Thx @anshika0987

Welcome Sir @Mr-Sunglasses  😄


Add Support for Bitwise XOR opeator(^) Token in Translator Codegen Frontend #108

PR Description
This PR implements support for the Bitwise Operator (^) token in the CrossGL project, addressing issue #108  . The token is now properly translated across the DirectX, Metal, and OpenGL backends.
Related Issue
#108
shader Sample
shader XorTestShader {
    vertex {
        input vec3 position;
        output vec2 vUV;

        void main() {
            // Perform XOR on the x and y components of the position
            vUV.x = float(int(position.x) ^ 3);  // XOR with 3
            vUV.y = float(int(position.y) ^ 5);  // XOR with 5
            gl_Position = vec4(position, 1.0);
        }
    }

    fragment {
        input vec2 vUV;
        output vec4 fragColor;

        void main() {
            // Use XOR in fragment shader
            float result = float(int(vUV.x) ^ int(vUV.y));
            fragColor = vec4(result / 10.0, 1.0 - result / 10.0, 0.0, 1.0);
        }
    }
    }

Checklist

[X] Have you added the necessary tests?
[ ] Only modified the files mentioned in the related issue(s)?
[X] Are all tests passing?

For supporting bit-wise operator support maybe crosstl/src/translator/parser.py  needs to be modified

@samthakur587 @vaatsalya123 can you review and this !


clean separation between drop and entityspec

There were some places where the DnD handling code got intermingled with EntitySpec.  This PR teases those apart and makes EntitySpec a bit more extensible. In the future we'll want the support for each entity origin etc to be plugged in (or at least all clustered together in one spot) rather than sprinkled across all the code as it is now. That will make it easier to add and manage different providers. This is a first small step in that direction.

There are definite similarities. Some thoughts

This is just a first step. Eventually we'll have a plugin mechanism that allows different parsers etc to be plugged in. Even more eventually we'll have complete support for a package manager plugged in (entity spec parsing, origin management, version selection, ...). At that point the parser methods etc will be fanned out and the lookup mechanism will consult the plugin registry. With this first step, the bits of code are distinct and separate.
we do need a plug in mechanism to make this work. I've not done a lot of investigation on what's available/good. Suggestions more than welcome.
Gists are a different thing. IMO they are better as a separate concept as the APIs etc should be more tuned to how they are used.
EntitySpec is a simple data type. Previously it had various UI function (e.g., checkDroppedFiles) on it. This PR moves that into the UI code.
I agree that the UI drop code needs to be factored out and reusable. I'd like to see all of the Drop related code in PageDefinitions.js moved out into some reusable Dropzone component.


Follow Vault Validation

Validation following limited to 30 vaults
Changes 👷♀

Added Validation on API and frontend level

How to test 🧪

Insert more than 30 vaults into your db

INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2137, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2138, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2139, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2140, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2141, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2142, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2143, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2145, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2146, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2147, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2148, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2149, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2150, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2151, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2152, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2153, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2154, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2155, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2156, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2157, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2158, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2159, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2160, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2161, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2162, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2163, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2164, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2165, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2166, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2167, 'borrow'::public."vault_type", '0xasfsa', 1);
INSERT INTO public.vault
(vault_id, "type", owner_address, chain_id)
VALUES(2168, 'borrow'::public."vault_type", '0xasfsa', 1);

Follow 29 or 30 vaults

INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2138,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2139,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2140,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2141,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2142,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2143,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2144,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2145,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2146,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2147,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2148,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2149,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2150,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2151,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2152,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2153,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2154,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2155,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2156,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2157,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2158,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2159,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2160,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2161,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2162,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2163,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2164,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2165,1);
INSERT INTO public.users_who_follow_vaults (user_address,vault_id,vault_chain_id)
	VALUES ('0x497cb171ddf49af82250d7723195d7e47ca38a95',2166,1);

Try edge cases

Already following 30 vaults, when opening the tab of vault that is not followed button should be disabled with following message

Unfollow vault that is already followed (so amount of followed vaults will be 29)

Try again to follow vault that you previously tried to follow, you should succeed at following

Also when following 30 vault already, try to forge an request to follow one more vault, request should fail
example request:

curl 'http://localhost:3000/api/follow' \
  -H 'Accept: */*' \
  -H 'Accept-Language: en-US,en;q=0.9' \
  -H 'Connection: keep-alive' \
  -H 'Content-Type: application/json' \
  -H 'Cookie: __adroll_fpc=$MY_COOKIE' \
  -H 'Origin: http://localhost:3000' \
  -H 'Referer: http://localhost:3000/2137' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Site: same-origin' \
  -H 'Sec-GPC: 1' \
  -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.53 Safari/537.36' \
  -H 'authorization: Bearer $MY_TOKEN' \
  --data-raw '{"vault_id":2137,"vault_chain_id":1}' \
  --compressed

https://user-images.githubusercontent.com/6871923/214578929-a8c13b71-9e08-4845-88ee-64f3b69cd364.mp4
Example response, when already following 30 vaults should contain json with 30 vaults, but also status 422 - Unprocessable Entity:

I strongly suggest merging https://github.com/OasisDEX/oasis-borrow/pull/1924 first for two reasons.

You missed one thing from designs, blocked input when you are following to many vaults should have different background color and in PR above and rearranged a lot of styling, so it's going to be easier for you to work on that version.
There suppose to be a tooltip on short version of button, without it we don't have all cases covered.

In figma there was a specific state for this button when you reached limit, background had different color, first screenshot is from implementation, second from figma. Also, something happend with positioning of the button, it's no longer in line with header text. You've added extra div around button and it fell apart. ~Instead of Box component I suggest using Flex with alignItems set to center, that should do the trick.~ Update: in #1938 I've wrapped both follow and share button with Flex component, try merging dev to your branch first and see if it solves this issue.
In some vault headlines components doesn't fit anymore. That should be probably consulted with someone from design team how to approach it. We have too much stuff in there, but this has to be solved. It's not even a small screen view, but full width.
Tooltip on follow button on discover table is inconsistent with design. Position is different, it's size and font color. First screenshot is from implementation, second from figma. Additionally, in my opinion that tooltip should be shown only when user is hovering over button. In its current state it is visible whenever you hover over entire table cell.

Fixed the positioning of an Tooltip like this:

Regarding headline where button doesn't fit where limit is reached, can we agree that this is edge case, that could be addressed in different story, after redesigning headlines ? For vaults that have short names it meets requirements unfortunately some have longer names than that

Disabled button is STILL different color, than in figma. That should be neutral30 if I'm not mistaken.
Hover effect is still visible on disabled button. Border color change is gone, but star is still changing it's color and stroke width.
Box shadow is gone from disabled button - is that intentional? Because if disabled button is next to share button it looks out of place. Especially that this change also affected disabled button when it's is in its progress state, not only when you reached limit of vaults you can follow.
Somehow follow button in discover stopped being perfectly round, now they are roundish. I compared to staging, on staging they are fine.

https://user-images.githubusercontent.com/6871923/216061730-dba39fad-256c-49b3-b762-5811c24ebd9c.mp4

When button is disabled star is clipped

I'm ignoring button not fitting in headline as it's going to be fixed as separated story, right?
This is the third time I'm pointing out the same thing; according to the designs disabled button has different background color.  Also, when button is disabled, there shouldn't be a hover on it. Right now when i mouseover it is still highlighting.  According to figma, tootlip should be centered, but I don't know, I think I'm ready to let it slide and accept as it is, that's no big difference. But there's different weird thing about this button, tooltip is showing only when I hover over the star in it, not on the entire button.

yes PR is ready https://github.com/OasisDEX/oasis-borrow/pull/1965


Not able to control copter using setpoint_velocity/cmd_vel

Hi,
I've been trying to control quadcopter with px4 firmware with sitl, gazebo and ROS. I've successfully started simulation and established right connection with mavros. I can control quadcopter either by using pxh command line or sending poses to mavros/setpoint_position/local topic. This works fine.
However when I wanted to control quadcopter with cmd_vel types of messages, I couldn't do such a thing. For this I'm using my joystick and teleop from mavros_extras pkg. When looking at topics and messages I can see that my joystick commands transfer into cmd_vel messages which are then published to mavros/setpoint_velocity/cmd_vel topic which is fine. But then in Gazebo the model is doing nothing and I don't know where the problem is.
Here's my rosgraph:

I've also tried to set other flight modes (e.g. OFFBOARD, MANUAL etc.) but this also doesn't seem to work.
Am I missing something? Or is there some velocity control functionality at all?
Thank you for any advice.

Ok, so after some struggle I've figured it out. I didn't know I had to actually arm the vehicle using rosrun mavros mavsafety arm and operate in OFFBOARD mode. Now the teleop works fine.

@L4ncelot did this work on actual quadcopter?

@vinhk I haven't tested this on actual copter. I just wanted it to work in simulation. But I think it should work on actual one as well since it's just velocity_cmd publisher and nothing else.


taping on notification & closed app

i have two issues here
when i tap on the notification doesn't open the app and show the notification
and i can't receive the notification while the app is closed
any help on that matter ?

any help on that matter ?