Problem with WH31 sensor

name: WH31 sensors fail to configure
about: Please add WH31 support
title: 'WH31 support'
labels: bug
assignees: ''

Describe The Bug:
WH31 sensors fail to properly initialize
To Reproduce:
connect plugin to gateway featuring a WH31 sensor
Expected behavior:
Should work... @conquistadore/homebridge-ecowitt does work with this sensor
Logs:
her-sensors/src/EcowittPlatform.ts:134:12
    at Layer.handle [as handle_request] (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/layer.js:95:5)
    at next (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/route.js:149:13)
    at Route.dispatch (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/route.js:119:3)
    at Layer.handle [as handle_request] (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/layer.js:95:5)
    at /usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/index.js:284:15
    at Function.process_params (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/index.js:346:12)
    at next (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/index.js:280:10)
    at /usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/body-parser/lib/read.js:137:5
    at AsyncResource.runInAsyncScope (node:async_hooks:206:9)
    at invokeCallback (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/raw-body/index.js:238:16)
    at done (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/raw-body/index.js:227:7)
    at IncomingMessage.onEnd (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/raw-body/index.js:287:7)
[13/09/2024, 16:40:46] [Ecowitt] An issue occured while updating sensor values for WH31. Review the error message below and file a bug report if needed at https://bit.ly/3yklrWZ
 Error: Update on 974B:WH31CH1 requires data batt1,temp1f,humidity1
    at WH31.update (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/src/devices/WH31.ts:54:13)
    at EcowittPlatform.updateAccessories (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/src/EcowittPlatform.ts:639:28)
    at EcowittPlatform.onDataReport (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/src/EcowittPlatform.ts:267:10)
    at /usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/src/EcowittPlatform.ts:134:12
    at Layer.handle [as handle_request] (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/layer.js:95:5)
    at next (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/route.js:149:13)
    at Route.dispatch (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/route.js:119:3)
    at Layer.handle [as handle_request] (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/layer.js:95:5)
    at /usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/index.js:284:15
    at Function.process_params (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/index.js:346:12)
    at next (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/express/lib/router/index.js:280:10)
    at /usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/body-parser/lib/read.js:137:5
    at AsyncResource.runInAsyncScope (node:async_hooks:206:9)
    at invokeCallback (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/raw-body/index.js:238:16)
    at done (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/raw-body/index.js:227:7)
    at IncomingMessage.onEnd (/usr/local/lib/node_modules/homebridge-ecowitt-weather-sensors/node_modules/raw-body/index.js:287:7)

Data Report:
StationInfo: {
  "model": "GW1100B",
  "deviceName": "GW1100",
  "serialNumber": "C4:5B:BE:6D:97:4B",
  "shortSerial": "974B",
  "hardwareRevision": "GW1100B_V2.3.4",
  "softwareRevision": "",
  "firmwareRevision": "V2.3.4",
  "frequency": "915M",
  "PASSKEY": "19C7B89C12D820C983DDA1A38B73CADE",
  "sensors": [
    {
      "type": "GW1100"
    },
    {
      "type": "WH31",
      "channel": 1
    },
    {
      "type": "WH31",
      "channel": 2
    }
  ]
}

 {
  "PASSKEY": "19C7B89C12D820C983DDA1A38B73CADE",
  "stationtype": "GW1100B_V2.3.4",
  "runtime": "5524430",
  "heap": "25748",
  "dateutc": "2024-09-13 23:47:04",
  "tempinf": "77.90",
  "humidityin": "40",
  "baromrelin": "29.577",
  "baromabsin": "29.577",
  "temp1f": "37.58",
  "temp2f": "-2.56",
  "batt1": "0",
  "batt2": "0",
  "freq": "915M",
  "model": "GW1100B",
  "interval": "20"
}

Plugin Config:
{
    "baseStation": {
        "mac": "C4:5B:BE:6D:97:4B",
        "port": 8889,
        "path": "/data/report"
    },
    "additional": {
        "staticNames": "false",
        "validateMac": "true",
        "luxFactor": 126.7,
        "acceptAnyPath": "false",
        "validateTimestamp": "true",
        "removeStaleDevices": "true"
    },
    "units": {
        "wind": "mph",
        "rain": "in",
        "distance": "mi",
        "temperature": "fh"
    },
    "platform": "Ecowitt"
}

Screenshots:
Environment:

Plugin Version: 2.2.0-beta
Homebridge Version: 1.8.4
Node.js Version: v20.17.0
NPM Version: 10.8.2
Operating System: Linux homebridge 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux on Raspberry Pi 4

Hi @LordJohnWhorfin.  Thanks so much for trying this plugin out.
For WH31, the plugin is expecting 3 properties from the data report - tempXf, humidityX, and battX.   It looks like your data report only includes tempXf, and battX.  Do you happen to know why the data report with the WH31 data is not sending humidity?  Is it possible that your gateway is configured to not send humidity data, or maybe older WH31s didn't report humidity?  Let me know - really would like to understand it better.
It does look like I have one other sample data report that doesn't include humidity data for a WH31, so I'm thinking it would be reasonable to make the humidity data as optional.

Hi, actually it looks quite confusing. I ordered two WN30BL outdoors probe thermometers from Amazon but the devices I received are marked WN37B and report as a WH31 without humidity readings… This is weird. Let me know if you want more data logs.EricOn Sep 13, 2024, at 7:10 PM, Ryler Hockenbury @.***> wrote:
Hi @LordJohnWhorfin.  Thanks so much for trying this plugin out.
For WH31, the plugin is expecting 3 properties from the data report - tempXf, humidityX, and battX.   It looks like your data report only includes tempXf, and battX.  Do you happen to know why the data report with the WH31 data is not sending humidity?  Is it possible that your gateway is configured to not send humidity data, or maybe older WH31s didn't report humidity?  Let me know - really would like to understand it better.
It does look like I have one other sample data report that doesn't include humidity data for a WH31, so I'm thinking it would be reasonable to make the humidity data as optional.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Ahh, that's super helpful. Thanks.  In that case, what I think I'll do is map it to the WN30 so they'll show up for you as WN30 sensors, rather than WH31 without humidity.  I should have the changes out within the next day or two.

Sweet! Thanks! I’ll test it right away :-)On Sep 14, 2024, at 5:26 AM, Ryler Hockenbury @.***> wrote:
Ahh, that's super helpful. Thanks.  In that case, what I think I'll do is map it to the WN30 so they'll show up for you as WN30 sensors, rather than WH31 without humidity.  I should have the changes out within the next day or two.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Hi @LordJohnWhorfin - Can you please give the v2.3.0-beta build a try?  That should properly handle mapping your sensors to WN30.  Please let me know if you hit any issues.


[help]: CMSIS SVD file wanted

Help
Hello,
I am looking to write Rust libraries providing a hardware abstraction layer and a peripheral access API for this system. If anyone could provide an SVD file for the K510, that would make the process much easier.

已转达内部，请稍后


No paths found for /pets/dog.us

Hello, I am facing a new issue with the url validation.
My url is something like this: http://localhost/pets/dog.us?type=2&age=1
My swagger is something like this:
basePath: /localhost
paths:
  /pets/dog.us?type=2&age=1
    get:
      summary: Get dogs of type 2 and age 1
      responses:
        200:
          schema:
            $ref: Type2Age1

I am getting this error:
libs.flex.exceptions.ValidationError: 'request':
    - 'path':
        - 'No paths found for /pets/dog.us'

I took a look to paths :
{'/pets/dog.us?type=2&age=1': re.compile('^/pets/dog\\.us?type=2&age=1$')}

And the matching_api_paths:
[]

What do you think about the problem? Am I defining the path in 'swagger' wrongly? or do you think that is a flex issue?

I don't think that your swagger schema is valid
basePath: /localhost
paths:
  /pets/dog.us?type=2&age=1
    get:
      summary: Get dogs of type 2 and age 1
      responses:
        200:
          schema:
            $ref: Type2Age1

Specifically the path.  I think you would have to define the query parameters as follows.
basePath: /localhost
paths:
  /pets/dog.us
    get:
        parameters:
            - name: type
              in: "query"
              type: integer
            - name: age
              in: "query"
              type: integer
      summary: Get dogs of type 2 and age 1
      responses:
        200:
          schema:
            $ref: Type2Age1

Seeing as swagger defines a way to specify query parameters it seems odd to include them in the actual path string.  That said, I don't see any place where swagger explicitly forbids including them in the path string so I am open to a pull request that expands how the path regex is generated to correctly  match paths like this, though I'm not sure it's the appropriate thing to do...
Thoughts?

You are totally right, I should use the query parameters. My problem is because the '/pets/dog.us?type=2&age=1' and '/pets/dog.us?type=3&age=1' return a total structure, so I wanted to put the paths in the path string. But I think that I should change my software and use the query parameters.


Fix Streaming for 5.3

Changes in 5.3 caused streaming PCM to fail occasionally. Check directly against endpoint to confirm binary data

LGTM


Updating info on supported genotypers

This is updated to match Supp Table 1.
Note, there is a link to contributing on the bottom that doesn't seem to get parsed correctly. I'm not sure about this syntax so hope one of you can look at that.

Codecov Report

Merging #96 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop      #96   +/-   ##
========================================
  Coverage    96.98%   96.98%
========================================
  Files           17       17
  Lines         2186     2186
========================================
  Hits          2120     2120
  Misses          66       66

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 e57b08b...0045028. Read the comment docs.

Some questions:
You say "designed to be run genome-wide". Is this not true of any of these? What does it mean for this not to be true?
PopSTR seems like it doesn't even use a reference except for super long repeats (based on my cursory reading of their docs). Why doesn't it get a * also?
What does "genic hg19" mean?

I added back a bunch of (now edited) text to the use cases column. I do think this is important to have, since the main point of having this page is giving people that don't know a sense of what these tools were designed to do.
I do like having the info from before in separate columns. Thanks for adding. I don't know if you have a trick for dealing with RST tables. But it is not one of my favorite activities...
Not all of these are designed to run genome-wide. (although all could be). AdVNTR is currently too slow to reasonable run genome-wide (I forgot the run time, but it's in the hundreds of hours I think even for only things inside of genes ("genic").
ExpansionHunter was designed for targeted genotyping of expansions. If you have a complex locus with many interruptions, there is currently no tool to automate inferring the correct regular expression to use. SO in that sense that part is not (yet) automated to run genome-wide.
PopSTR has "markerInfo" files with the info for each genome-wide TR. But they don't give instructions for how to make a different one if you want to. (e.g. like, I don't see a specification of the format of that file).
But to give all the tools the benefit of the doubt, I've changed the asterisk thing and instead just note at the bottom that all could theroetically be run on any panel.
AdVNTR usually infers length. It can be used to infer frameshifts mutations. So that's not quite inferring sequence so I don't think it should get that label.
For EH, while complex TR sequences can be specified, as far as I can tell it only outputs lengths, which is why I put "length" there.
All of this info is hard to boil down in table form. But I think the columns you added as well as the use cases column gives some idea of intended uses of the different tools.
If it looks ok with you feel free to merge. Once we're happy and merged I'll update the supp text.
(Also sorry some of the commit messages are just "Update CALLERS.rst". Generally I like more informative messages. When editing on the web browser I clicked too fast through the commit button).

Hopefully this is the last round of changes. Just some minor stuff. If you like it, merge it.
Split the table in two for visual clarity.
Only differentiate between STRs and VNTRs where necessary, otherwise just change to TRs.
Say tools apply to all TRs despite the name.


Error: error deleting S3 bucket versioning (bucker-name): InvalidBucketState

When I run terraform destroy, I get this error
Error: error deleting S3 bucket versioning (bucket-name): InvalidBucketState: A replication configuration is present on this bucket, so you cannot change the versioning state. To change the versioning state, first delete the replication configuration.
│   status code: 409
however, when I run terraform destroy after 15 mins, the resources gets destroyed.
I couldn't get this resolved, any help?
Thanks..

@RahilRehan
Thank you for reporting the issue!
I found that the bucket versioning can't be turned off when you have the replication configuration on the same bucket(AWS doc).

however, when I run terraform destroy after 15 mins, the resources gets destroyed.

It fails when aws_s3_bucket_versioning deletion ran before aws_s3_bucket_replication_configuration.
Since terraform run resource deletions in parallel by default, the above case randomly occurrs.
I fixed this issue by making the bucket relication configuration dependent to the versioning configuration. Could you try v1.0.1?

Thanks so much @nozaq , this worked!


pkgs/top-level/release-cross.nix: add Hydra jobs for pkgsCross.platform.nixStatic

Description of changes
This commit causes Hydra to build nixStatic on non-NixOS platforms for which nixStatic is known to build correctly.
Providing Hydra builds of nixStatic on these platforms allows users to bootstrap their local nixpkgs system without either having to:
a. Trust binaries that came from a source other than Hydra or
b. Fight with their host distribution to satisfy all of nix's large    set of build dependencies (this is not easy!)
Currently there are two platforms in this set: mips64el-linux-gnuabi64 and powerpc64le-linux-gnu.
Things done

Built on platform(s)

[x] x86_64-linux (=buildPlatform)

[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

If appropriate, I can add myself as maintainer for these new expressions.  I assume that means I'll get an email if the Hydra builds fail.  I would like that.
I tried doing that in the initial PR but the organization of release-cross.nix makes it really awkward to patch in new meta fields.  It more than doubled the number of lines of code touched.

Resolved merge conflict.

The builds were successful!

nix-static-mips64el-unknown-linux-muslabi64-2.12.0
nix-static-powerpc64le-unknown-linux-musl-2.12.0

Thanks for following up with a fix and reporting back here! Great that it works.


Release Google.Cloud.Dialogflow.V2 version 3.0.0

Changes in this release:
Documentation changes only since 3.0.0-beta02:

Commit 4181b4f: docs: Comment updates only
Commit 947a573: docs: Regenerate all clients with more explicit documentation
Commit b3e7794: docs: minor comments change.

As noted in the 3.0.0-beta01 history, 3.0.0 is a breaking change compared with 2.0.0 due to resource names being corrected.

Created release for Google.Cloud.Dialogflow.V2-3.0.0


updated all radiokot bugs/improvements.

Changes
Updated all radiokot bugs/improvements.
Checklist

[x] My code follows the style of this project.
[x] The code compiles without warnings.
[x] I have performed a self-review of the changes.
[x] I have documented my code, in particular the intent of the
hard-to-understand areas.
[x] (If necessary) I have updated the CHANGELOG.

CLA acceptance
_Remove if not applicable.
By submitting the contribution I accept the terms and conditions of the
Contributor License Agreement v1.0

link: https://developers.concordium.com/CLAs/Contributor-License-Agreement-v1.0.pdf

[x] I accept the above linked CLA.

If I shield an amount, wait for it to finalize, and then navigate to the default account view (on the fungible tab), then the amount shown in the Fungible tab is not the same as balance total at the top. It does not subtract the amount I just shielded even if I navigate to some of the other screens. If I navigate to Collectibles and then back to Fungible, then it updates it correctly.


Support TryFromBytes - conditional conversion analogous to FromBytes

Co-authored with @jswrenn.
Overview
Add a TryFromBytes trait, which supports byte-to-type conversions for non-FromBytes types by performing runtime validation. Add a custom derive which generates this validation code automatically.
Many thanks to @kupiakos and @djkoloski for providing invaluable feedback and input on this design.
Progress

[x] Add TryFromBytes trait definition

https://github.com/google/zerocopy/pull/641

[x] Implement TryFromBytes for existing FromBytes types

https://github.com/google/zerocopy/pull/644

[x] Add try_from_ref method; impl for bool

https://github.com/google/zerocopy/pull/647

[x] Implement derive for structs

https://github.com/google/zerocopy/pull/665

[x] Implement for slices

https://github.com/google/zerocopy/pull/666

[x] Implement for arrays

https://github.com/google/zerocopy/pull/799

[x] Allow deriving on repr(packed) structs

https://github.com/google/zerocopy/pull/794

[x] Allow deriving on unions

See for context: https://github.com/google/zerocopy/discussions/696
https://github.com/google/zerocopy/pull/800

[x] Allow deriving on field-less enums with primitive reprs (u8, i16, etc)

https://github.com/google/zerocopy/pull/803

[x] Allow deriving on field-less enums with repr(C) by treating the discriminant type as [u8; size_of::<Self>()]

https://github.com/google/zerocopy/pull/806

[x] https://github.com/google/zerocopy/issues/873
[ ] https://github.com/google/zerocopy/issues/874
[x] Implement TryFromBytes for fn() and extern "C" fn() types

#904

[x] Implement TryFromBytes for UnsafeCell<T>

#905

[x] Make TryFromBytes a super-trait of FromZeros

#962

[x] Remove #[doc(hidden)] from all items which are intended to be public

https://github.com/google/zerocopy/pull/976

[x] Add to TryFromBytes docs to explain that you can't always round trip T -> [u8] -> T (notably for pointer types), which could be confusing given that, for TryFromBytes, the failure would show up at runtime

#860

Non-breaking additions

[x] Add try_from_mut and try_read_from methods

https://github.com/google/zerocopy/pull/892
https://github.com/google/zerocopy/pull/808

[ ] Allow deriving on data-full enums

https://github.com/google/zerocopy/pull/879

[ ] Implement for unsized UnsafeCell

Consider that we may not need to require T: Sized (described in #251) if we use the design in #905

[x] Remove Self: NoCell bound from try_read_from

https://github.com/google/zerocopy/pull/970

[ ] Support deriving on unions without NoCell bound

Motivation
Many use cases involve types whose layout is well-defined, but which cannot implement FromBytes because there exist bit patterns which are invalid (either they are unsound in terms of language semantics or they are unsafe in the sense of violating a library invariant).
Consider, for example, parsing an RPC message format. It would be desirable for performance reasons to be able to read a message into local memory, validate its structure, and if validation succeeds, treat that memory as containing a parsed message rather than needing to copy the message in order to transform it into a native Rust representation.
Here's a simple, hypothetical example of an RPC to request log messages from a process:
/// The arguments to the `RequestLogs` RPC (auto-generated by the RPC compiler).
#[repr(C)]
struct RequestLogsArgs {
    max_logs: u64,
    since: LogTime,
    level: LogLevel,
}

/// Log time, measured as time on the process's monotonic clock.
#[repr(C)]
struct LogTime {
    secs: u64,
    // Invariant: In the range [0, 10^9)
    nsecs: u32,
}

/// Level of log messages requested from `RequestLogs`.
#[repr(u8)]
enum LogLevel {
    Trace,
    Debug,
    Info,
    Warn,
    Error,
}

None of these types can be FromBytes. For LogLevel, only the u8 values 0 through 4 correspond to enum variants, and constructing a LogLevel from any other u8 would be unsound. For LogTime, any sequence of the appropriate number of bytes would constitute a valid instance of LogTime from Rust's perspective - it would not cause unsoundness - but some such sequences would violate the invariant that the nsecs field is in the range [0, 10^9).
While these types can't be FromBytes, we'd still like to be able to conditionally reinterpret a sequence of bytes as a RequestLogsArgs - it's just that we need to perform runtime validation first. Ideally, we'd be able to write code like:
/// The arguments to the `RequestLogs` RPC (auto-generated by the RPC compiler).
#[derive(TryFromBytes)]
#[repr(C)]
struct RequestLogsArgs {
    max_stats: u64,
    since: LogTime,
    level: LogLevel,
}

/// Log time, measured as time on the process's monotonic clock.
#[derive(TryFromBytes)]
#[TryFromBytes(validator = "is_valid")]
#[repr(C)]
struct LogTime {
    secs: u64,
    // Invariant: In the range [0, 10^9)
    nsecs: u32,
}

impl LogTime {
    fn is_valid(&self) -> bool {
        self.nsecs < 1_000_000_000
    }
}

/// Level of log messages requested from `RequestLogs`.
#[derive(TryFromBytes)]
#[repr(u8)]
enum LogLevel {
    Trace,
    Debug,
    Info,
    Warn,
    Error,
}

The TryFromBytes trait - the subject of this design - provides the ability to fallibly convert a byte sequence to a type, performing validation at runtime. At a minimum, the validation code simply ensures soundness - for example, in the case of LogLevel, validating that byte values are in the range [0, 4]. The custom derive also supports user-defined validation like the LogTime::is_valid method (note the validator annotation on LogTime), which can be used to enforce safety invariants that go above and beyond soundness.
Given these derives of TryFromBytes, an implementation of this RPC could be as simple as:
fn serve_request_logs_rpc<F: FnMut(&RequestLogsArgs)>(server: &mut RpcServer, f: F) -> Result<()> {
    loop {
        let bytes = [0u8; mem::size_of::<RequestLogsArgs>()];
        server.read_request(&mut bytes[..])?;
        let args = RequestLogsArgs::try_from_bytes(&bytes[..]).ok_or(ParseError)?;
        f(args);
    }
}

The design proposed in this issue implements this API.
Design
TODO
This design builds on the following features:

https://github.com/google/zerocopy/issues/29
https://github.com/google/zerocopy/issues/196

/// A value which might or might not constitute a valid instance of `T`.
// Builds on the custom MaybeUninit type described in #29
pub struct MaybeValid<T: AsMaybeUninit + ?Sized>(MaybeUninit<T>);

// Allows us to use the `project!` macro for field projection (proposed in #196)
unsafe impl<T, F> Projectable<F, AlignedByteArray<F>> for AlignedByteArray<T> {
    type Inner = T;
}

impl<T> MaybeValid<T> {
    /// Converts this `MaybeValid<T>` to a `T`.
    ///
    /// # Safety
    ///
    /// `self` must contain a valid `T`.
    pub const unsafe fn assume_valid(self) -> T { ... }

    /// Converts this `&MaybeValid<T>` to a `&T`.
    ///
    /// # Safety
    ///
    /// `self` must contain a valid `T`.
    pub const unsafe fn assume_valid_ref(&self) -> &T { ... }

    /// Converts this `&mut MaybeValid<T>` to a `&mut T`.
    ///
    /// # Safety
    ///
    /// `self` must contain a valid `T`.
    pub unsafe fn assume_valid_mut(&mut self) -> &mut T { ... }
}

/// # Safety
///
/// `is_bit_valid` is correct. If not, can cause UB.
pub unsafe trait TryFromBytes {
    fn is_bit_valid(bytes: &MaybeValid<Self>) -> bool;

    fn try_from_ref(bytes: &[u8]) -> Option<&Self> {
        let maybe_valid = Ref::<_, MaybeValid<T>>::new(bytes)?.into_ref();
        if Self::is_bit_valid(maybe_valid) {
            // SAFETY: `is_bit_valid` promises that it only returns true if
            // its argument contains a valid `T`. This is exactly the safety
            // precondition of `MaybeValid::assume_valid_ref`.
            Some(unsafe { maybe_valid.assume_valid_ref() })
        } else {
            None
        }
    }

    fn try_from_mut(bytes: &mut [u8]) -> Option<&mut Self>
    where
        Self: AsBytes + Sized,
    {
        let maybe_valid = Ref::<_, MaybeValid<T>>::new(bytes)?.into_mut();
        if Self::is_bit_valid(maybe_valid) {
            // SAFETY: `is_bit_valid` promises that it only returns true if
            // its argument contains a valid `T`. This is exactly the safety
            // precondition of `MaybeValid::assume_valid_ref`.
            Some(unsafe { maybe_valid.assume_valid_ref() })
        } else {
            None
        }
    }

    fn try_read_from(bytes: &[u8]) -> Option<Self>
    where
        Self: Sized
    {
        let maybe_valid = <MaybeValid<T> as FromBytes>::read_from(bytes)?;
        if Self::is_bit_valid(&maybe_valid) {
            // SAFETY: `is_bit_valid` promises that it only returns true if
            // its argument contains a valid `T`. This is exactly the safety
            // precondition of `MaybeValid::assume_valid`.
            Some(unsafe { maybe_valid.assume_valid() })
        } else {
            None
        }
    }
}

Here's an example usage:
/// A type without any safety invariants.
#[derive(TryFromBytes)]
#[repr(C)]
struct MySimpleType {
    b: bool,
}

// Code emitted by `derive(TryFromBytes)`
unsafe impl TryFromBytes for MySimpleType {
    fn is_bit_valid(bytes: &MaybeValid<Self>) -> bool {
        // `project!` is described in #196
        let b: &MaybeValid<bool> = project!(&bytes.b);
        TryFromBytes::is_bit_valid(b)
    }
}

/// A type with invariants encoded using `validate`.
#[derive(TryFromBytes)]
#[TryFromBytes(validator = "validate")]
#[repr(C)]
struct MyComplexType {
    b: bool,
}

// Code emitted by `derive(TryFromBytes)`
unsafe impl TryFromBytes for MyComplexType {
    fn is_bit_valid(bytes: &AlignedByteArray<Self>) -> bool {
        // `project!` is described in #196
        let b: &MaybeValid<bool> = project!(&bytes.b);
        if !TryFromBytes::is_bit_valid(b) { return false; }
        // If there's no interior mutability, then we know this is sound because of preceding
        // validation. TODO: What to do about interior mutability?
        let slf: &MyComplexType = ...;
        MyComplexType::validate(slf)
    }
}

impl MyComplexType {
    fn validate(slf: &MyComplexType) -> bool { ... }
}

Unions
See for a discussion of how to support unions in TryFromBytes: https://github.com/google/zerocopy/discussions/696
Relationship with other traits
There are obvious relationships between TryFromBytes and the existing FromZeroes and FromBytes traits:

If a type is FromZeroes, then it should probably be TryFromBytes (at a minimum, we must know something about the type's layout and bit validity to determine that it is genuinely FromZeroes)

This implies that we should change FromZeroes to be FromZeroes: TryFromBytes

If a type is FromBytes, then it is trivially TryFromBytes (where is_bit_valid unconditionally returns true)

This implies that we should provide a blanket impl impl<T: FromBytes> TryFromBytes for T

Unfortunately, neither of these are possible today.
FromZeroes: TryFromBytes
The reason this bound doesn't work has to do with unsized types. As described in the previous section, working with unsized types is difficult. Luckily for FromZeroes, it doesn't have to do anything with the types it's implemented for - it's just a marker trait. It can happily represent a claim about the bit validity of a type even if that type isn't constructible in practice (over time, FromZeroes will become more useful as more unsized types become constructible). By contrast, TryFromBytes is only useful if we can emit validation code (namely, is_bit_valid). For that reason, we require that TryFromBytes: AsMaybeUninit since that bound is required in order to support the MaybeValid type required by is_bit_valid.
This means that we have two options if we want FromZeroes: TryFromBytes:

We can keep TryFromBytes: AsMaybeUninit. As a result, some types which are FromZeroes today can no longer be FromZeroes, and some blanket impls of FromZeroes would require more complex bounds (e.g., today we write impl<T: FromZeroes> FromZeroes for Wrapping<T>; under this system, we'd need to write impl<T: FromZeroes> FromZeroes for Wrapping<T> where <T as AsMaybeUninit>::MaybeUninit: Sized, or alternatively we'd need to write one impl for T and a different one for [T]).
We could move the AsMaybeUninit bound out of definition of TryFromBytes and into is_bit_valid (and callers). As a result, we can keep existing impls of FromZeroes, but now T: TryFromBytes is essentially useless - to do anything useful, you need to specify T: TryFromBytes + AsMaybeUninit.

Neither option seems preferable to just omitting FromZeroes: TryFromBytes. Callers who require both can simply write T: FromZeroes + TryFromBytes.
(Note that the same points apply if we consider FromBytes: TryFromBytes)
impl<T: FromBytes> TryFromBytes for T
This conflicts with other blanket impls which we need for completeness:

impl<T: TryFromBytes> TryFromBytes for [T]
impl<const N: usize, T: TryFromBytes> TryFromBytes for [T; N]

As a result, we have to leave TryFromBytes and FromBytes as orthogonal. We may want to make it so that derive(FromBytes) automatically emits an impl of TryFromBytes, although in the general case that may require custom DST support.
Open questions

Is there any way to recover the blanket impl of TryFromBytes for T: FromBytes? Unlike FromZeroes: TryFromBytes, where you may need to perform runtime validation, if you know that T: FromBytes, then in principle you know that is_bit_valid can unconditionally return true without inspecting its argument, and so in principle it shouldn't matter whether you can construct a MaybeValid<Self>. Is there some way that we could allow FromBytes types to specify <Self as AsMaybeUninit>::MaybeUninit = () or similar in order to bypass the "only sized types or slices can implement AsMaybeUninit" problem?

One approach is to wait until a KnownLayout trait lands. There's a good chance that, under that design, we'd end up with FromZeroes: KnownLayout. If KnownLayout: AsMaybeUninit (or just absorbs the current definition of AsMaybeUninit into itself), it'd solve this problem since all zerocopy traits would imply support for MaybeValid.

In the first version of this feature, could we relax the Self: Sized bounds on try_from_ref and try_from_mut (without needing full custom-DST support)?
Should derive(FromBytes) emit an impl of TryFromBytes? What about custom DSTs?
What should the behavior for unions be? Should it validate that at least one variant is valid, or that all variants are valid? (This hinges somewhat on the outcome of rust-lang/unsafe-code-guidelines#438.)
What bounds should we place on T when implementing TryFromBytes for Unalign<T> (#320)?

Future directions

In this design, we ban interior mutability entirely. For references, this is unavoidable - e.g., if we were to allow types containing UnsafeCell in try_from_ref, then the user could obtain an &UnsafeCell and a &[u8] view of the same memory, which is unsound (it's unsound to even exist under Stacked Borrows, and unsound to expose to safe code in all cases). For values (i.e., try_read_from), we'd like to be able to support this - as long as we have some way of performing validation, it should be fine to return an UnsafeCell by value even if its bytes were copied from a &[u8]. Actually supporting this in practice is complicated for a number of reasons, but perhaps a future extension could support it. Reasons it's complicated:

is_bit_valid operates on a NonNull<Self>, so interior mutability isn't inherently a problem. However, it needs to be able to call a user's custom validator, which instead operates on a &Self, which is a problem.
Even if we could solve the previous problem somehow, we'd need to have is_bit_valid require that it's argument not be either experiencing interior mutation or, under Stacked Borrows, contain any UnsafeCells at all. When the NonNull<Self> is synthesized from a &[u8], this isn't a problem, but if in the future we want to support type-to-type conditional transmutation, it might be a problem. If, in the future, merely containing UnsafeCells is fine, then we could potentially design a wrapper type which "disables" interior mutation and supports field projection. This might allow us to solve this problem.

https://github.com/google/zerocopy/issues/590

Prior art
The bytemuck crate defines a CheckedBitPattern trait which serves a similar role to the proposed TryFromBytes.
Unlike TryFromBytes, CheckedBitPattern introduces a separate associated Bits type which is a type with the same layout as Self except that all bit patterns are valid. This serves the same role as MaybeValid<Self> in our design. One advantage for the Bits type is that it may be more ergonomic to write validation code for it, which is important for manual implementations of CheckedBitPattern. However, our design expects that manual implementations of TryFromBytes will be very rare. Since CheckedBitPattern's derive doesn't support custom validation, any type with safety invariants would need a manual implementation. By contrast, the TryFromBytes derive's support for a custom validation function means that, from a completeness standpoint, it should never be necessary to implement TryFromBytes manually. The only case in which a manual implementation might be warranted would be for performance reasons.

I think this design may be over-engineered to accommodate a future that's slightly off. The complexity of MaybeValid described here (or of Ptr/Maybe, as implemented in #699) anticipates a future in which we want to support full type-from-type transmutation. However, as I describe in https://github.com/google/zerocopy/discussions/696#discussioncomment-8015861, the proposed API's use of Ptr/Maybe in is_bit_valid generalizes poorly to unions (and perhaps enums, too).
Putting my Project Safe Transmute thinking hat on, I'd think that the minimal, ideal API would look something like this:
pub type MaybeAligned<'a, T, Alignment = invariant::AnyAlignment> =
    Ptr<'a, T, (invariant::Shared, Alignment, invariant::Valid)>;

pub unsafe trait TryFrom<Src> {
    fn is_bit_valid(candidate: MaybeAligned<'_, Src>) -> bool;

    /* other methods */
}

The key difference here is that is_bit_valid consumes a maybe-aligned pointer to Src, not to Self. This design is informed by three observations:

When we are validating a fallible transmutation from a Src to a Dst, our starting point is a candidate Src.
Since we want to accommodate unsized types, this candidate must be behind a pointer.
Since we want to accommodate packed types with potentially unaligned fields, this pointer candidate must be maybe-aligned.

Together, these three observations point to the above design.

Now, in 0.8, we're aiming to support TryFromBytes, not TryFrom<Src>. Substituting in &[u8]:
pub unsafe trait TryFromBytes {
    fn is_bit_valid(candidate: MaybeAligned<'_, [u8]>) -> bool;

    /* other methods */
}

...and observing that &[u8] is always aligned, we can even reduce this to:
pub unsafe trait TryFromBytes {
    fn is_bit_valid(candidate: &[u8]) -> bool;

    /* other methods */
}

Now, I don't think we need to go all the way to candidate: &[u8]. There's a lot of utility in defining our own wrapper type with useful methods. It's still useful, for instance, to project to the sub-range of bytes corresponding the places of fields in another type. What this approach avoids is then maintaining a (hard to maintain, as illustrated in https://github.com/google/zerocopy/discussions/696#discussioncomment-8015861) safety invariant where that sub-range is tagged as corresponding to another type. Instead, it's just initialized bytes all the way down.

IIUC the design implemented in 0.8.0-alpha.6 does not support the motivation example in the OP. Right now, TryFromBytes can be only derived and it's not possible to provide additional library-level validity checks which are needed, for example, for LogTime. What are plans for resolving this? Is it planned to be part of the v0.8 release?

The current implementation doesn't support custom validation, and we likely won't add it before 0.8 - we're prioritizing features that are backwards-incompatible right now. Once we release 0.8, then we'll implement custom validation since we can do that at any time without it being a breaking change.
Do you have a use case for custom validation?

Do you have a use case for custom validation?

Yes, we have types likes this:
// The `u64` contains (from highest bits to lowest):
//
// |  Unused | File ID | Unused | Block ID |
// |---------|---------|--------|----------|
// | 16 bits | 16 bits | 1 bit  |  31 bits |
#[repr(transparent)]
pub struct PageId(u64);

And some unsafe parts of our code rely on the unused holes to be equal to zeros. We could add explicit masking to this parts, but it would be more error-prone and it would delay detection of potential data corruption.

Gotcha, sounds good! We'll keep that in mind and try to prioritize customer validators if we can. If you have dev cycles to spare and want to speed it up, we can also mentor contributions to get some of the prerequisites done.
Also, feel free to submit a "customer request" issue mentioning this and any other features you'd like to see or features you currently use that you'd like us to put more love into. That's one of the few ways we have insight into how people are using or trying to use zerocopy. I'm on my phone rn so I don't have a link, but "customer request" is one of our issue templates.

I've been thinking about the interaction of custom validators and slice-tail DSTs - what if the result of is_bit_valid isn't a simple bool, but rather:
enum BitValidity {
    /// This &T contains invalid bits for the type.
    Invalid,

    /// This `&T` contains valid bits for the type.
    Valid,

    /// This `&T` would contain valid bits if the tail slice were truncated to this many elements.
    ValidIfTruncatedTo(usize),
}

That way ref_from_prefix and friends could consume the correct amount of data based on e.g. a length in the header of a &T.

@kupiakos I discussed this with @jswrenn and @djkoloski and decided to handle this as part of https://github.com/google/zerocopy/issues/1289#issuecomment-2121244709, when we're doing more work to consider the broader design space. We likely won't support this for 0.8, but may support it for 0.9 depending on how our design for #1289 goes.

The remaining TODOs have been spun out into their own issues:

#1832
#1831
#1330


Patch Proposals 1.0.6

Use this issue to link PRs that should be contained in patch 1.0.6.

#570

Release 1.0.6 is now finalized. Use new Patch Proposal Ticket.


Simplify installation instructions

Changes:

webpacker has moved package.json (and related files) to the project root from vendor/
There is no need to edit package.json directly. I added a yarn command to take care of adding the webpacker-react module & install it.

Fixes #11

Good catch, thanks! It does not fixes #11 completely as we still need to update the test & example apps for the new Webpacker, but at least the doc will be correct.


Basic Peering Provider

Adds a basic interface and types to get a running nodes peers via the: /eth/v1/node/peers<?optional state&direction filters>

Thank you for this pull request.  The API has recently undergone a significant rework, so please can you update the code with the new style?  Thank you.
You should also create the equivalent functions and tests in the mock multi and testclients directories to make this function available for all common use cases and testing.

Will do.


fix: kwok offerings to use correct requirements

Fixes #N/A
Description
The kwok instance types use a differently typed requirements. The instance types have the right requirements, but the offerings don't have any requirements. This fixes that bug and adds them in
How was this change tested?
make apply
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.02%) to 81.267%

Files with Coverage Reduction
New Missed Lines
%

pkg/scheduling/requirements.go
2
97.98%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
8299

Relevant Lines:
10212

💛  - Coveralls


The margin to the right of the avatar in a chat message should be 12px

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open Newdot
Open any chat
Observe the margin right to the avatar

Expected Result:
Should be 12px like in chat header and LHN
Actual Result:
It is 8px
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.2.48-2
Reproducible in staging?: y
Reproducible in production?: y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Expensify/Expensify Issue URL:
Issue reported by: @shawnborton
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1672827156356519
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~014f91d608cd8fd8d0
Upwork Job ID:<PHONE_NUMBER>481505792
Last Price Increase: 2023-01-09

I'm happy to take this one!

reviewing today!

Nice! @grgia going to mark internal then since you got this!

cc @shawnborton - we were fixing some alignments in this PR that I'm wrapping up today, is this issue a design choice or a bug I should add to that PR?

Ah good reminder. Yeah, I think we want to make sure the compose bar item alignment matches this 12px right padding. It looks like in my mockups, I had been working under the assumption that the margin to the right of chat avatars was 12px:

Quick follow up question,
Right now on staging it looks like its a 16px gap on LHN/Header, In figma, it's 12px. Should I update to 12px everywhere? Or just update the chat items to 16px?

Here's with 16px for reference:

Ah, let's fix that header margin to be 12px as well.

@grgia any update here? 🙇♂

Just merged this one!

NICE! Thanks @shawnborton !

Payment is due for C+ review.
cc: @dylanexpensify

On it!

@sobitneupane sent invite to apply for job!

@shawnborton, @sobitneupane, @grgia, @dylanexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

@sobitneupane payment sent!

For Regression Test step @shawnborton do we think this is something we should add a step for? I wonder if it might be something captured by visual guidelines, but curious for your thoughts!

@shawnborton, @sobitneupane, @grgia, @dylanexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

just bumping the above comment @shawnborton! 🙇♂

Good question. I suppose we could add a step to make sure that there is always 12px of space between the avatar and the sender name? But yeah, maybe that would be captured by the visual guidelines whenever those are ready to go?

Yeah, lemme cc @mallenexpensify to see his thoughts! I think this might be more a visual guideline bit than a test step IMO

I added to the Testing guidelines doc under design - link
We shouldn't need to  create or update anything in TestRail.

@shawnborton, @sobitneupane, @grgia, @dylanexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

@shawnborton, @sobitneupane, @grgia, @dylanexpensify Huh... This is 4 days overdue. Who can take care of this?

@shawnborton, @sobitneupane, @grgia, @dylanexpensify Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

@shawnborton, @sobitneupane, @grgia, @dylanexpensify 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

Pretty sure this can be closed as regression test steps were added to the testing guidelines


Add assignment operator

Add function named assign available in R and the change in the direction of arrow.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x] My changes do not use shortened URLs or affiliate links.

Closes #XXXXX

Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding. ✈

Hi,
As there has been no response from your end for a while, we are closing this PR.
Feel free to request this PR to be reopened, if you still wish to make the changes you originally added.  Also, remember to update your fork, so you have the latest version of master in case it has changed significantly.
Happy Coding! ✈


feat(kno-3591): run a local workflow

Description
Run a local workflow rather than a remote workflow.
Todos

[x] Fix tests

Tasks
KNO-3591

closign in favor of this one: https://github.com/knocklabs/knock-cli/pull/165


Complete #708 by updating _NET_SUPPORTED.

Description
#708 is incomplete because it doesn't add _NET_DESKTOP_VIEWPORT to _NET_SUPPORTED. This update makes that addition, which should make polybar happy. Closes #708.
Checklist

[x] I've read CONTRIBUTING.md

[x] I've considered how to best test these changes (property, unit,
manually, ...) and concluded: needs to be manual

[n/a] I updated the CHANGES.md file

@compromyse, can you test this? Either copy the files directly over your tree, or install the GitHub command line tool and do gh pr checkout 722.

I have tested this and it does seem to work


Upgrade path 4.11 through 4.11.1 to 4.12

Description
Upgrade path 4.11.0 --> 4.11.1 --> 4.12.0
Types of changes

[?] Breaking change (fix or feature that would cause existing functionality to change)
[?] New feature (non-breaking change which adds functionality)
[?] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):
How Has This Been Tested?

Checklist:

[ ] I have read the CONTRIBUTING document.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
Testing
[ ] I have added tests to cover my changes.
[ ] All relevant new and existing integration tests have passed.
[ ] A full integration testsuite with all test that can run on my environment has passed.

@blueorangutan package

@DaanHoogland let me do a quick upgrade test.

@blueorangutan package

@borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1903

Packaging result: ✔centos6 ✖centos7 ✔debian. JID-1920


What's the difference between readout and decode, conceptually?

First of all, this library looks like a great addition to Keras, thanks for providing it. Now for my question: This might be obvious, but I'm not totally clear on the uses of readout=True and decode=True in your examples. When would I use either one, and when would I want to specify both arguments?
I see that decode=True requires setting an output length (so it can be used for n-to-m seq2seq learning), and that readout simply basically adds the previous timesteps final output to the current input. Isn't this sort of  "readout" required for decoders in most settings? When does readout=True by itself become useful? Also, slightly less related: how do I use the RecurrentContainer to specify the initial hidden state of a decoder?
Finally, there seem to be multiple readout modes: https://github.com/datalogai/recurrentshop/blob/master/recurrentshop/engine.py#L244-L251 , are they documented somewhere?
I know these are a lot of questions, but perhaps you could just generally clarify the concepts a little. Thank you.

Readout is useful when you have a stack of rnn cells, and you want the output of the top cell at time t be available to the bottom cell at t-1.
For initializing the hidden states of a recurrent container, simple create one (rc = RecurrentContainer(...)), build it (rc.build(input_shape)) and reset the states (rc.states=[list of tensors]).

I see, thanks. Doesn't a decoder always need the readout=True flag then?

Not really.. since readout is not the only information being transferred across time. There are states too.

Ah, yes that makes sense. Just out of curiosity: do you transfer the raw class probabilities tensor as input to the next timestep, or the one-hot encoded argmax, i.e. the resulting classification?


Relationship Issue : displaying no results

Laravel Version: latest
Voyager Version: latest
PHP Version: 7.1
Database Driver & Version: Apache/2.4.29 (Win32) OpenSSL/1.0.2l PHP/7.1.11

Description:
I created two tables naming items and product_types ... I added two inputs in the product_type and created a relationship for items with product_types..
when I try to add an item I am able to select the product_type with a drop down menu and I'm able to select..but after saving the column product_type is displaying no results
My item bread property:

When adding an item:

after adding when I view the item:

This also seems to be fixed in https://github.com/the-control-group/voyager/pull/2837 (1.x-dev)
The default selected type is now text and not checkbox.
If it isn't fixed (in future 1.1) please open a new issue!

@Overfinch  thankyou it works to me also.


libndp: fix cross compilation to musl

Description of changes
Assume that malloc works properly if cross compiling.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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/)
24.05 Release Notes (or backporting 23.05 and 23.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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Why musl? I assume musl test programs can run on a glibc buildPlatform.

configure won't even try if it's cross compiling (which is the same reason we can't use canExecute)


propertyNames, patternProperties do not work v2

This bug is resolved https://github.com/justinrainbow/json-schema/issues/36 but it seems it does not work properly.
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "http://json-schema.org/draft-07/schema#",
  "title": "Schema",
  "type": "object",
  "propertyNames": {
    "$ref": "#/definitions/localeIdentifier"
  },
  "patternProperties": {
    "": {
      "type": "array",
      "items": {
        "$ref": "#/definitions/localeIdentifier"
      }
    }
  },
  "definitions": {
    "localeIdentifier": {
      "type": "string",
      "maxLength": 2,
      "minLength": 2
    }
  }
}

Test data:
{"abc":["ab"]} // works
{"ab":["abc"]} // works

This 2 examples should fail.

It looks like propertyNames constraint is not supported and patternProperties works only when pattern is defined (eg ".*") but it still should work with empty value.

This library does not support draft-07, but your schema requires some newer features in order to function properly. The latest version of the spec that is fully supported by this library is draft-04. Unfortunately, this does mean that I'm going to close this issue without a fix in place.
You are welcome to submit a PR implementing this functionality - we are extremely short of manpower on this project, so any useful contributions to the codebase are greatly appreciated.

@piotrkochan An empty key for patternProperties is not valid. ECMA-262 states that a regular expression literal (which the key must be) may not be empty.

Still it does not work even for patterns like:
    "^[A-Z]{2}+$": {

@piotrkochan That looks like your example from #584. If so, this isn't working because your data does not match the pattern. That pattern will only match a string containing an even number of upper-case characters, but your test data was lower-case.
If you're saying that this isn't working with data that it should be matching, could you please post some example data here so that I can investigate further.


remote sensing

I am using this great library in a project to monitor the resources of a *nix machine.
Is there any way to measure with SI the resources on a different remote machine(where Nodejs is not installed)?
Expanding some port remotely? or with tools like netcat,ncat,telnet or other?

Hi @st3b1t
The functionality you describe is currently not available. This would be something like in windows WMI remote connections. As far as I know, this is not available in *nix systems.
This npm package is intended to run only locally with node installed. To be able to get detailed system information on remote *nix machines, you would need to run some kind of local code (node, bash, …) and then a channel to send this to the master. If you are planning to use systeminformation, you need node installed don the remote machine.


[USERSNAP] Searching for a Drep doesn't work. In order to find them you need to scroll until it appears. Added screenshots to show bug.  *The DRep updated its name about 12 hours ago.

Taken at: https://gov.tools/connected/drep_directory
Fields:

Add a comment: Searching for a Drep doesn't work. In order to find them you need to scroll until it appears. Added screenshots to show bug.

*The DRep updated its name about 12 hours ago.
Browser: Chrome 129 (Windows 10)
Screen size: 3440x1440
Open #143 in Usersnap
Powered by Usersnap.

Duplicate of #1893 .


Can any one help me make code for manipulating egg hatch?

Can any one help me make code for manipulating egg hatch?

Please keep in mind that this is an issue tracker, not a support forum <3


Bump version to 1.1.0

/domain @phantomphildius @Betterment/test_track_core
/no-platform

<< domain lgtm the naming is a little more descriptive and aligns nicely with the rake task!


Loops inside cascade! are not explained well

In an example it says:
let hash_map = cascade! {
  HashMap::new();
  ..insert("foo", "bar");
  println!("Look! You can put statements in a cascade!");
  for i in 0..3 {
    println!("You can put loops in here too! Make sure to put a semicolon at the end!");
  };
};

So there's a loop inside cascade!, but it doesn't invoke any ..method. Is it possible to invoke them? Also the remark about semicolon is very vague, what's the rule here? Why should it be there?
My code:
let x = cascade! {
  MultiLinFunc::new_zero(blink_low_brightness);
  ..add_const_segm(t_in_out);
  for i in 0..blink_rep {
    ..add_segm(t_unit, 1.0);
    ..add_segm(t_unit, blink_low_brightness);
  };
  ..add_segm(t_in_out, 0.0);
};

doesn't compile, I get complaints about the two calls inside the loop:
error[E0425]: cannot find function `add_segm` in this scope
  --> src/weather_clock.rs:36:11
   |
36 |         ..add_segm(t_unit, 1.0);
   |           ^^^^^^^^ not found in this scope

error[E0425]: cannot find function `add_segm` in this scope
  --> src/weather_clock.rs:37:11
   |
37 |         ..add_segm(t_unit, blink_low_brightness);
   |           ^^^^^^^^ not found in this scope

So I suppose the crate doc is not clear enough on this. I don't really know if it's supposed to work and I'm just doing something stupid, or it's not expected to work in the first place.

@TPReal Thank you for opening this! Sorry, I should have made the documentation more clear: it is not possible to put .. within loops. Unfortunately, due to limitations with Rust's macro parser, it is not possible for cascade to parse for/while statements, so it treats all loops as a single expression. Of course, it lets you put .. inside of blocks, so I can see how this would be confusing.
I'll update the documentation to explain this. Sorry for taking so long to get to this issue (I never got a notification for it). Let me know if you have any further questions!

@TPReal Thank you for opening this! Sorry, I should have made the documentation more clear: it is not possible to put .. within loops. Unfortunately, due to limitations with Rust's macro parser, it is not possible for cascade to parse for/while statements, so it treats all loops as a single expression. Of course, it lets you put .. inside of blocks, so I can see how this would be confusing.
I'll update the documentation to explain this. Sorry for taking so long to get to this issue (I never got a notification for it). Let me know if you have any further questions!


suitcase-tiff v0.3.0

It is very likely that the current package version for this feedstock is out of date.
Notes for merging this PR:

Feel free to push to the bot's branch to update this PR if needed.
The bot will almost always only open one PR per version.
Checklist before merging this PR:

[ ] Dependencies have been updated if changed: see upstream
[ ] Tests have passed
[ ] Updated license if changed and license_file is packaged

Note that the bot will stop issuing PRs if more than 3 Version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
Here is a list of all the pending dependencies (and their versions) for this repo. The first package is the current feedstock package. Please double check all dependencies before merging.
Feedstock Packages Build Status

#
Repo
Build  Health
nsls2forge  PyPI  defaults  conda-forge  GitHub  Versions
Downloads

1
suitcase-tiff

2
tifffile

Power-cycled to check how it works with the tifffile package from defaults.

Power-cycled to pick up https://github.com/nsls-ii-forge/suitcase-utils-feedstock/pull/4.


SSL handshake failed seems to happen too often.

I've gotten this about 30 times in the last 6 months, seems to always be blockstream, but I'm always using blockstream as my primary server.
How often is blockstream SSL cert changing and could this error be cause by something else?

@Transisto are you using a VPN by any chance? That is what causes the popup to show up for me I think

@Transisto are you using a VPN by any chance? That is what causes the popup to show up for me I think

No I wasn't, on the plus side it seems to not happen anymore, also haven't used Sparrow much though.


Dropdown aligned to the right shifts slightly when 'loading' is enabled.

Steps
Open https://codepen.io/anon/pen/OxNQjE and compare how two dropdowns work
Expected Result
Both dropdowns(left and right aligned should not shift when adding 'loading')
Actual Result
The right aligned dropdown shifts slightly on 'loading' added.
Version
2.2.13
Testcase
Without React https://jsfiddle.net/n22dmm4L/15/
With React https://codepen.io/anon/pen/OxNQjE

Hi @vdytsiak, we don’t track issues with the React implementation in this repository; if you think it’s an issue with CSS, could you please create a test case without React? You can fork this JSFiddle.

Shure, here it is - https://jsfiddle.net/n22dmm4L/15/

@vdytsiak Thanks, we’ll see if it makes sense to change it in the core. In the meantime, you can override it in installation_folder/src/site/modules/dropdown.overrides, these values seem to be working:
.ui.loading.dropdown:not(.selection) > i.icon {
  height: 1em !important;
  width: 1em !important;
  margin-left: 0.572em;
}

Rebuild the framework after updating dropdown.overrides.

Thank you for the quick response!

This is (also) fixed in the community fork Fomantic-UI by
https://github.com/fomantic/Fomantic-UI/pull/1807


error: no matching member function for call to 'set_device'

YouTube-8M Feature Extraction and Model Inference
Fellow this
https://github.com/google/mediapipe/tree/master/mediapipe/examples/desktop/youtube8m
When I'm running the command below to extract video features, the errors found as follows.
Has anyone ever found and solved this situation?
bazel build -c opt --linkopt=-s \
--define MEDIAPIPE_DISABLE_GPU=1 --define no_aws_support=true \
mediapipe/examples/desktop/youtube8m:extract_yt8m_features

My configuration
MacOS 10.15.6
python==3.7
Tensorflow==1.15
g++ --version

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.3 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Errors:
INFO: Build options --action_env, --define, and --linkopt have changed, discarding analysis cache.
WARNING: /private/var/tmp/_bazel_appletreee/c2ac5852e797c79be4eb5198c68ddbab/external/com_google_audio_tools/third_party/fft2d/BUILD:3:1: in linkstatic attribute of cc_library rule @com_google_audio_tools//third_party/fft2d:fft2d: setting 'linkstatic=1' is recommended if there are no object files
WARNING: /private/var/tmp/_bazel_appletreee/c2ac5852e797c79be4eb5198c68ddbab/external/org_tensorflow/tensorflow/core/BUILD:1757:1: in linkstatic attribute of cc_library rule @org_tensorflow//tensorflow/core:lib_internal: setting 'linkstatic=1' is recommended if there are no object files. Since this rule was created by the macro 'cc_library', the error might have been caused by the macro implementation
WARNING: /private/var/tmp/_bazel_appletreee/c2ac5852e797c79be4eb5198c68ddbab/external/org_tensorflow/tensorflow/core/BUILD:2202:1: in linkstatic attribute of cc_library rule @org_tensorflow//tensorflow/core:framework_internal: setting 'linkstatic=1' is recommended if there are no object files. Since this rule was created by the macro 'tf_cuda_library', the error might have been caused by the macro implementation
INFO: Analyzed target //mediapipe/examples/desktop/youtube8m:extract_yt8m_features (112 packages loaded, 10672 targets configured).
INFO: Found 1 target...
INFO: From ProtoCompile mediapipe/framework/calculator.pb.h:
bazel-out/darwin-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/calculators/internal/callback_packet_calculator.pb.h:
bazel-out/darwin-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/framework/calculator_profile.pb.h:
bazel-out/darwin-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From ProtoCompile mediapipe/framework/tool/calculator_graph_template.pb.h:
bazel-out/darwin-opt/bin/external/com_google_protobuf/src: warning: directory does not exist.
INFO: From Linking external/org_tensorflow/tensorflow/core/util/ctc/libctc_loss_calculator_lib.a:
warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: warning for library: bazel-out/darwin-opt/bin/external/org_tensorflow/tensorflow/core/util/ctc/libctc_loss_calculator_lib.a the table of contents is empty (no object file members in the library define global symbols)
[1,869 / 2,792] 128 actions, 8 running
[1,925 / 2,792] 128 actions, 8 running
ERROR: /Users/appletreee/mediapipe/mediapipe/calculators/tensorflow/BUILD:471:1: C++ compilation of rule '//mediapipe/calculators/tensorflow:tensorflow_session_from_frozen_graph_calculator' failed (Exit 1) wrapped_clang failed: error executing command external/local_config_cc/wrapped_clang '-D_FORTIFY_SOURCE=1' -fstack-protector -fcolor-diagnostics -Wall -Wthread-safety -Wself-assign -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG ... (remaining 174 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
mediapipe/calculators/tensorflow/tensorflow_session_from_frozen_graph_calculator.cc:55:12: error: no matching member function for call to 'set_device'
      node.set_device(device_id);
      ~~~~~^~~~~~~~~~
bazel-out/darwin-opt/bin/external/org_tensorflow/tensorflow/core/framework/node_def.pb.h:1007:22: note: candidate function not viable: no known conversion from 'absl::string_view' to 'const std::string' (aka 'const basic_string<char, char_traits<char>, allocator<char> >') for 1st argument
inline void NodeDef::set_device(const std::string& value) {
                     ^
bazel-out/darwin-opt/bin/external/org_tensorflow/tensorflow/core/framework/node_def.pb.h:1022:22: note: candidate function not viable: no known conversion from 'absl::string_view' to 'std::string' (aka 'basic_string<char, char_traits<char>, allocator<char> >') for 1st argument
inline void NodeDef::set_device(std::string&& value) {
                     ^
bazel-out/darwin-opt/bin/external/org_tensorflow/tensorflow/core/framework/node_def.pb.h:1028:22: note: candidate function not viable: no known conversion from 'absl::string_view' to 'const char *' for 1st argument
inline void NodeDef::set_device(const char* value) {
                     ^
bazel-out/darwin-opt/bin/external/org_tensorflow/tensorflow/core/framework/node_def.pb.h:1035:22: note: candidate function not viable: requires 2 arguments, but 1 was provided
inline void NodeDef::set_device(const char* value,
                     ^
1 error generated.
Target //mediapipe/examples/desktop/youtube8m:extract_yt8m_features failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 905.487s, Critical Path: 885.70s
INFO: 423 processes: 423 darwin-sandbox.

Try commenting out https://github.com/google/mediapipe/blob/bdfdaef30585719ed2cd1bc598a3e9879bcc4a1c/mediapipe/calculators/tensorflow/tensorflow_session_from_frozen_graph_calculator.cc#L54 and see if it works.
We will upgrade our tensorflow version soon.

The tensorflow dependency is updated in https://github.com/google/mediapipe/commit/1db91b550aeb43c742042f5ab947b81d90710079.


celery_task_rejected and celery_task_failed metrics are not updating even if the celery task is failing

I have intergerate this celery exporter in my django app and set these two fields as True in settings:
CELERY_WORKER_SEND_TASK_EVENTS = True
CELERY_TASK_SEND_SENT_EVENT = True
The celery_task_failed metric is not getting update even after my celery task is failing to execute and throwing an exception. I have use the docker image and passed my broker url. I have attached my yaml file for deployment and the metric data which shows only some data and not the failed task data.
Metric.txt
celery-exporter.txt

It was working fine the before day where it was throwing the exception and setting celery_task_failed metric but now its doesnt update it, the code is same but now its not showing me that failed task in metrics.

I have no problems with those two metrics. If you think you've found a bug a pull-request is welcome.

Hi, actually the issue was from my end I didn't enable or use to the -E options in my celery command to send task related data.
Thanks for your quick reply, I wanted to know if we are going to get the metric for getting the size of queue, it would be really helpful if we can have that metric data as well.

No worries :+1: I'm happy that this project is in use.
If you'd like to add the metric for the queue size please open a PR. AFAIK Celery does not expose this through their metrics interface.


Add persistent memory type for allocator/deallocator

MIOpen needs persistent memory for some kernels to use.
This patch is depended on a MIOpen patch, so need to wait until that patch been released by MIOpen.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

jenkins: ok to test

jenkins: retest this please

LGTM.
Let's see if it can pass with ROCm2.5 build MIOpen.

@sunway513 does MIOpen in ROCm 2.5 contain required interface changes already? I was under the impression that the builds are expected to fail

No, the corresponding change in MIOpen won't be available in ROCm2.5 or upcoming ROCm2.6. I'm also under the impression that the build will fail.
Will need to hold merging this PR to develop-upstream before MIOpen being updated publicly.

Close this PR, due to we're planning to change the use of persistent memory


Add dataset: digital_libraries_document_types

A URL for this dataset
https://doi.org/10.6084/m9.figshare.4834229.v2
Dataset description

Abstract: In this paper, we address the problem of classifying documents available from the global network of (open access) repositories according to their type. We show that the metadata provided by repositories enabling us to distinguish research papers, thesis and slides are missing in over 60% of cases. While these metadata describing document types are useful in a variety of scenarios ranging from research analytics to improving search and recommender (SR) systems, this problem has not yet been sufficiently addressed in the context of the repositories infrastructure. We have developed a new approach for classifying document types using supervised machine learning based exclusively on text specific features. We achieve 0.96 F1-score using the random forest and Adaboost classifiers, which are the best performing models on our data. By analysing the SR system logs of the CORE digital library aggregator, we show that users are an order of magnitude more likely to click on research papers and thesis than on slides. This suggests that using document types as a feature for ranking/filtering SR results in digital libraries has the potential to improve user experience.

This is mainly of interest as a tabular dataset since the available fields in the datasets are derived features from the original textual data.
Dataset modality
Other
Dataset licence
Creative Commons Attribution 4.0 International
Other licence
No response
How can you access this data
As a download from a repository/website
Confirm the dataset has an open licence

[X] To the best of my knowledge, this dataset is accessible via an open licence

Contact details for data custodian
No response

For this dataset, if you want to access the actual articles, it looks like you have to register for a Slideshare API (which might be free) and the Core API which has some terms of use. Is that still okay to use?

For this dataset, if you want to access the actual articles, it looks like you have to register for a Slideshare API (which might be free) and the Core API which has some terms of use. Is that still okay to use?

Good spot, I'll have a bit more of a think about this one, but this one is probably a lower priority given that getting at the actual data will be a bit more convoluted. I'll take this off the backlog for now.

I will close this one for now since it seems like it will be difficult to get the data in an accessible format.


Add Back/Forward navigation long press menu

Task/Issue URL: https://app.asana.com/0/414235014887631/1202297990501898/f
Description:
This PR adds a feature for users to long press the back/forward buttons on the navigation bar and be presented with a menu of options that the user can go directly to.
Steps to test this PR:

Visit a bunch of different websites
Long press the back button and check if the sites you visited are there
Select a website in the middle, check if the site loaded correctly
Long press the forward button and check if the stack displays the websites you visited after the current one.

Check if the order of the websites on the back button are newest at the bottom, oldest at the top
Check if the order of the websites on the forward button are newest at the top oldest at the bottom

Check if protections are being respected after reloading a website from the back button

This feature is iOS 14+ only, check if this is being respected.

Device Testing:

[x] iPhone
[x] iPad

OS Testing:

[x] iOS 13
[x] iOS 14
[x] iOS 15

Theme Testing:

[x] Light theme
[x] Dark theme

Thank you @samsymons  :)

State restoration: If you close the browser, the back/forward list is gone. The problem is that this list is immutable so we'd have to do something custom to handle this correctly, since a lot of the state restoration functionality in WKWebView is private. I don't think this should block the initial implementation from going in, so don't worry about this here.

Yep, since we currently don't have state restoration for the back/forward menus as it is today I consider this to be something outside of the scope for this feature.

Efficiency: I worry that re-building the menu on every navigation event is inefficient, since I expect users to only bring it up occasionally during a session. Creating and showing it lazily would be a nice improvement, as long as it's fast to create and display it lazily if you have a large set of back-forward items - but again I don't view this as a blocker.

Good point. I did check performance during implementation and didn't find anything that made me worry. The main reason it's not lazy loaded is because I didn't find a good way to do it without fighting UIKit. The menu is a property of UIBarButtonItem, which means we don't actually have a callback for when it's called. One way to fix this would be to add a tap recognizer in both buttons, create the menus in a lazy way and then manually display the UIMenu using the button frame, but it feels convoluted. Am I overthinking this? If you think it's a good approach or if you have a different solution I'm not considering please let me know :)

Instrumentation: I considered suggesting we add instrumentation to get a read on how frequently this menu is used, but am now against that idea since there's not a lot to be learned with that knowledge. Let's leave pixels out. 🙂

Agreed. If necessary we can add it later.
https://github.com/duckduckgo/iOS/pull/1199#pullrequestreview-1012737379


[azure-storage] Add devops step for validating shared code

The 3 storage SDKs have a large internal module of shared code.
We should add a CI step to validate the each SDK has the most up-to-date version of the shared module.
The CI step should also validate the error code enum against the swagger specs.

Rakshith swung by to give some additional details here. I can't get to this before preview 4, but given that, here's my thoughts.
Folder Structure for Storage _shared modules:
sdk/storage/azure-storage-blob/
   azure/
       storage/
          _shared

The above _shared occurs in all 3 of the storage libaries. We need to validate that all contents are identical between these 3 packages.
I see this being possible in a few ways (not an exhaustive list):

Adding an additional step to build-test.yml that always runs a script that compares all _shared folders within a servicedir.
Add additional steps to the ci.yml for the storage
Add a lookup file w/ run X custom scripts per service dir check. Something along the lines of:

in sdk/storage ci runs, add this additional custom step.

azure-storage-Y/_shared should be autodetected, and then ensure that all values of Y would be compared.
azure-storage-file/queue/blob all the _shared should be exactly the same.

Hi @scbedd it doesn't seem that this was ever shipped? any updates on this?

Bringing this thread back to life again.
Another approach we can look into is whether the shared directory can be maintained separately, in a single place in the repo, where it can be vendored into the packages as part of a pipeline.
In order for that to work, work would need to be done to make sure the shared directory is truly identical between all Storage SDKs.

This is now an issue across several SDKs - closing this in favour of a new issue that covers the broader scope: #28232


When I run visualization command, an error occured.

I first ran:
python save.py checkpoint=/home/qzh/DeFlow/checkpoints/deflow_best.ckpt dataset_path=/home/qzh/DeFlow/data/av2/preprocess_v2/sensor/val
and it showed:
We already write the flow_est into the dataset, please run following commend to visualize the flow. Copy and paste it to your terminal: python tools/visualization.py --res_name 'deflow_best' --data_dir /home/qzh/DeFlow/data/av2/preprocess_v2/sensor/val Enjoy! ^v^ ------
so I ran this command, then, an error occured.
File "tools/visualization.py", line 114, in
fire.Fire(vis)
File "/home/qzh/anaconda3/envs/deflow/lib/python3.8/site-packages/fire/core.py", line 135, in Fire
component_trace = _Fire(component, args, parsed_flag_args, context, name)
File "/home/qzh/anaconda3/envs/deflow/lib/python3.8/site-packages/fire/core.py", line 468, in _Fire
component, remaining_args = _CallAndUpdateTrace(
File "/home/qzh/anaconda3/envs/deflow/lib/python3.8/site-packages/fire/core.py", line 684, in _CallAndUpdateTrace
component = fn(*varargs, **kwargs)
File "tools/visualization.py", line 73, in vis
opt.background_color = np.asarray([80/255, 90/255, 110/255])
AttributeError: 'NoneType' object has no attribute 'background_color'

Could you check your open3d version, it must >=0.18.0

import open3d
open3d.version
'0.18.0'
Thanks for your reply, I have checked.

but the error still exists

I don’t think it’s model or data problem but open3d didn’t work on your
platform.
Could you please check in open3d repo issue if someone have same issue?
On Thu, Nov 7, 2024 at 11:26 Zihan Qin @.***> wrote:

but the error still exists
—
Reply to this email directly, view it on GitHub
https://github.com/KTH-RPL/DeFlow/issues/9#issuecomment-2461861681, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AIN2HBB6NHNDO7JNTUIXMHLZ7M56LAVCNFSM6AAAAABRKL4NYSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRRHA3DCNRYGE
.
You are receiving this because you commented.Message ID:
@.***>


Fix/32123: Remove pending fields when saving waypoints

Details

Remove pending fields when saving waypoints
Fixed Issues

$ https://github.com/Expensify/App/issues/32120
PROPOSAL: https://github.com/Expensify/App/issues/32120#issuecomment-1829915666
Tests

Go to a workspace chat with distance request.
Open distance request details page.
Click Distance.
Click Add stop.
Add a new address.
Verify that the map, amount and distance in the background don't not show TBD

[x] Verify that no errors appear in the JS console

Offline tests

Same above
QA Steps

Same above

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Screencast from 15-12-2023 17_56_33.webm

Android: mWeb Chrome
https://github.com/Expensify/App/assets/141406735/3ee14199-95ac-4f97-94cc-327ec48d7662

iOS: Native
https://github.com/Expensify/App/assets/141406735/ddba0779-44cf-4df3-9d02-c58801c27485

iOS: mWeb Safari
https://github.com/Expensify/App/assets/141406735/cf275301-592c-436b-b83a-ae922b061a43

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/141406735/e0a5c94b-388a-4b55-af8d-ec7132e5fe33

MacOS: Desktop
https://github.com/Expensify/App/assets/141406735/6601cce0-fb18-44c4-86ba-fa43632f32af

@rlinoz Please ignore this PR, It is my mistake. I shouldn't mark PR as ready before completing the body description.
@ntdiary Please sefl assign to this PR
Sorry all guys for the inconvenience

🚀 Deployed to staging by https://github.com/hayata-suenaga in version: 1.4.14-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/hayata-suenaga in version: 1.4.14-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/jasperhuangg in version: 1.4.14-6 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Validating $ref in schema

Similar to #904 , check_schema does not verify that $ref references resolve. We get (unhandled) errors from validate instead.

Schemas with refs that don't resolve are valid under the metaschema, so this one is expected behavior.


How can one-way animation looping be implemented?

Here is my sample code. If loop is implemented as the following, 1-> 10, 10-> 1, 1-> 10, ... are repeated. But I want to repeat 1-> 10, 1-> 10, 1-> 10. Is there any way?
const LED = props => {
  const [spring, set] = useSpring(() => ({
    from: { number: 1 },
    to: async next => {
      while (1) {
        await next({ number: 10 });
        await next({ number: 1 });
      }
    },
    config: {
      duration: 3000
    }
  }));

  return <a.div>{spring.number}</a.div>;
};

In the latest canary, you can use the loop prop:
useSpring({
  loop: true,
  from: { n: 1 },
  to: { n: 10 },
})

Note: I have some bug fixes for the loop prop ready for the next canary, so bugs might exist in the latest canary that prevent the example above from working as expected.

Thank you and look forward to the next release :)

Now available in v9.0.0-rc.2 #985

u can do so in v8 as well by reset flag
useSpring({
reset: true,
from: { n: 1 },
to: { n: 10 },
})

@shubhamkes Sort of. That requires you to rerender for each repetition.

oh is it?  thought they are same. is v9.0.0-rc.2 recommended for prod?


Object order

Hello, thanks for the sjson/gjson!
Bug or feature?
https://go.dev/play/p/NmpNpe6-DRb

Neither.
https://pkg.go.dev/github.com/tidwall/sjson#SetRaw

Thanks!


WIP

🤔 해결하려는 문제가 무엇인가요?
🎉 변경 사항
🙏 여기는 꼭 봐주세요!
사용 방법
🌄 스크린샷
📚 참고

Codecov Report
Patch and project coverage have no change.

Comparison is base (0b1efd5) 95.65% compared to head (11c9463) 95.65%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #33   +/-   ##
=======================================
  Coverage   95.65%   95.65%
=======================================
  Files           9        9
  Lines          46       46
  Branches        4        4
=======================================
  Hits           44       44
  Misses          2        2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.