Improve automated accessibility testing

TBC - we will write this up after epic kickoff

This is duplicated by the new accessibility strategy activity: https://github.com/alphagov/govuk-frontend/issues/3041


Fix(my-organization): fixed my organization functinalities

Signed-off-by: Abhishek Mishra<EMAIL_ADDRESS>Functionality:
fixing the UI of my organization page and its upload logo feature
Solution:
fixed UI of my org in dark theme and fixed the functionalities for updating organization logo.
also did some necessary changes in start service and firebase indexing
Risk level:

[ ] high
[x] medium
[ ] low

How to test:
try the my organization page in dark mode and also try to upload a logo and check in firestore

@abhishek-mishra019 resolve merge conflicts

@abhishek-mishra019 resolve merge conflicts

resolved


Add inference usage instead of mocking handler function in serverless_handler.py

After recent changes still applies to runpod/torch implementation


isNaN usage not covered by tests

There are some (~5) occurrences of isNaN usage in code, and no single test to understand their real purpose.
And that function is known to be not so obvious: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/isNaN
It's not straightforward to make sure that value is number, because boolean and empty string also coercing to numbers.
So I am not sure that our current usage is correct.
And more - instead of coercing numeric strings - I'd prefer throwing errors
Thus, we need to refactor that parts and cover them by tests.

Ref: https://github.com/Leaflet/Leaflet/issues/7128#issuecomment-767523311

isNaN itself is not reliable way to check if value can be converted to number. There a lot of discussions, and I just point to thes unit tests: https://run.plnkr.co/plunks/93FPpacuIcXqqKMecLdk/
So I propose to implement isNumeric like here: #7765
Just making sure that the value is convertable tu number is not enough. Instead we should actually convert the value to number (otherwise '5'+5 = '55').
There are a lot of places in code vulnerable to this sort of bugs, and a number of open issues (too lazy to link them now).

@johnd0e
Is the issue still open? Because if it is, I'd like to try if that's fine.

@itsyourOOP I think this not a good issue to start, it is currently not clearly how we want to further with the number check in Leaflet.
A easy issue to start would be: #7787


Update version

Codecov Report
Base: 90.62% // Head: 90.62% // No change to project coverage :thumbsup:

Coverage data is based on head (46894e7) compared to base (5539e84).
Patch coverage: 100.00% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #141   +/-   ##
=======================================
  Coverage   90.62%   90.62%
=======================================
  Files           1        1
  Lines          32       32
=======================================
  Hits           29       29
  Misses          3        3

Impacted Files
Coverage Δ

src/Spinners.jl
90.62% <100.00%> (ø)

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

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


Add multi-robot sim ISAAC13 scenario instructions

These instructions are working well for me (at least up to a few panoramas). Sharing for others who would like to test the integrated system and don't have granite table access.

Closes #144


Chunk Encoding

Describe the feature
SEP: /in-progress/shared/dynamic-payload-trait.md
Use Case
Required for GA
Proposed Solution
No response
Other Information
No response
Acknowledgements

[ ] I may be able to implement this feature request
[ ] This feature might incur a breaking change

Closing as duplicate of #356


Modularise dependencies

Closes #401
TODO: remove .github/workflows/build-test-python-release.yml (currently used to generate a wheel here: https://github.com/pi-top/pi-top-4-Miniscreen-App/tree/hypermodern/whl)

Replaced by #421


Does Ollama costs Money?

I don't find anything. :(

Ollama is free and open source. Could you be more explicit about what you mean by “I can’t find anything “? If you have any questions, please feel free to drop them below

Thanks. I mean when i say something to ollama, do i need to pay in Credits? Because i saw some Prices when i searched: Ollama Price.

You do not need to pay anything, it runs locally on your computer

I found this: https://gist.github.com/jerzydziewierz/3b4a169c8d7cba89e18f613b32c3f52b

I see. however, ollama is free and open source software itself.
you might wanna check this: https://github.com/ollama/ollama
ps: if this issue is no longer relevant could we close it? thanks

of course. thx for the help :D


Replace ExprX::Admit with ExprX::AssertAssume

This replaces ExprX::Admit, which meant assume(false), with ExprX::AssertAssume, which can assert or assume an expression.  This allows us to put assert and assume in builtin rather than pervasive, which removes a dependency that the verus! syntax macro had on pervasive and is more consistent with the other forms of assert (assert_nonlinear_by, assert_bitvector_by, assert_forall_by, assert_bit_vector), which are all in builtin.  It allows us to write small test cases and examples that use assert but don't require all of pervasive (particularly in the tutorial; see https://github.com/secure-foundations/verus/blob/main/source/docs/guide/src/getting_started.md and https://github.com/secure-foundations/verus/blob/main/source/rust_verify/example/guide/getting_started.rs , for example).
@channy412 You might want to check that --expand-errors still works as expected; this incorporates a change to the span printing that we discussed earlier so that assertions are still split correctly in --expand-errors.

Looks great to me, thank you!  This also looks more natural for expand-errors since it doesn't need to inline perviasive::assert into its requires(b)
There are a few places that expand-errors use crate::def::pervasive_assert_path().
Now that verus! does not depend on pervasive::assert, should I go ahead and remove those code paths?

Yes, I think you can remove those code paths.


Intermittent test failure for test_csr() and test_signing()

Hi,
We are currently seeing intermittent test failure when executing parsec-cli-tests.sh on the FVP platform. The intermittent failure test cases are always test_csr() and test_signing().
Reproducer:
#!/bin/sh

set -e

max=200
for i in `seq 1 $max`
do
    echo "--------------$i test-------------"
    parsec-cli-tests.sh -d
    echo "--------------$i test done-------------"
done

We've investigated a bit and below is what we found.

The test_csr() case:

Full log with debug info when the case fails:
test_csr_fail_full.txt
Full log with debug info when the case passes:
test_csr_pass_full.txt
It looks like when the test case fails, the generated CSR below
-----BEGIN CERTIFICATE REQUEST-----
MIIBEzCBugIBADAxMRswGQYDVQQDDBJwYXJhbGxheHNlY29uZC5jb20xEjAQBgNV
BAUMCUVaNFUyQ0lYTDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABHqW3v6RNxNC
rq4aqQDXf/gUAKHe+MKRzwcaJWoWpt7+vJmNbZmToVfrCClM8epDHwA1U1q7gGYN
UtgVMXIGoCSgJzAlBgkqhkiG9w0BCQ4xGDAWMBQGA1UdEQQNMAuCCWxvY2FsaG9z
dDAKBggqhkjOPQQDAgNIADBFAiAAMbC74dHo2sHy9cizKtkjssaCsV1E4asBP6+r
TUqTYQIhAOPZEmPDeUq45f6KrHqhgZQw2HThIwhPVFAzxxFtPk6M
-----END CERTIFICATE REQUEST-----

is shorter than the passed CSR below:
-----BEGIN CERTIFICATE REQUEST-----
MIIBFDCBugIBADAxMRswGQYDVQQDDBJwYXJhbGxheHNlY29uZC5jb20xEjAQBgNV
BAUMCUVaNFUyQ0lYTDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABFKFxB9RJfvx
rQlb8rRIh1tPAK5yW6/ycXKJVpFFkkk43NNJpHUmUZKSagGBZPAKIItCDnnCMxLz
qBogAsYjfWugJzAlBgkqhkiG9w0BCQ4xGDAWMBQGA1UdEQQNMAuCCWxvY2FsaG9z
dDAKBggqhkjOPQQDAgNJADBGAiEA/GXlRImox5nNyLZY3g73SjWo5UoWrMuxEEXQ
YqgYeGYCIQCdDLos2E6HIWv/rk0lz0OwXjgS/86Lcd+MMC8Ff2C4tw==
-----END CERTIFICATE REQUEST-----

The test_signing() case:
Full log can be found below, and we suspect that maybe the issue is similar to the test_csr() case.
test_signing_fail_full.txt

May I please ask some helps from the parsec experts? Thanks very much!

Could you add more details please, so we can try to reproduce the issue:

parsec and parsec-tool versions
how parsec was built, manually or with Yocto recipes. If former then rust version, if latter then Yocto layers versions. Which providers were included when parsec was built. Which providers are configured in parsec config.
FVP version
how do you run FVP, manually or Yocto runfvp script? what FVP parameters do you use?
do you see failures for ECC keys only or for RSA keys as well?
how many failures do you see from the 200 runs?
do you see failures if you add a few seconds pause between the runs?
is the host where you run FVP is shared? can it be overloaded?


Stylus/SASS/Less styles

It would be great to have the src styles utilize a css preprocessor.

are the styles that complicated that we need something like scss?
On 10 April 2015 at 23:13, Tanner Linsley<EMAIL_ADDRESS>wrote:

It would be great to have the src styles utilize a css preprocessor.
—
Reply to this email directly or view it on GitHub
https://github.com/ceolter/angular-grid/issues/52.

--
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Statements and opinions expressed in this e-mail may not
represent those of the sender. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender immediately and delete
the material from any computer.

Not at all. I'm such a fan of lean styles. I'm just throwing out any optimizations that come to mind.

I've been thinking the same about implementing this for the CSS.
Firstly, it's not that the styles are particularly complicated, but providing/maintaining predefined themes will definitely be simplified with the use of a preprocessor since each would just become a set of variables setting the required colours, etc, rather than needing to duplicate each of the related rules.  This, in turn, means that the rules are only defined once, so updating them doesn't need each theme to be changed separately.
More significantly though, I think it would make it much easier for developers to integrate the grid into a project that uses SASS/LESS.  Currently, you must manually copy and edit the grid styles to match your project (a process that then has to be repeated whenever the grid's styles are changed).  With SASS/LESS, you don't care about the rules themselves - as long as all the significant values have been declared as variables, you will only need to update the variables to match.  Upgrading to a new version then just needs you to check what variables have been added/removed.
Of course, whichever one you go with, someone will want you to implement the other one.  But I think implementing both is overkill.  Personally, I've used both SASS and LESS, but prefer SASS, so will probably have a go at converting it anyway (though I'm no expert).  I'll be happy to provide a PR as a first attempt, if you're interested.

I use SASS (scss) in work, haven't used LESS. So I can't compare them, but
given I use SASS, that would be my preference. My reason for holding back
is I'm trying to minimise the complexity of the project. Although I use
SASS and am comfortable with it, not everyone is / does, so bringing in
another layer to the stack make the project less maintainable by some -
especially those who have arrived at JS development from traditional
application development (vs those who have come from creating websites).
Re the comments on style reuse - currently the styles are split into core
(always used) and theme (selected by user). So css styles that are part of
the operation of the grid are in core, so the themes don't need to be aware
off and repeat the core styling (not sure this is styling really, it's more
the skeleton layout of the grid). Was this what your were referring to as
the reusable parts?
If interested in the pull request, think Tanner has his eyes on this one!!!
But sure!! However it will be easier in a week or two when I get everything
moved over to git. Maybe my concern over 'making it difficult for non-css
people' can be eased by making sure we heavily inlne-comment the scss files
and extend the documentation to cover this.
On 11 April 2015 at 17:29, David Geary<EMAIL_ADDRESS>wrote:

I've been thinking the same about implementing this for the CSS.
Firstly, it's not that the styles are particularly complicated, but
providing/maintaining predefined themes will definitely be simplified with
the use of a preprocessor since each would just become a set of variables
setting the required colours, etc, rather than needing to duplicate each of
the related rules. This, in turn, means that the rules are only defined
once, so updating them doesn't need each theme to be changed separately.
More significantly though, I think it would make it much easier for
developers to integrate the grid into a project that uses SASS/LESS.
Currently, you must manually copy and edit the grid styles to match your
project (a process that then has to be repeated whenever the grid's styles
are changed). With SASS/LESS, you don't care about the rules themselves -
as long as all the significant values have been declared as variables, you
will only need to update the variables to match. Upgrading to a new version
then just needs you to check what variables have been added/removed.
Of course, whichever one you go with, someone will want you to implement
the other one. But I think implementing both is overkill. Personally, I've
used both SASS and LESS, but prefer SASS, so will probably have a go at
converting it anyway (though I'm no expert). I'll be happy to provide a PR
as a first attempt, if you're interested.
—
Reply to this email directly or view it on GitHub
https://github.com/ceolter/angular-grid/issues/52#issuecomment-91876235.

--
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Statements and opinions expressed in this e-mail may not
represent those of the sender. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender immediately and delete
the material from any computer.

I can appreciate your concerns about complexity.  I assumed you hadn't used SASS/LESS because you didn't want to introduce additional third-party dependencies, but I can understand the other implications for some people.  That said, using a pre-processor is almost a tacit best practice (and so many OS frameworks/components use one or the other anyway), so maybe it's no bad thing.  And you can still distribute the CSS files too.
Regarding style reuse, I was referring more generally, though I'm ambivalent about the split between 'core' and 'theme' styles; it's useful when you have to work with the CSS directly, so could be maintained, but is less relevant and more complex when working in SASS.
I think the way the themes are currently implemented should change anyway.  I'm not a fan of the practice of adding the theme name to a parent element of the grid since, for most projects, you'll only ever be using a single fixed theme.  The only advantages I can see it giving is making it easy to try out different themes by simply changing the parent's class (which you can do just as easily by changing the stylesheet name) or where you have multiple grids on a single page that need different styling.  OTOH, the disadvantage is that you increase the browser's processing of the CSS since every element's style requires a traversal up the DOM to see if a parent has the .ag-fresh (or whatever) class.
Anyway, I'm fine with letting @tannerlinsley take the lead if he's up for it (always happy to let someone else do work!)

I'd love to do some style optimization.  My plan of attack would be this:

I'll wait until we start using gulp to move it to a preprocessor.  The build process needs to change before we can go much further.
Rewrite all of the src styles using Stylus, as it tends to be pretty agnostic and easy to convert to other preprocessors. Since Sass and Less are more commonly used (for now), we can easily convert the source stylus files to those types on build.  The markup for any preprocessor is going to be so similar, I don't think anyone will have a problem contributing, as there are so few differences between the preprocessors anyway.  Easy use of the files, customization compatibility and the ability to contribute easily should remain the focus.

@tannerlinsley  is your suggesting for Stylus because you think it will take over from Sass and Less?

@davidgeary re different styles used concurrently - yes i have that requirement - in my current project we have many reports in the same platform, the reports can have different styles.

Proposed fix #72

Fixed by #72


Bug: bad schema for optional enums inside of named structs.

Hello,
I think I found a bug in Utoipa.
Up until 3.0, this was fine, but after updating to 3.1, we started to get this behavior.
But the bug is still present in current 4.2 utoipa.
What is happening?
Option<AnEnum> is generated as an allOf besides a "nullable": true property.
What I was expecting?
Option<AnEnum> generated a reference to AnEnum. The "nullable": true property should not be added.
How to reproduce it?
I created a tiny example that replicates the bug.
When the code bellow is run,
use utoipa::{OpenApi, ToSchema};

#[derive(ToSchema)]
enum AnEnum {
    A,
    B,
}

#[derive(ToSchema)]
struct ANamedStruct {
    the_enum_1: AnEnum,
    the_enum_2: Option<AnEnum>,
}

#[derive(OpenApi)]
#[openapi(components(schemas(ANamedStruct, AnEnum)))]
struct Api;

fn main() {
    println!("{}", Api::openapi().to_pretty_json().unwrap())
}

[dependencies]
utoipa = "4"

We get this:
{
  "openapi": "3.0.3",
  "info": {
    "title": "utoipa-flatten-fields-bug",
    "description": "",
    "license": {
      "name": ""
    },
    "version": "0.1.0"
  },
  "paths": {},
  "components": {
    "schemas": {
      "ANamedStruct": {
        "type": "object",
        "required": [
          "the_enum_1"
        ],
        "properties": {
          "the_enum_1": {
            "$ref": "#/components/schemas/AnEnum"
          },
          "the_enum_2": {
            "allOf": [
              {
                "$ref": "#/components/schemas/AnEnum"
              }
            ],
            "nullable": true
          }
        }
      },
      "AnEnum": {
        "type": "string",
        "enum": [
          "A",
          "B"
        ]
      }
    }
  }
}

The type of the_enum_2 is weird.
When I set the version of utoipa-gen to 3.0.x, the same example produces this:
[dependencies]
utoipa = "~3.0"
utoipa-gen = "~3.0"

{
  "openapi": "3.0.3",
  "info": {
    "title": "utoipa-flatten-fields-bug",
    "description": "",
    "contact": {
      "name": "",
      "email": ""
    },
    "license": {
      "name": ""
    },
    "version": "0.1.0"
  },
  "paths": {},
  "components": {
    "schemas": {
      "ANamedStruct": {
        "type": "object",
        "required": [
          "the_enum_1"
        ],
        "properties": {
          "the_enum_1": {
            "$ref": "#/components/schemas/AnEnum"
          },
          "the_enum_2": {
            "$ref": "#/components/schemas/AnEnum"
          }
        }
      },
      "AnEnum": {
        "type": "string",
        "enum": [
          "A",
          "B"
        ]
      }
    }
  }
}

I'm closing the issue because I've noted that there are a few other issues explaining that these changes were intended.


OpenSLO

Great tool, thanks! Can you share your thoughts around supporting OpenSLO please?

Hi @mhausenblas!
I was asked that question last week on Twitter, so I think that is something that people are interested in :)
tl;dr: I would love to!
Sloth at this moment is focused on a very easy spec (e.g: no custom time windows). However, OpenSLO has a lot of knobs (that not every people want or know how to set). So... I need to research a bit and see if I can map OpenSLO to the current Sloth generator implementation. If this can be done, what I was thinking, is supporting OpenSLO spec and support only the options types that Sloth supports (e.f 30d time windows, Prometheus...).
With time we would have more information and we could see what new features could Sloth support from the OpenSLO spec.
How does this sound?

would be cool to have you in the openslo slack, maybe we can brainstorm there how to make this work?

would be cool to have you in the openslo slack, maybe we can brainstorm there how to make this work?

That would be awesome! thanks.

Thanks so much @slok and that sounds like a great plan to me! As Kit suggested, maybe having a bit of an informal convo on Slack, to scope and set expectations right won't hurt ;)

@mhausenblas @kitmerker I've added initial support for OpenSLO :tada:, Any feedback is much appreciated!


TFLite v1.14.0 download_dependencies.sh is broken

OS Platform and Distribution (e.g., Linux Debian):
TensorFlow installed from (source or binary): github
TensorFlow version: v1.14.0
Installed using virtualenv? pip? conda?: docker tensorflow/tensorflow:nightly-devel

$ git clone https://github.com/tensorflow/tensorflow
Cloning into 'tensorflow'...
remote: Enumerating objects: 38, done.
remote: Counting objects: 100% (38/38), done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 668742 (delta 8), reused 29 (delta 1), pack-reused 668704
Receiving objects: 100% (668742/668742), 378.17 MiB | 28.86 MiB/s, done.
Resolving deltas: 100% (542405/542405), done.
Checking out files: 100% (20047/20047), done.
$ cd tensorflow/
$ git checkout v1.14.0
Checking out files: 100% (8943/8943), done.
Note: checking out 'v1.14.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 87989f6959 Add Sergii Khomenko to contributor list
$ ./tensorflow/lite/tools/make/download_dependencies.sh
downloading http://mirror.tensorflow.org/bitbucket.org/eigen/eigen/get/a0d250e79c79.tar.gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Oh. Yes. That would be https://www.tensorflow.org/lite/guide/build_rpi

Sadly building from HEAD is also broken (at least for rpi armv6).
See https://github.com/tensorflow/tensorflow/issues/32055#issuecomment-525857017

Also default (armv7l) rpi build is broken at HEAD: https://github.com/tensorflow/tensorflow/issues/32055#issuecomment-525862626

edit download_dependencies.sh, then change 'http.*bitbucket.org' to 'https.*bitbucket.org', It worked;


[MV-340] Add Create room screen

This PR introduces a proper screen that should be used for creating new rooms. Since the size of this change is pretty big, I decided that step 2/2 will be added in a separate PR.

 I think the background shouldn't be scrollable at all, just the content?
https://user-images.githubusercontent.com/6280457/226411435-0af06cda-265c-42c2-a484-2c620c547288.mp4

Also I don't like this behaviour: you can scroll past the blue background and see ugly white space. I think the background shouldn't be scrollable at all, just the content?

Yes, I didn't want to make the background scrollable, but without it the KeyboardAvoidingView was broken, and after some tweaking I found, that's the only configuration I made it working, do you have any ideas on why is that the case?


[cxx-interop] import static operator call from C++23 as member callAs…

…Function functions in Swift to preserve source compatibility

Explanation: Correct importing of operator ()() from C++ types into Swift.
Scope: This fixes a small C++ interop issue in the compiler which is required for use of std::hash on Windows.
Issue:
Risk: This is a pretty narrow change to how we handle static operator()() which was added in C++23. It impacts only the C++ interop path where this method is declared.
Testing: This has been on main for quite some time and we failed to bring it over for the release.
Reviewer: @egorzhdan @hyp @al45tair

@swift-ci please test

We should also cherry-pick a crash fix: https://github.com/swiftlang/swift/pull/76252

Brought those over along with this change so that we do not split them up.


[e2e]: generic push main default slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/3125161087
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Mon Sep 26 04:55:08 UTC 2022

privacy check blocked the workflow:
error_message: Repository is private. The workflow has halted in order to keep the repository name from being exposed in the public transparency log. Set 'private-repository' to override.
but the repo isn't private?

I think it's a transient API error (500). Maybe we should do retries or something...
HttpError: Server Error
    at /home/runner/work/_actions/slsa-framework/slsa-github-generator/a3c7a56c8749c2c423f01bbcfd063315efc07a22/.github/actions/privacy-check/webpack:/privacy-check/node_modules/@octokit/request/dist-node/index.js:86:1
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

#914

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/3132950487
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Tue Sep 27 04:37:18 UTC 2022
Tests are passing now. Closing this issue.


update readme

Issue #652
updated readme to include minor changes to improve quality.
Changes
command line -> command-line
a Node.js package -> an npm(Node.js Package Manager) package
Node.js package manager -> npm
Signed-off-by: Parikshit-Hooda<EMAIL_ADDRESS>

Coverage remained the same at 99.584% when pulling 80d6063a906f678687d4b7c54efdd1c9b71bbd7f on perry-contribs:master into 9e216d86c87c6b67f640e7982f0e639a792e6207 on accordproject:master.


[SPARK-27653][SQL] Add max_by() and min_by() SQL aggregate functions

What changes were proposed in this pull request?
This PR goes to add max_by() and min_by() SQL aggregate functions.
Quoting from the Presto docs

max_by(x, y) → [same as x]
Returns the value of x associated with the maximum value of y over all input values.

min_by() works similarly.
How was this patch tested?
Added tests.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10538/
Test PASSed.

Test build #105258 has started for PR 24557 at commit 5c7e3c5.

Hi @viirya,
Thanks for working on this!
I had a few quick questions:

Could you also implement min_by(x, y)?

It looks like you might be able to share most of the code except for replacing GreaterThan and greatest, so maybe this difference could be abstracted away via a shared abstract superclass.

Presto also has three-argument versions of max_by / min_by:

max_by(x, y, n) → array<[same as x]>
Returns n values of x associated with the n largest of all input values of y in descending order of y.

I don't think we need to do this version now, especially since we can always add it in a separate followup PR (which is what Presto originally did: https://github.com/prestodb/presto/issues/3620)

Were there any bugs in older implementations of Presto version that we might have replicated here? Or Presto tests for edge-cases that we could emulate?

https://github.com/prestodb/presto/issues/7646 discusses using rows / structs as the ordering value. I suspect that would work already in your implementation, but it might be nice to check.
https://github.com/prestodb/presto/issues/2040 discusses a problem with null ordering values. It looks like you're testing that case, but I just wanted to double-check that we've covered the same edge-case there.

Test build #105258 has finished for PR 24557 at commit 5c7e3c5.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class MaxBy(valueExpr: Expression, maxExpr: Expression) extends DeclarativeAggregate

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/105258/
Test PASSed.

@JoshRosen Thanks for the review!

Could you also implement min_by(x, y)?
Yes. I originally planed to have separate PR for it. I'm fine to add it here.  A shared abstract superclass to share code is good.

Presto also has three-argument versions of max_by / min_by:
Agreed. We don't need three-argument versions now. If we need it, we can add it in a followup.

Were there any bugs in older implementations of Presto version that we might have replicated here? Or Presto tests for edge-cases that we could emulate?

For using rows / structs as the ordering value, I also think it would work. I will add few tests.
For null ordering values, I already have few test cases. I checked Presto's results and they are matched. Let me see double-check if we've covered the same edge-case.

I've checked few test cases regarding null values in Presto:
presto> select max_by(x, y) from ( values ('a', null), ('b', null), ('c', null) ) as t (x, y);
 _col0
-------
 NULL
(1 row)

Query 20190509_050643_00001_ww5mk, FINISHED, 1 node
Splits: 1 total, 1 done (100.00%)
0:02 [0 rows, 0B] [0 rows/s, 0B/s]

presto> select max_by(x, y) from ( values ('a', null), ('b', null), ('c', 10) ) as t (x, y);
 _col0
-------
 c
(1 row)

Query 20190509_050655_00002_ww5mk, FINISHED, 1 node
Splits: 1 total, 1 done (100.00%)
0:00 [0 rows, 0B] [0 rows/s, 0B/s]

The results match the added test cases here.
About prestodb/presto#2040, it is happened by null reference for the key field in Presto. This shouldn't be in our case.

Merged build finished. Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10562/
Test PASSed.

Test build #105286 has started for PR 24557 at commit 798f0fa.

Test build #105286 has finished for PR 24557 at commit 798f0fa.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/105286/
Test PASSed.

cc @cloud-fan @dongjoon-hyun

Test build #105329 has started for PR 24557 at commit 26b5a32.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10601/
Test PASSed.

Test build #105329 has finished for PR 24557 at commit 26b5a32.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/105329/
Test PASSed.

LGTM except a few code style comments

Note that we don't add them into functions, currently. If needed, we can add it in a followup in the future.

Note that we don't add them into functions, currently. If needed, we can add it in a followup in the future.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10617/
Test PASSed.

Test build #105349 has started for PR 24557 at commit dd1d9de.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10618/
Test PASSed.

Test build #105350 has started for PR 24557 at commit 05f1767.

Test build #105349 has finished for PR 24557 at commit dd1d9de.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/105349/
Test PASSed.

Test build #105350 has finished for PR 24557 at commit 05f1767.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/105350/
Test PASSed.

thanks, merging to master!


Scanning a QR with payment id and amount

When a QR code has a payment ID and/or amount, they are added to the end of the payment address rather than being put into the proper fields.

Thanks. Yeah, we are not parse additional info and as you said if exist additional fields it's parsing wrong.

Fixed it in release-1.0.2 branch. Please test it and write feedback if you've time for it.

Works now. thanks!


Game save on host doesn't work

Save file is created but it contains the state of the previous save.
"Save as" does work tho.

@polycone I can not reproduce it.
Could you check it on the last main?

Seems like it was fixed somewhere, nice.


Fix for Android chip-tool build issue (#27284)

Fixes https://github.com/project-chip/connectedhomeip/issues/27284
This commit solves the above build issue of Android chip-tool project.

@satyajitanand this seems to break linux builds - I believe these options were added to make error strings not contain developer-specific paths.

Closing: I don't think a code change is needed, a documentation change may be needed instead.


[flutter_tools] fix null check in crash reporter

The crash reporter is currently broken, it will crash while trying to report a crash. We need a test for this. Perhaps some way to force the flutter_tool to produce a crash report?
Fixes https://github.com/flutter/flutter/issues/80383

This broke in  https://github.com/flutter/flutter/commit/8ddc27e6077b0ce66e19d7d489a327f41d974f7d which is unfortunately in the latest RC so we'll need to cherry pick.

for testing, can we add a method that always throws with @visibleForTesting?

I added a flag to update-packages, since that is really only a command for contributors and is already hidden. This allows us to simulate a crash with as few differences as possible between the test environment and IRL.

Actual output is missing the Oops
  Expected: contains 'Oops; flutter has exited unexpectedly: "Bad state: test crash please ignore.".\n'
              'A crash report has been written to'
    Actual: '\n'
              'Bad state: test crash please ignore.\n'

Ahh, the oops is stdout

err, maybe its a terminal versus no terminal thing

g3 failure seems unrelated so I'll land on green.


background: inherit expansion

A user on my site (http://refresh-sf.com) noticed that when minifying a class with background: inherit it is expanded to cover all background properties
div{background:inherit;} -> div{background:inherit inherit/inherit inherit inherit inherit}
I wanted to see if this was intentional or not?

Oh, it's definitely not. Good catch!

Same problem here.

It's fixed in 3.3-pre master. I'm considering backporting it to 3.2 too.

Thank you kind sir. :+1:


sync pkg test

Please provide a description of this PR:
fixes: https://github.com/istio/istio/issues/44991
sync changes from https://github.com/istio/pkg/pull/813
cc @howardjohn

@zirain: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
b02cd8592791c67c7e237e238b3f366c2ebf7947
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@zirain: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
b02cd8592791c67c7e237e238b3f366c2ebf7947
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest
flake unrelated, will investigate


CVE 2010 1230 and CVE 2015 1226

The second CVE is not done yet and I don't want to give you guys the half completed CVE.
2010 1230 investigation should be complete.

There were no VCC's for the issue. It was a development omission, not a issue that anyone created.

Same thing with interesting commits. Nothing interesting about them. Simple fixes all.

Currently working on trying to get the yaml syntax correct. Apparently the output is giving me the .rb script errors, so it isn't telling me where the yaml syntax error is located. Working on trying to fix it.

So I got to the point that I only get two errors, one per file, both with vccs. I couldn't figure out the format in time (and that's what I spent the majority of my time on). Otherwise, the syntax should be good and the actual research should be complete.


required options should be arguments

Description
The syntax on many commands require a group but make it an option rather than an argument.
$ az group delete -h | tail -n 5
Examples
    Delete a resource group.
        az group delete -n MyResourceGroup

Why isn't that?
$ az group delete MyResourceGroup

Environment summary
Install Method: How did you install the CLI? snap
CLI Version: What version of the CLI and modules are installed? (Use az --version)
Answer here: 2.0.7
OS Version: What OS and version are you using?
Answer here: Ubuntu
Shell Type: What shell are you using? (e.g. bash, cmd.exe, Bash on Windows)
Answer here: bash

As of now, we do not support the positional argument. The positional argument can cause confusion with multiple levels of subcommand.
Thank you for the feedback.


Fixes to the CategoricalDeckGLContainer and filter box

This PR fixes a few bugs with the CategoricalDeckGLContainer and the filter box:

When the filter box dropdown is not a multi-select (like the time grain selector, where only a single value can be selected), selectedValues[key] is not an array, like the code currently assumes. I added logic to handle this.
When running the time slider, the payload.data was being filtered inplace for each time step, becoming empty after the first one. I changed the logic so we create a copy of the payload and pass that to getLayer instead.
The categories on the legend are computed from the props, and were being reset at every interaction. I changed the logic so state.categories is preserved when props change. Not sure if this is the best way to do this. (@kristw, @xtinec?)

LGTM


Caused by: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=zOS and os.arch=s390x

Hi Team,
I am using version <IP_ADDRESS> of 'snappy-java' and getting below error:
Caused by: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=zOS and os.arch=s390x
JVM version::
IBM J9 VM (build 2.9, JRE 1.8.0 z/OS s390x-64-Bit Compressed References 20190124_408237 (JIT enabled, AOT enabled)

snappy-java currently does not have a native binary for zOS/s390x.  I contributed the binary for Linux/s390x, but I do not have access to zOS now.  Let me poke around....

@odaira Did you find anything or any ETA, we have install around next month that requires this change

@sunz21sunz Would you have any contact in IBM on your deal? If the deadline is critical, I would reach out to the contact if any.  I'm working for snappy-java on a voluntary basis, so I'll try, but I cannot commit myself to any schedule.
By the way, I've got access to a zOS instance. It has nothing installed, so I'll start with installing git.

Another idea is adding a fallback to pure-scala Snappy (like aircompressor) if no native library is found.

@xerial do you have any benchmarks for a pure-java implementation vs this one?

@odaira you can get access to a free LinuxOne (Linux on Z) environment in two ways.

The Marist College Linux One Community CLoud https://linuxone.cloud.marist.edu/cloud/#/login
The HyperProtect Virtual Server (Free tier) on the IBM public Cloud https://cloud.ibm.com

Good luck

Added a fallback to pure-java snappy implementation in #244 and this is available since snappy-java 1.1.76

@xerial , the fallback that you implemented in #244 that is based on aircompressor doesn't support BIGENDIAN platforms
static {
        ByteOrder order = ByteOrder.nativeOrder();
        if (!order.equals(ByteOrder.LITTLE_ENDIAN)) {
            throw new SnappyError(SnappyErrorCode.UNSUPPORTED_PLATFORM, format("pure-java snappy requires a little endian platform (found %s)", order));
        }

I came here to report the bug, but @n-marion beat me :)
If run on Z/OS Unix shell with snappy-java <IP_ADDRESS>, and use pure-java option on command line :
Exception in thread "main" org.xerial.snappy.SnappyError: [UNSUPPORTED_PLATFORM] pure-java snappy requires a little endian platform (found BIG_ENDIAN)
at org.xerial.snappy.pure.UnsafeUtil.(UnsafeUtil.java:38)
at org.xerial.snappy.pure.SnappyRawCompressor.writeUncompressedLength(SnappyRawCompressor.java:383)
at org.xerial.snappy.pure.SnappyRawCompressor.compress(SnappyRawCompressor.java:89)
at org.xerial.snappy.pure.PureJavaSnappy.rawCompress(PureJavaSnappy.java:102)
at org.xerial.snappy.Snappy.rawCompress(Snappy.java:424)
at org.xerial.snappy.Snappy.compress(Snappy.java:105)
at com.equifax.usis.acro.Main.main(Main.java:12)
I really want to use snappy compression within Avro, but this LITTLE_ENDIAN bug in aircompressor is preventing us.
[(https://github.com/airlift/aircompressor/blob/master/src/main/java/io/airlift/compress/snappy/UnsafeUtil.java)]
Specifically, it seems that these lines should be deleted. (I don't know if something else has to change, but I would think the JVM should handle the pointer to long conversion internally)
ByteOrder order = ByteOrder.nativeOrder();
if (!order.equals(ByteOrder.LITTLE_ENDIAN)) {
throw new IncompatibleJvmException(format("Snappy requires a little endian platform (found %s)", order));
}

It's not a bug, rather big-endian architecture is not supported in the pure-java fallback version. To use zOS, s390x we need to add a native library for this.
If https://github.com/dockcross/dockcross supports cross-compilation for zOS/s390s, it's the ideal way to support zOS in snappy java because the build is reproducible, and we don't need to ask IBM team members like @odaira to rebuild native libraries.

I only referred to it as a bug in pure-java, as it seems the only reason why big endian isn't supported is because there was no effort to reverse the byte order to allow it to work. ie It doesn't seem to be something that is completely unresolvable
This link has examples of methods that could be leveraged to provide the big endian functionality
[]http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.04/raw_files/new/src/share/classes/sun/security/provider/ByteArrayAccess.java

Personally I don't have time for working on big-endian support by checking every detail of the compressor/decompressor implementation (e.g., where byte order matters).
If there is a docker image of g++ cross compiler for zOS, I'd be happy to included it as a part of the build process of snappy-java. Otherwise, I need to wait for contributions from open source community.

This link seems to mention a docker image for cross compile of gcc to Z/OS platform (at bottom of blog). [https://blog.the-leviathan.ch/?p=1344]
My company blocks the link, so I am unable to validate.
In the meantime, I might play around with Pure Java and try to get a local version that for Big Endian, does the reversebytes alternative that seems to be needed around every UNSAFE.getXXX() or UNSAFE.putxxx invocation

You should be able to test this on Linux on Z... which you can get a VM on
the Marist College LInuxOne Community Cloud here:
https://developer.ibm.com/components/ibm-linuxone/gettingstarted/
On Tue, Aug 25, 2020 at 12:26 PM kiwi1969<EMAIL_ADDRESS>wrote:

This link seems to mention a docker image for cross compile of gcc to Z/OS
platform (at bottom of blog). [https://blog.the-leviathan.ch/?p=1344]
My company blocks the link, so I am unable to validate.
In the meantime, I might play around with Pure Java and try to get a local
version that for Big Endian, does the reversebytes alternative that seems
to be needed around every UNSAFE.getXXX() or UNSAFE.putxxx invocation
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/xerial/snappy-java/issues/232#issuecomment-680130875,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHJIVXR2AVESFQLKY55OEDSCPQZTANCNFSM4I7CYR3A
.

--
I/T Architect

@fosslou  - I am using Z/OS native, not ZLinux.
So far I have a version of libsnappy.so natively compiled on z/os using c89, without any GNU tools, based upon snappy.c implementation here: [https://github.com/yitzikc/snappy-c]. I am yet to add the JNI stubs to allow JNI to work.
I am not sure if this actually works properly yet, or if it is 100% compatible with dll that snappy-java uses, so I am thinking I may be better off (and perhaps easier) to attempting an update to pure-java for big endian.

libsnappy.so won't work as snappy-java needs its own extension (libsnappyjava.so). Running make native is the basic step to create snappy-java that should work at your target machine.
https://github.com/xerial/snappy-java/blob/master/Makefile#L143

I successfully have updated snappy.purejava to work on both little and Big Endian, by providing new methods, instead of directly using UNSAFE.getXXX methods for short, int,long datatypes.
ie Initial testing looks good.
I would like to note, that the 'fallback' doesn't actually occur when JNI DLL is being found. I can only get the pure java implementation to run my forcing it on the command line
See below
java -cp "SnappyTest.jar:lib/*" com.equifax.usis.acro.Main
Exception in thread "main" org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=zOS and os.arch=s390x
	at org.xerial.snappy.SnappyLoader.findNativeLibrary(SnappyLoader.java:361)
	at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:195)
	at org.xerial.snappy.SnappyLoader.loadSnappyApi(SnappyLoader.java:167)
	at org.xerial.snappy.Snappy.init(Snappy.java:69)
	at org.xerial.snappy.Snappy.<clinit>(Snappy.java:46)
	at com.equifax.usis.acro.Main.main(Main.java:12)

java -Dorg.xerial.snappy.purejava=true -cp "SnappyTest.jar:lib/*" com.equifax.usis.acro.Main
Hello snappy-java! Snappy-java is a JNI-based wrapper of Snappy, a fast compresser/decompresser.
Original size = 96
Compressed size = 87
Uncompressed size = 96

My work won't let me attach to your Git repository from this PC, so I will have to find a work around...

I managed to create own fork of this project, apply my changes, and submit a pull request for this project to merge in changes from my fork : https://github.com/xerial/snappy-java/pull/254
Hoping this will solve this issue for systems without DLL for native Java (and usually do not have GNU toolsets etc in order to produce it themselves). They will just have to specify "-Dorg.xerial.snappy.purejava=true" to select pure Java.


<class 'websockets.py35.server.Serve'> breaks documentation and API

https://websockets.readthedocs.io/en/stable/api.html#websockets.server.serve
This link states that websockets.serve() returns a WebSocketServer, however it returns a Serve wrapper with self.server as the actual WebSocketServer
https://github.com/aaugustin/websockets/blob/master/websockets/py35/server.py#L9

It seems (untested) like this would be solved if the __aenter__() and __aexit__() methods were put directly on WebSocketServer instead of creating a new wrapper class.

I am gonna check that out

I checked the solution from @cjerdonek, it looks like async with syntax expects __aenter__() and __aexit__() on serve, not on WebSocketServer returned by serve.

I don’t think that makes sense because serve is  a function, and that’s not
how it currently works. It just needs to be on the object returned by the
function (which can be a WebSocketServer object instead of an object with
type the Server wrapper class).
On Wed, Oct 18, 2017 at 10:39 PM Dmitry<EMAIL_ADDRESS>wrote:

I checked the solution from @cjerdonek https://github.com/cjerdonek, it
looks like async with syntax expects aenter() and aexit() on serve,
not on WebSocketServer returned by serve.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aaugustin/websockets/issues/291#issuecomment-337804856,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVt7kxbfKXBILQVAeiFisj9Qmhpr9ahks5stuB7gaJpZM4P-Fyp
.

@cjerdonek serve is a coroutine and that is why it cannot pass back WebSocketServer without being await'ed first.

On second thought, it doesn't seem like there's a bug here at all.
When the documentation says serve() "returns a WebSocketServer object," that implicitly means after awaiting. The OP is getting a Serve object because the function isn't being awaited. This isn't unique to the "py35" code path. In Python < 3.5, you won't get a WebSocketServer object either if you don't await. You'll get a "serve generator object" (i.e. generator-based coroutine).
Perhaps what can be improved in the docs is to say that serve() is a coroutine. This is partly an issue with the Sphinx formatting of coroutines. There's been various discussion about how to format coroutines in Python docs. For example, here's the start of one thread:
https://mail.python.org/pipermail/async-sig/2017-June/000316.html

Also, just for comparison, if you look at the create_server() docs (which serve() wraps and which the serve() docs link to), you'll see that it says create_server() "Return[s] a Server object," even though you need to await to get that returned object.

The issue that @SlightlyCyborg shared is about inconsistent behaviour of serve function, in case you use it as asynchronous context manager it returns websockets.py35.server. Serve wrapper instead of WebSocketServer object that you expect. When you use it directly (not though asynchronous context manager) it returns WebSocketServer object as expected.

It returns a WebSocketServer in both cases when I test:
async def run():
    server = await websockets.serve(lambda ws, uri: None, '<IP_ADDRESS>', 8001)
    print(f'awaiting directly: {server!r}')
    server.close()

    async with websockets.serve(lambda ws, uri: None, '<IP_ADDRESS>', 8001) as server:
        print(f'from context manager: {server!r}')

# Outputs:
awaiting directly: <websockets.server.WebSocketServer object at 0x10c088d68>
from context manager: <websockets.server.WebSocketServer object at 0x10c088b00>

This is also evident if you look at the __aenter__() and __await__() methods of the Serve class here:
https://github.com/aaugustin/websockets/blob/master/websockets/py35/server.py#L11

Yes, I tested it again and I see the same results. I agree with you that it not looks like an issue because WebSocketServer object is returned after await from coroutine.

I do have the feeling that the whole wrapping of serve(), etc. can be made simpler. A couple thoughts are--

Serve.server is currently being used to store two different things at two different times (one during __init__() and one during __aenter__()). They should probably be different attributes.
It seems like the Serve class could be moved to the main server.py and the serve() function could go through Serve for all Python versions. This would create a single code path without the need for wrapping. For Python versions below 3.5, they can simply not recognize the __aenter__() and __aexit__() methods. This is just an untested thought though, so maybe there is a reason this can't be done that I'm overlooking.

I wrote up a PR (#294) that implements what I described in my above comment.
That PR doesn't close this issue though, because I would consider the current issue a documentation one (see my comment here on that).

Closing in favor of #294 and #295, which appear to cover the outcomes of this discussion. Thanks!

That sounds good. My only suggestion is that in addition to #294 and #295, serve() should still in the short term be documented as being a coroutine. That doesn't seem to be currently stated, which may have caused confusion leading to this issue.

I made that change in 2c0b6618a71453cf1ff39a3bf769081a25475aaf.


[HB] Create a category for weight loss

Create a category for weight loss contain these sub categories:
Weight Loss Supplements
Weight Loss Meal Replacement Products
Weight Loss Detox & Cleanse Products

@ornanatan we're missing the following dist files, let me try locally while I rebase:

dist/en/integrations/all_mappings.json
dist/en/integrations/google/shopify_2025-01_to_google_2021-09-21.json
dist/en/integrations/google/shopify_2025-01_to_google_2021-09-21.txt


Git: file opened from index needs a better tab title

Steps to Reproduce:

have a staged new file
open it

=> it looks like any other file and needs a better label imho

In stable:

I have no control over this through the API.
But IMO this is exactly the same as #19627. That URI should be distinguished in the tab control because it has a git: scheme.

Yeah I think that is possible. But we should also think about API to provide label/description explicitly via options. We need to collect all these things and just provide options to showTextDocument.

I would love to be able to control the tab title for a document in GitLens as well -- for the same thing - context about the opened file/virtual file.

To keep the number of issues in our inbox on a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: We look at the number of votes the issue has received and the number of duplicates issues filed.
Thanks for your understanding. Happy coding!


Replace sh with bash (fix #39)

As mentioned in #39, we could just get rid of -o pipefail and just use set -e. set -e should be available for every sh.

Closing this in favor of removing pipefail. If there are more problems we can consider reopening. Thanks anyway @e-kwsm!


Refactoring extraction methods leads to naming conflicts

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.87.2
OS Version: Windows11
-Language：java
Steps to Reproduce:

select "extracted();'
click “Refacator-Extract to method”
new method name " extractedMethod() "

class ExtractMethodTest {
public  void originalMethod() {};
public void methodA() {
// Extracted method
extracted();
}
private void extracted() {
extractedMethod();
}
private void extractedMethod() {
// TODO Auto-generated method stub
}
public void methodB() {
extracted();
}
}
refactoring result:

Reason: When extracting the method, there was no detection of naming conflicts between the new method name and the context
Expected behavior: Check for naming conflicts before and after refactoring, and provide warning prompts

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.88.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

/extJava

It looks like this is caused by the Java extension. Please file the issue to the Java extension repository. Make sure to check their troubleshooting instructions and provide relevant information such as the extension version you're using. See also our issue reporting guidelines for more information.
Happy Coding!


Added "Hybrid Cryptography" to article

Added and defined Hybrid Cryptography

[ 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 ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.


README links are broken

The links to cnn_lstm.py and lstm_encoder.py in the README are broken. They currently point to https://github.com/facebookresearch/multimodal/blob/main/torchmultimodal/models/cnn_lstm.py
and
https://github.com/facebookresearch/multimodal/blob/main/torchmultimodal/modules/encoders/lstm_encoder.py
but I guess they're meant to point to
https://github.com/facebookresearch/multimodal/blob/main/examples/cnn_lstm/cnn_lstm.py
and
https://github.com/facebookresearch/multimodal/blob/main/examples/cnn_lstm/lstm_encoder.py
?
Thanks!

You’re right, thanks for pointing this out. They should point to the examples folder. Feel free to submit a pull request, or I can take care of it soon.


docs: Update casing from Webpack to webpack

Following discussion in https://github.com/vercel/next.js/pull/45560

Current dependencies on/for this PR:

main

PR #3651

PR #3655   👈

This comment was auto-generated by Graphite.


How can I disable Ripple ?

I don't want to show effect Ripple. How can I turn off it?. I already set opacity of this to 0 but it still take some time to show modal.

Facing the same issue, is there way to turn off the ripple?

Facing the same issue, is there a way to turn them off?


Switch GRPC and WEB start sequence

What changes are proposed in this pull request?
Switching GRPC and WEB start sequence.
Why are the changes needed?
In my tests I found that grpc starts quickly (about 1s) but the web service takes about 15s. Switching the order can make GRPC  accept the request earlier but the impact on the web service is minimal when from follower to leader,
Does this PR introduce any user facing changes?
no user facing changes.

Codecov Report

Merging #13781 (c7cc75c) into master (3f73cf9) will decrease coverage by 17.05%.
The diff coverage is 100.00%.

@@              Coverage Diff              @@
##             master   #13781       +/-   ##
=============================================
- Coverage     34.60%   17.55%   -17.06%
+ Complexity     6956     2674     -4282
=============================================
  Files          1384     1385        +1
  Lines         80346    80481      +135
  Branches       9777     9801       +24
=============================================
- Hits          27804    14125    -13679
- Misses        50145    65109    +14964
+ Partials       2397     1247     -1150

Impacted Files
Coverage Δ

...main/java/alluxio/master/AlluxioMasterProcess.java
67.40% <100.00%> (ø)

...mon/src/main/java/alluxio/shell/CommandReturn.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mon/src/main/java/alluxio/util/ExceptionUtils.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/src/main/java/alluxio/wire/AlluxioProxyInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../src/main/java/alluxio/wire/AlluxioMasterInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...src/main/java/alluxio/job/meta/JobIdGenerator.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/src/main/java/alluxio/stress/BaseParameters.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...src/main/java/alluxio/client/UnderStorageType.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...main/java/alluxio/underfs/options/ListOptions.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...main/java/alluxio/worker/block/io/BlockReader.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 492 more

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 3f73cf9...c7cc75c. Read the comment docs.

alluxio-bot, merge this please


Move the equality and diversity survey onto the application form

Context
After the candidate has reviewed their application form and is happy to submit it we present them with the E&D survey. With the current flow this journey makes sense, since submitting an application is an infrequent activity. With continuous applications submitting an application will happen multiple times per recruitment cycle for the majority of candidates; therefore we should include E&D within the application details section so that it’s filled out once (and is editable).
Changes proposed in this pull request

Before
After

Guidance to review
Walk through the candidate journey for a fresh and existing app. Also try carrying over an application. Does it all make sense?
Link to Trello card
https://trello.com/c/HBUslouw/1512-ca-move-the-ed-survey-onto-the-application-form
Things to check

[ ] If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
[ ] This code does not rely on migrations in the same Pull Request
[ ] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[ ] If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
[ ] API release notes have been updated if necessary
[ ] If it adds a significant user-facing change, is it documented in the CHANGELOG?
[ ] Required environment variables have been updated added to the Azure KeyVault

Looks good just some missing content changes:

Above each question we changed the content under each H1 for 'Sex', 'Disabilities and health conditions' and 'Ethnicity'. It should say:

'We ask this question to prevent discrimination in teacher recruitment.
Training providers will not see your answer when deciding to offer you a place. They'll only see your answer if you accept an offer from them.'

2. The Free school meals question is missing at the end of the flow and in the summary list?

There's an additional line under the Disability heading about for additional support, are we planning to remove this with the new content ?

The free school meals should also appear unless it is for an international candidate and/or a candidate born before September 1964. Can you double check the candidate account you were using on the review app and then lmk!


feat: [OPS-26952]: Cleanup duplicate labels on helm chart

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


default is inverted now, also the invertion function was wrong

tested on raspberry pi 2 with kernel from github/raspberrypi/firmware

Does this require appropriate hardware to test?

That is the question. I am running Ubuntu Linux armhf branch on an RPI 2 with a USB mouse, using the evdev input driver in Kivy. If you connect a USB mouse via evdev to Kivy on any other Linux installation I would expect the same behaviour and result - but who knows?

@fscz thanks.


feat: upgrade suppression system

Closes #405
Closes #411

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

The important files to look at in this PR are

nag-pack.ts (formerly common.ts) validating both technically and that the logged messages are clear
nag-suppressions.ts validating both technically and that the logged messages are clear
Engine.test.ts to ensure proper coverage
README making sure that the new and updated examples are clear


Reason for no YAML output options?

I realize that part of the motivation for this project was to avoid YAML when possible.
I'm looking at potentially building a Sonobuoy plugin using isopod mainly for the convenient kube.* methods. However, there are times I'd like to be able to compare objects in their yaml form or print the raw yaml.
I see there is a "json" option instead of the protobuf default, why not also YAML? Trying to understand if it was a technical reason or not.

Duplicate of https://github.com/cruise-automation/isopod/issues/62.
Have you tried print(yaml.marshal(my_obj))?

Oh great, thanks. I see now it is part of your predeclared modules.
Thanks for the snippet too.


chore(analyzer): Use permalinks in the error for duplicate projects

This makes links valid / clickable to directly inspect the source.

Merging despite the unrelated funTest-docker failure.


Changed labels in DC Deployment Wizard

Simple label change in the Azure Arc Data Controller deployment wizard to match the labels in Portal.

Administrator Account --> Metrics and Logs Dashboard Credentials
Login --> Username
Added descriptions to Login and Password

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 41.713%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
27330

Relevant Lines:
59439

💛  - Coveralls


Audio and video capture

It would be nice to be able to capture audio / video or both from the device.
Could be configurable via a ICaptureSettings interface.
CrossMedia.CaptureAudio(audioCaptureSettings)
CrossMedia.CaptureVideo(videoCaptureSettings)

+1


fix: Issue when edittext is empty and send is clicked

Fixes #203
Changes:

Added a Check before sending to check if it is empty

@mariobehling @yashk2000 @iamareebjamal Review

@adityastic sorry. I had opened this issue and forgot about it. Will not do so again.

@yashk2000 no worries. I took care of it xD


[10.x] Adds Lang::whenMissingTranslation

The original suggestion for this pull request came from https://github.com/laravel/framework/pull/47001. It enables users to report missing translations in their applications in the manner they prefer:
use Illuminate\Support\Facades\Lang;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        Lang::whenMissingTranslation(fn ($key) => logger('Missing translation', ['key' => $key]));
    }
}

Can use a community package like: https://github.com/LarsWiegers/laravel-translations-checker

@taylorotwell That does not work for translation keys that are concatenated/generated dynamically.

To clarify, let me explain our situation:

Many notifications in our app all follow the same structure (header, body, button).
Therefore, we didn't really want to maintain many very similar markdown/Blade templates.
We created a base notification class with one Blade template
Every notification extends that base class, and translation keys are generated dynamically based on the class name
However, sometimes translation keys get missing (complex setup with Localazy and PRs/merges, multiple team members, not easy fix)
Users get sent notifications without translations = full of translation keys
We would like to get alerted immediately in case any notification goes wrong


Undefined variable dataType

Laravel Version: 5.6.*
Voyager Version: dev-1.x-dev
PHP Version: 7.2.0 on Ubuntu 16.04 (Laravel Homestead) running on WIndows 10
Database Driver & Version: MySQL 5.7.21

Description:
I wanted to create a relationship from BREAD section, using Voyager of course. Teachers table got user_id as foreign constraint that references id on users tab.e (ran through migration). Now when, I try creating  BREAD from Voyager, I get error like this:
ErrorException (E_NOTICE)
Undefined variable: dataType.
Its in line #220 on vendor/tcg/voyager/src/Http/Controllers/VoyagerBreadController.php. As i inspected the code, the given variable was not declared.

Steps To Reproduce:
I think we need to declare the var first.

This is known, see https://github.com/the-control-group/voyager/issues/2735
And it will be fixed in https://github.com/the-control-group/voyager/pull/2757


GoogleDataTransport version conflict with firebase_crashlytics

For anyone that requests updates on this issue, the mobile_scanner plugin cannot resolve this until there is a new release listed in https://developers.google.com/ml-kit/release-notes#ios-api-latest-versions that updates MLKit dependencies
After update firebase_* packages ios build was broken.

Pod error log
[!] CocoaPods could not find compatible versions for pod "GoogleDataTransport":
  In Podfile:
    firebase_crashlytics (from '.symlinks/plugins/firebase_crashlytics/ios') was resolved to 4.1.0, which depends on
      Firebase/Crashlytics (= 11.0.0) was resolved to 11.0.0, which depends on
        FirebaseCrashlytics (~> 11.0.0) was resolved to 11.0.0, which depends on
          GoogleDataTransport (~> 10.0)

    mobile_scanner (from '.symlinks/plugins/mobile_scanner/ios') was resolved to 5.2.1, which depends on
      GoogleMLKit/BarcodeScanning (~> 6.0.0) was resolved to 6.0.0, which depends on
        MLKitBarcodeScanning (~> 5.0.0) was resolved to 5.0.0, which depends on
          MLKitCommon (~> 11.0) was resolved to 11.0.0, which depends on
            GoogleDataTransport (< 10.0, >= 9.4.1)

We already depend on the latest version of GoogleMLKit/BarcodeScanning. You will have to raise an issue on their issue tracker to request an update.
See https://developers.google.com/ml-kit/release-notes#ios-api-latest-versions and https://github.com/juliansteenbakker/mobile_scanner/blob/master/ios/mobile_scanner.podspec#L18C17-L18C44

I have opened an issue with GoogleMLKit for this issue: https://issuetracker.google.com/issues/362452861

Thanks!

Again priority P4 on googles side... :-(

Same conflict with firebase_messaging

+1

For a temporary fix I set old versions firebase_* packages. I use versions before fix
bump all iOS deployment targets to iOS 13 ahead of Firebase iOS SDK v11 breaking change (#12872). (de0cea2c)

For example
  firebase_core: ^2.32.0
  firebase_crashlytics: ^3.5.7
  firebase_messaging: ^14.9.4
  firebase_performance: ^0.9.4+7

For now this works for me...
Override Firebase SDK Version
$FirebaseSDKVersion = '10.29.0'

Any updates?

@Mo0Khaled I cannot provide any updates, since MLKit is not developed by us, but by Google.

63 requests and still just P4 on googles side 🤦♂🤨

+1 on https://github.com/juliansteenbakker/mobile_scanner/issues/1165#issuecomment-2313227415

They too much occupied by killing Flutter by themselves by creating new cross-platform "framework" instead of updating current libraries to keep flutter alive... 😢
PS: It's a joke, and i'm still waiting for this update too

The Flutter team is not the same team as the MLKit team, though. But yes, the fact that it is closed source also prevents us from landing fixes ourselves. I'm actively exploring dropping support for MLKit on iOS (in favor of Apple's own Vision API). That should eliminate dependency issues on iOS entirely.

Do you have also alternative ms for Android?

Old Firebase don't work with Xcode 16
Any workarounds?

Old Firebase don't work with Xcode 16 Any workarounds?

Open in Android Studio ios/Runner.xcodeproj/project.pbxproj and wherever is CLANG_ENABLE_MODULES = YES; put below this line CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = YES; and this option will also appear in xcode after you do this.

Old Firebase don't work with Xcode 16 Any workarounds?

Open in Android Studio ios/Runner.xcodeproj/project.pbxproj and wherever is CLANG_ENABLE_MODULES = YES; put below this line CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = YES; and this option will also appear in xcode after you do this.

Open in Android Studio ios/Runner.xcodeproj/project.pbxproj and wherever is CLANG_ENABLE_MODULES = YES; put below this line CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = YES; and this option will also appear in xcode after you do this.

Just a quick note: although it may work, everybody in the thread warn against it, since it may introduce some bugs. If you do it, don't forget to revert it when a proper fix is introduced.

@haf We use the Vision API from Apple on MacOS. My plan is to move to that for iOS as well.

Guys, is there any news? I also encountered this, there are packages that require updated versions of firebase and along the chain I ended up here

We depend on MLKit to update their version, so there isn't any news for this issue.

Yep, still a P4 Issue for Google:
https://issuetracker.google.com/issues/362452861

This works for me:
Xcode => Runner => Build Settings and put "Allow Non-modular Includes In Framework Modules" to "yes"
Package versions:
firebase_crashlytics: 3.5.7
firebase_core: 2.31.1
mobile_scanner: 5.0.0

I got this error when running pod install:
[!] CocoaPods could not find compatible versions for pod "GoogleDataTransport":
  In Podfile:
    firebase_crashlytics (from `.symlinks/plugins/firebase_crashlytics/ios`) was resolved to 4.1.3, which depends on
      Firebase/Crashlytics (= 11.2.0) was resolved to 11.2.0, which depends on
        FirebaseCrashlytics (~> 11.2.0) was resolved to 11.2.0, which depends on
          GoogleDataTransport (~> 10.0)

    mobile_scanner (from `.symlinks/plugins/mobile_scanner/ios`) was resolved to 5.2.3, which depends on
      GoogleMLKit/BarcodeScanning (~> 6.0.0) was resolved to 6.0.0, which depends on
        GoogleMLKit/MLKitCore (= 6.0.0) was resolved to 6.0.0, which depends on
          MLKitCommon (~> 11.0.0) was resolved to 11.0.0, which depends on
            GoogleDataTransport (< 10.0, >= 9.4.1)

and I got this error when running in xcode 16:

plugins:
  firebase_core: ^3.6.0
  firebase_messaging: ^15.1.3
  firebase_crashlytics: ^4.1.3
  sentry_flutter: ^8.9.0
  cloud_firestore: ^5.4.3

@tajjacob read the whole thread

For now this works for me... Override Firebase SDK Version in podfile
$FirebaseSDKVersion = '10.29.0'

We depend on MLKit to update their version, so there isn't any news for this issue.
Edit: I updated the OP to make this more clear for other users.

Is it possible to somehow replace MLKit with another library?

We depend on MLKit to update their version, so there isn't any news for this issue.
Edit: I updated the OP to make this more clear for other users.

Is it possible to somehow replace MLKit with another library?

See https://github.com/juliansteenbakker/mobile_scanner/issues/1165#issuecomment-2371608445
We plan to switch to the Vision API on iOS as well.

Any update on when we can expect a resolve
CLANG_ENABLE_MODULES = YES is not a viable workaround as we do not know what the implications will be
We can't use an older version of firebase_messaging as this has the iOS 18 and Xcode 16 fix

See the top of this thread. This will require us to migrate to the Vision API for iOS.

Same problem, firebase_messaging and mobile_scanner.
firebase_messaging depends on GoogleDataTransport (~> 10.0)
mobile_scanner depends on GoogleDataTransport (< 10.0, >= 9.4.1)

+1

in my case, camerax pacakge is depends on very old version of GoogleDataTransport ~> 3.2 something
but firebase_messanging use GoogleDataTransport ~> 10.0
clearly, camerax need to get the package updated

@dishankjindal1 it will not help since GoogleMLKit also depends on an outdated version of GoogleDataTransport as you can gather from this thread.

I am facing the same issue too!

As suggested in the issue tracker by someone, this worked for me too:

I was able to fix this bug temporarily with the Podfile of my ios build. Please see the $FirebaseSDKVersion = '10.29.0' at the top of my Podfile. This is the important part:

Podfile:
# Temporary fix for Google ML Kit bug - https://issuetracker.google.com/issues/362452861
$FirebaseSDKVersion = '10.29.0'
...

@EvertonMJunior

As suggested in the issue tracker by someone, this worked for me too:

I was able to fix this bug temporarily with the Podfile of my ios build. Please see the $FirebaseSDKVersion = '10.29.0' at the top of my Podfile. This is the important part:

Podfile:
# Temporary fix for Google ML Kit bug - https://issuetracker.google.com/issues/362452861
$FirebaseSDKVersion = '10.29.0'
...

You should not use newer Flutterfire components with older SDKs (cocoapods), which is what you are trying to achieve here. You have no guarantee that the recent Flutterfire packages will behave appropriately with SDK 10.29.0 (and not 11.x).
The only solution seems to downgrade Flutterfire in pubspec.yaml.

$FirebaseSDKVersion = '10.29.0'

Unfortunately using an older version of Firebase isn't an option for me as it doesn't include a fix to an Xcode 16 build issue
See this closed Firebase issue https://github.com/firebase/firebase-ios-sdk/issues/13115

@AristideVB I've solved the BoringSSL issue adding the following lines to the Podfile:
post_install do |installer|
  installer.pods_project.targets.each do |target|

    if target.name == 'BoringSSL-GRPC'
      target.source_build_phase.files.each do |file|
        if file.settings && file.settings['COMPILER_FLAGS']
          flags = file.settings['COMPILER_FLAGS'].split
          flags.reject! { |flag| flag == '-GCC_WARN_INHIBIT_ALL_WARNINGS' }
          file.settings['COMPILER_FLAGS'] = flags.join(' ')
        end
      end
    end

    [...]

Its fixed by google:
https://issuetracker.google.com/issues/362452861

@Bilonik Thank you for the confirmation. I will roll mobile_scanner forward to pick up the new MLKit version.

I have opened an issue with GoogleMLKit for this issue: https://issuetracker.google.com/issues/362452861

Thanks!

Google fixed the issue. Please can you update from this end now.
GoogleMLKit shipped a new release (7.0.0)
https://developers.google.com/ml-kit/release-notes#september_30_2024
It upgraded its version range of GoogleUtilities/UserDefaults dependency in MLKitCommon from ">= 7.13.0, < 8.0" to "~> 8.0" and should have fixed this dependency conflict issue.
The current version according to mobile scanner is 6.0.0

A new version is on it's way. However, this version will have to bump the minimum iOS deployment target to iOS 15.5.0, per MLKit requirements.

I would still like to bring iOS over to the Vision API, as it brings some improvements to the plugin. (SPM support, no third-party dependencies, easier maintenance when merged with the MacOS implementation under the darwin/ folder, better results i.e. analyzeImage works on files where MLKit didn't, etc.)
We were just very fortunate that MLKit did bring out an update last week.
I think that we could try to do the Vision migration for the next major release.

A new version is on it's way. However, this version will have to bump the minimum iOS deployment target to iOS 15.5.0, per MLKit requirements.

@navaronbracke I saw you published the new version, thank you. I see in the changelog that XCode 15.3+ is now required? Ouch, this means macOS Ventura is now unsupported. Can I ask you where you saw the XCode 15.3+ requirement?

If we ever drop MLKit in favor of the Vision API (which is the long-term plan) we might be able to relax that requirement. However, with Apple probably requiring people to build using the iOS 18 SDK soon, I don't think that would help anyway.

@ettaegbe I'm sorry but I do not understand what you mean here. We fixed the issue with Firebase in version 6.0.0, is there a specific reason why you need support for the Vision API on iOS ?

It is fixed:
https://pub.dev/packages/mobile_scanner in version 6.0.0
flutter clean && flutter pub get
pod repo update
flutter build ipa

I update all packages and have a same problem
[!] CocoaPods could not find compatible versions for pod "GoogleDataTransport":   In Podfile:     firebase_messaging (from.symlinks/plugins/firebase_messaging/ios`) was resolved to 11.4.4, which depends on
Firebase/Messaging (= 9.6.0) was resolved to 9.6.0, which depends on
FirebaseMessaging (~> 9.6.0) was resolved to 9.6.0, which depends on
GoogleDataTransport (< 10.0.0, >= 9.1.4)
mobile_scanner (from `.symlinks/plugins/mobile_scanner/ios`) was resolved to 6.0.0, which depends on
  GoogleMLKit/BarcodeScanning (~> 7.0.0) was resolved to 7.0.0, which depends on
    MLKitBarcodeScanning (~> 6.0.0) was resolved to 6.0.0, which depends on
      MLKitCommon (~> 12.0) was resolved to 12.0.0, which depends on
        GoogleDataTransport (~> 10.0)

`

I update all packages and have a same problem
[!] CocoaPods could not find compatible versions for pod "GoogleDataTransport":
  In Podfile:
    firebase_messaging (from `.symlinks/plugins/firebase_messaging/ios`) was resolved to 11.4.4, which depends on
      Firebase/Messaging (= 9.6.0) was resolved to 9.6.0, which depends on
        FirebaseMessaging (~> 9.6.0) was resolved to 9.6.0, which depends on
          GoogleDataTransport (< 10.0.0, >= 9.1.4)

    mobile_scanner (from `.symlinks/plugins/mobile_scanner/ios`) was resolved to 6.0.0, which depends on
      GoogleMLKit/BarcodeScanning (~> 7.0.0) was resolved to 7.0.0, which depends on
        MLKitBarcodeScanning (~> 6.0.0) was resolved to 6.0.0, which depends on
          MLKitCommon (~> 12.0) was resolved to 12.0.0, which depends on
            GoogleDataTransport (~> 10.0)

firebase_messaging: ^11.4.3 mobile_scanner: ^6.0.0

Update firebase_messaging (15.1.3) to the latest version and it will work.
Please stop using this issue thread for unrelated things.
The issue itself has been solved and closed.

Your changes works. I just have issues because of my Xcode version. I’m
using Ventura so I can’t do anything .
On Tue, Oct 8, 2024 at 6:09 PM Navaron Bracke @.***>
wrote:

@ettaegbe https://github.com/ettaegbe I'm sorry but I do not understand
what you mean here. We fixed the issue with Firebase in version 6.0.0, is
there a specific reason why you need support for the Vision API on iOS ?
—
Reply to this email directly, view it on GitHub
https://github.com/juliansteenbakker/mobile_scanner/issues/1165#issuecomment-2400404168,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACWEL6DZ34XZBCIYO2VZETDZ2QGUXAVCNFSM6AAAAABNGFMG2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBQGQYDIMJWHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

A new version is on it's way. However, this version will have to bump the minimum iOS deployment target to iOS 15.5.0, per MLKit requirements.

Thanks for your quick replies and fixes!!! Which can't be said about Google :)


[release-3.0]  Metal3 quickstart updates

Backport of #254
Add details around building the base image and deploying the downstream clusters
(cherry picked from commit 97fccc2a0166b723cecf7af69c583c2463eb3efc)

@hardys Since you have cherry-picked this into release-3.0 branch. it is automatically picked up for the weekly release.
However, I had a  few suggestions on the file and I am leaving those comments.


cleans up codebase according to ET standards. fixes issue #1027

https://github.com/ExactTarget/javascript#whitespace

Slightly easier view into these changes (eliminates strictly "whitespace" diffs, meaning, you won't see the differences where I literally converted errant spaces into tabs, you'll only see structural differences):
https://github.com/ExactTarget/fuelux/pull/1028/files?w=1


Optimize PNG images with ZopfliPNG and pngquant

Leaflet is already very lightweight, but I noticed that the PNG images could be made smaller. Using a combination of ZopfliPNG and pngquant (for the two marker images), I was able to reduce the total size from 11.0 KB to 6.6 KB.
ZopfliPNG is lossless, but pngquant does alter the images slightly. I wasn't able to tell the difference with my eyes, but I guess you can use GitHub's fancy image comparison tool to check it yourself!
Thanks for working on Leaflet!

Great, thanks! I can't see the difference as well.

Awesome! Thanks.


Support for SHARD DURATION in retention policy

The SHARD DURATION clause determines the time range covered by a shard group.
Based on:
https://docs.influxdata.com/influxdb/v1.3/query_language/database_management/#create-retention-policies-with-create-retention-policy
Fixes #204

Looks good on a first glace (I will have a closer look tomorrow).

@dmke updated based on your suggestions. Thanks.

Thanks!
I have merged and released your changes.


[Streetcode page]  The vertical progress bar disappears from 1448 px

Environment: OS, Windows 11 .
Browser Google Chrome Version 114.0.5735.135.
Reproducible: always
Build found: https://github.com/ita-social-projects/StreetCode/commit/77fb021ad16c11d189d744dff099c9920c0873bb
Preconditions

Go to the site as user.

Steps to reproduce

Go to 'Streetcode'
Click on vertical progress bar
Сheck that the progress bar is present on the desktop version (from 1025 px)

Actual result
The vertical progress bar disappears from 1448 px and below
Expected result
The vertical progress bar is present on the desktop version ( from 1025 px)
https://github.com/ita-social-projects/StreetCode/assets/109734235/c97ef5b3-9188-4ca8-87c8-2fc02b874d50
User story and test case links
E.g.: "User story #77
Labels to be added
"Bug", Priority ("pri: medium "), Severity ("severity: low"), Type ("Functional")

The bug is reproduced as well on MacBook Air, Apple M1.
Brauser: Chrome, Safari.
Displays 2560x1600.
If you open DevTool and select the same screen size (2560x1600), the progress bar is present, but it is absent on real computers.


on-pt-item-confirmed doesn't send json object of selected item

i think something was changed from a previous version.
before the update, the data of the selected json object was passed to the on-pt-item-confirmed event, now i can't find the object's data anywhere.

What data do you mean?   The pt-item-confirmed event is passing the selected item to the event, which is the  element.

What version does it pass the selected json to the event?

i can't restore my ancient version.
when i am setting up the items list like this:
	<paper-typeahead-input
		data-local-candidates="{{locals}}"
		autocomplete="off"
		display-prop="text"
		input-object="{{input}}"
		searchable-props="text, id"
		remote-url="data.php?q=%QUERY"
		is-candidates-json="true"
		name="mytypeahead"
		on-pt-item-confirmed="confirmed"></paper-typeahead-input>

// data is not data, but the selected item (as stated in the docs)
scope.confirmed = function(e, data) {
  console.log('confirmed', e, data);
  scope.price = data.price
}

the list of items is created from json-objects.
so when an item is selected/confirmed, my event needs to know about the underlying json data for further processing.

well first of all, there is no autocomplete and name property supported for paper-typeahead-input yet.
As for your request, you already assign a variable to input-object property.
When the event pt-item-confirmed is fire, you have a callback function confirmed for that. Inside of it, you will be able to know the selected item by your variable input.
scope.confirmed = function(e) {
  console.log(scope.input);
  scope.price = scope.input.price;
}

thanks, you are right, data is in the {{Input}}.
i had to add autocomplete, because it screws up on my surface rt:
      autocomplete:{
        type:String,
        value:"off"
      }

      // input.$.input.autocomplete = 'address-level4';
      input.$.input.autocomplete = this.autocomplete;

Oh  so about the line input.$.input.autocomplete = 'address-level4'; I think that's added to fix a bug of the chrome autofilling problem. It's a workaround.   About the autocomplete, do you think it's an issue that need to be resolved? What do you mean by "it screws up" surface rt?  What kind of bug it is?


Load CDN assets with Subresource Integrity check

https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/

So far I was unable to find LAB.js replacement with SRI support.
This issue is blocked until we find one, or create PR for LAB.js.

Until we remove LABjs, https://github.com/lidel/yt-looper/commit/6cd77f2161920e0a1ef14f682d06d4730f3799a1 will protect against malformed load of base libraries.


Incorrect highlighting of Vim syntax

Steps to reproduce
I wanted to report this issue at https://github.com/vim-jp/syntax-vim-ex (specified at the beginning of $VIMRUNTIME/syntax/vim.vim), but GitHub says "This repository has been archived by the owner on Feb 15, 2024. It is now read-only".

Put this text into the buffer: packadd vim-css3-syntax-main
Execute :set filetype=vim. The vim and syntax parts are colored vimCommand and vimSyntax respectively.

Expected behaviour
Both parts sould be colored VimIsCommand.
Version of Vim
9.1.443
Environment
.
Logs and stack traces
No response

FWIW, I just discovered that the three -s are colored vimOper. Should probably also be colored VimIsCommand.


Global export of all properties in basemap in MapBox (colors)

ALso is there a way to place the labels above. the census track. That would allow a less opaque tract style.

This is awesome! I will get these changed and maybe we can meet on it?


Minimum required columns must be exists in the import file

Define and check some minimum required columns which one must exists at import time.
Must have columns:

colFileName

Import file is not anymore needed.


Importing article {{{ content }}} stops at first section

Hi!
The link to the article : https://lynettebye.com/blog/2023/4/20/inside-the-minds-of-adhd
Relevant section of the article :

The imported content stops at the first section:

I do have highlights that go further down the article.

I tried deleting the article block, changing the sync date and reimporting to no avail.

I changed {{{ content }}} to {{ content }} to no avail.

Logseq plugin version: 1.13.0

The saved article is  fine in omnivore android and web

Let me know if I can help provide more information :)

@thiswillbeyourgithub do you mind opening the markdown of the page in another editor like VS Code, and checking to see if the full content is there?

I just opened it in vim and confirm that the rest of the article is not there.

Is there any workaround or something?

Not that I found. It's a pretty serious issue that can be devastating to one's workflow :/

I was able to replicate this with the top article, i have a feeling Logseq fails when we import the header elements like
# When you have a task that requires a lot of thought, how often do you avoid or delay getting started?

Oh. I think logseq throws an error when you use "# something" inside a multiline block. Maybe this error is hidden when it's from a plugin ? If that's the issue that's great because that means you can split the content in several blocks as I wished for in #113  :D

Yeah, I believe Logseq still doesn't allow multiple headings or sub-block in the same block so it causes this error.

The problem that I found is {{{ content }}} could not work.
I wish to see original content below the Highlights. So the Template of Highlight is set as:
> {{{text}}} [⤴]({{{highlightUrl}}}) {{#labels}} #[[{{{name}}}]] {{/labels}}

{{#note.length}}note:: {{{note}}} {{/note.length}}

[[omnivore original content]]
collapsed:: true
    {{{ content }}}

It just could not work at all.
Hope there will be new options for the page content preferences of this plugin.

Hey @Asgoret sorry for the late reply. Yeah, Logseq has some issues displaying the content in markdown format in a block.
I believe it is because Logseq does not allow nested blocks generated by templates

@sywhb no worries. Do you know maybe, there is any issue/mr on logseq side? So I can bump it out

@Asgoret I believe I saw one before. Let me look for it

@sywhb Hello, I have encountered the same issue. After conducting some testing and analysis, I suspect that it might be caused by two consecutive line breaks, resulting in the truncation of the text. I hope this information can be helpful in resolving the problem. Thank you.

@sywhb a simple workaround for now would be to escape the leading # of the text. Either simply adding a space between the newline and #, or backslash in each newline +#. Etc. Maybe rrplacing by simply a larger bolded font via inline html?
A more advanced fix would be to split the large block into different blocks, which is apparently more what ligseq was designed to handle anyway. But then you might want each highlight to appear as children of the right block of text, and might run into issue with respecting the template etc. All in all this is more complicated.
I'd really like to have the quick workaround at least because I'm coding a script that automatically creates anki flashcards of my highlights via logseq and this is keeping me stuck. Hence why the quick workaround above :)

I'd really like to have the quick workaround at least because I'm coding a script that automatically creates anki flashcards of my highlights via logseq and this is keeping me stuck. Hence why the quick workaround above :)

Up :)

Respectful up :)

That seems to work perfectly! Thank you immensely. I'll tell you more later when I finish creating an automatic flashcard creator based on this. Thanks!

Thanks for the confirmation! @thiswillbeyourgithub
I finally got time to finish this PR and hopefully it will resolve this issue permanently ~


Add peak memory reporting for IREE, TF and PyTorch

IREE is the only platform that supports peak memory reporting on both CPU and GPU. TensorFLow and PyTorch both report peak GPU memory usage.

Thank you

Looks good to me, thanks so much for this.
The formatting issues can be resolved by:
pip install black black --line-length 79 .  from the base SHARK directory.

Done – thanks!


Provide enum type parameters for Argo workflows

Summary
This is an enhancement to provide choice parameters as provided by Jenkins
Jenkins Example:
choice(name: 'CHOICE', choices: ['One', 'Two', 'Three'], description: 'Pick something')

A similar input parameter type could be provided for workflows. Something in the lines of
arguments:
    parameters:
    - name: choice
      defaultValue: one
      valueFrom:
           choices:
               - one
               - two
               - three

Use Cases
When would you use this?
Anyone who is submitting a workflow template from UI, would be able to specify arguments from the dropdown which has values from the choices array

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

@jessesuen @basanthjenuhb want to work on this as part of hacktoberfest. I think we need to come up with a suitable way to specify the options, I'd lean more towards:
arguments:
    parameters:
    - name: choice
      defaultValue: one
      enum:
               - one
               - two
               - three

Making the changes in #4314
UI PR coming up next

Making the UI changes in #4365
@alexec can you help with the PR


Update guide.md

This PR resolves the issue: #2436

Thanks for the contribution!
Can you please force-push and update your commit to follow our general commit style? In this case, it would be docs: Update nginx certbot to use python3

Duplicate of #2439


convert ".ipynb" into ".py" without "run cell" and "run Below" in VSCode

Feature: Notebook Editor, Interactive Window, Python Editor cells

Description
When we convert ".ipynb" into ".py" file in VSCode, can it automatically delete the parts similar to "run cell" and "run Below". Thanks a lot.
Microsoft Data Science for VS Code Engineering Team: @rchiodo, @IanMatthewHuff, @DavidKutu, @DonJayamanne, @greazer, @joyceerhl

Hi @jill123-cc @n0nvme @ijyliuC, are you referring to the cell markers (which are # %% by default)? Those are intended to allow users to execute cells in the Python extension's interactive window. If so, our team can discuss adding a setting to strip these cell markers out. It would help us prioritize this if you could share your use case here--why do you not want the cell markers?
(And just in case you're asking about the 'Run cell' and 'Run below' codelenses that appear above the cell markers, those codelenses aren't actually part of the document.)

@joyceerhl -Thank you for your replay.
The code I used is as follows:
To add a new cell, type '# %%'
To add a new markdown cell, type '# %% [markdown]'
%%
import matplotlib.pyplot as plt
import numpy as np
x = np.linspace(1,10)
plt.plot(x, np.sin(x))
plt.show()
%%
plt.plot(x, np.cos(x))
plt.show()
%%
plt.plot(x, np.tan(x))
plt.show()
%%

@jill123-cc, you can disable codelenses by setting the following setting:
"python.dataScience.enableCellCodeLens": false


Publicly shame people who try to set the theme to HotDogStand

https://www.youtube.com/watch?v=SrDSqODtEFM

Let's add a setting to allow choosing multiple "shame" themes and send a message to chat shaming the requester.

So this is now handled.
"But Mike, I don't see any commits are PR's related to it..."
Yes, I know.  Trust me.  It's handled.  😆


Fix the Readme workflow status picture

The "Python" workflow was deleted, replaced by a collection of Workflow.
Why not to bundle these collection to one, called "Python"

Expected: the new Python workflow is badged on the readme, like previously.

The problem is that there is no single python workflow; instead, there is one
workflow for each python module (client or lib).
So, we can't have a single badge, we'd need to add one badge for each python
module, which I'm afraid is going to be a bit too much: currently 5 on master,
with more to come...

As discussed together badges will be shown in the main README.md in dedicated sections mentioning Python subdirs