Add missing EDNS0EXPIRE data unpack

Currently EDNS0 Data unpack for EXPIRE option isn't implemented yet.

Codecov Report

Merging #1054 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #1054      +/-   ##
==========================================
- Coverage   54.97%   54.96%   -0.01%
==========================================
  Files          41       41
  Lines        9872     9879       +7
==========================================
+ Hits         5427     5430       +3
- Misses       3423     3428       +5
+ Partials     1022     1021       -1

Impacted Files
Coverage Δ

msg_helpers.go
57.46% <0%> (-0.92%)
:arrow_down:

server.go
67.4% <0%> (-0.28%)
:arrow_down:

msg.go
77.23% <0%> (+0.67%)
:arrow_up:

Continue to review full report at Codecov.

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

/merge
On Thu, 19 Dec 2019, 04:31 Tom Thorogood<EMAIL_ADDRESS>wrote:

@tmthrgd approved this pull request.
LGTM
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/miekg/dns/pull/1054?email_source=notifications&email_token=AACWIW44Z5MG3GNRHZB3IXLQZL2LLA5CNFSM4J3737ZKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCPXJSMA#pullrequestreview-334403888,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACWIW64Y7T4XS35SGU32F3QZL2LLANCNFSM4J3737ZA
.


Support for includes and excludes in the undeploy goal

README.md changes:

Updated deploy documentation to add the appArtifact parameter and
examples.
Updated undeploy documentation to add patternSet parameter and
examples.

MvnMessages.properties changes:

Added a new message to use it when the undeploy is done by a pattern
set.

UndeployAppMojo changes:

Organized imports.
Updated mojo documentation.
Added patternSet parameter.
Added support for the undeploy by pattern sets.

@RobertoSanchezHerrera the modifications that you proposed me were added. Thank you.

Commit merged. Thanks.


Question: Custom ParseError derived type seems erroneous

I'm using Rust 1.56, and implementing custom error types in nom have been VERY hit or miss for me. I've been trying to make a 3D file format conversion crate. With my first attempt (here) my custom error type worked without issue. with .pmx file header parsing. However, I tried to make a JSON parser (glTF, VRoid, etc are JSON formatted) and a prevailent error I'm getting is that JsonParseError is not convertable to nom::Err and such. I've looked at several examples, looked over past issues here, tried various things, but to no avail.
Here's the attempt. I'm confident that I'm most likely missing something that's obvious to more knowledgeable nom users.

could you show what kind of error you're getting? was it with a specific combinator?

error[E0277]: `?` couldn't convert the error to `nom::Err<JsonParseError>`
   --> /home/admin/Documents/GitHub/meshio.rs/core/src/json.rs:167:39
    |
166 | fn json_str(input: &str) -> IResult<&str, JsonValue, JsonParseError> {
    |                             ---------------------------------------- expected `nom::Err<JsonParseError>` because of this
167 |     let (input, s) = double_quoted(input)?;
    |                                          ^ the trait `From<nom::Err<nom::error::Error<&str>>>` is not implemented for `nom::Err<JsonParseError>`
    |
    = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
    = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, nom::Err<nom::error::Error<&str>>>>` for `Result<(&str, JsonValue), nom::Err<JsonParseError>>`
note: required by `from_residual`

error[E0271]: type mismatch resolving `<impl FnMut<(&str,)> as FnOnce<(&str,)>>::Output == Result<(&str, _), nom::Err<nom::error::Error<&str>>>`
   --> /home/admin/Documents/GitHub/meshio.rs/core/src/json.rs:187:24
    |
187 |     let (input, (s, v)) = separated_pair(ws(double_quoted), ws(char(':')),
    |                           ^^^^^^^^^^^^^^ expected struct `nom::error::Error`, found enum `JsonParseError`
    |
    = note: expected enum `Result<(&str, _), nom::Err<nom::error::Error<&str>>>`
               found enum `Result<(&str, JsonValue), nom::Err<JsonParseError>>`
    = note: required because of the requirements on the impl of `Parser<&str, _, nom::error::Error<&str>>` for `impl FnMut<(&str,)>`
note: required by a bound in `separated_pair`
   --> /home/admin/.cargo/registry/src/github.com-1ecc6299db9ec823/nom-7.0.0/src/sequence/mod.rs:137:6
    |
137 |   H: Parser<I, O3, E>,
    |      ^^^^^^^^^^^^^^^^ required by this bound in `separated_pair`

error[E0277]: `?` couldn't convert the error to `nom::Err<JsonParseError>`
   --> /home/admin/Documents/GitHub/meshio.rs/core/src/json.rs:188:23
    |
186 | fn key_val(input: &str) -> IResult<&str, (String, JsonValue), JsonParseError> {
    |                            -------------------------------------------------- expected `nom::Err<JsonParseError>` because of this
187 |     let (input, (s, v)) = separated_pair(ws(double_quoted), ws(char(':')),
188 |         ws(json_val))(input)?;
    |                             ^ the trait `From<nom::Err<nom::error::Error<&str>>>` is not implemented for `nom::Err<JsonParseError>`
    |
    = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
    = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, nom::Err<nom::error::Error<&str>>>>` for `Result<(&str, (String, JsonValue)), nom::Err<JsonParseError>>`
note: required by `from_residual`

I think the issue is coming from double_quoted using the default error type:
167 |     let (input, s) = double_quoted(input)?;
    |                                          ^ the trait `From<nom::Err<nom::error::Error<&str>>>` is not implemented for `nom::Err<JsonParseError>`

https://github.com/Schala/meshio.rs/blob/main/core/src/parser.rs#L30-L36


[SPARK-17807][core] Demote scalatest to "provided" in spark-tags.

This avoids exposing scalatest as a transitive dependencies to projects
that depend on spark-core, but don't declare a direct dependency on
scalatest in test scope.
Tested by checking "mvn dependency:tree" with a small pom file that just
declared a dependency on spark-core; scalatest would show up as "compile"
before the change, now it doesn't show at all.

Test build #70228 has started for PR 16303 at commit e5772e2.

Test build #70228 has finished for PR 16303 at commit e5772e2.

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/70228/
Test PASSed.

I appreciate the quick turn-around on this, though it seems like a mis-use of the provided scope.
FWIW, I am advocating for:

mv common/tags/src/{main,test}/java/org/apache/spark/tags;
publish the test-jar for the spark-tags module.

I know this is trivial in SBT, and I've seen Maven modules do this
bdgenomics:utils-misc does it with this config blob afaict?

This may work in practice, but it doesn't sound like the right change. The scalatest dependency is correctly non-test because it is used by the tags that this module exposes from its non-test code.
One solution is to make spark-tags itself provided, because it won't matter if the annotations are present at runtime, as far as I can tell. It's not really provided, but, doesn't matter.
Another is to move the test-oriented tags to src/test/scala, and have tests depend on its test-jar artifact.

I filed #16311 splitting out a spark-tags test-jar; turns out my second bullet above is a no-op since all Spark modules' test-jars are already automatically published, so that's neat.
As I noted over on #16311, I now feel that we should just move each of the three test-tags to the modules they are pretty explicitly scoped to (in name and usage), and do away with spark-tags' containing these test-tags altogether, but we can discuss that further over there.

Closing in favor of the other PR.


Testing OpenFAST

Error running r-test.txt
Hi,
I'm new with OpenFAST and I'm getting troubles with the unit and regression tests.
I managed to install OpenFAST with Visual Studio using Windows 10. Then I´ve been trying to compile the unit tests following the section <IP_ADDRESS> of the OpenFast documentation, but when I make the target to test with make beamdyn_utest, I´m getting this error message:
_C:\Users\ave\code\openfast\unit_tests>make beamdyn_utest
'make' is not recognized as an internal or external command,
operable program or batch file._

I added the path of the cmake´s executable to the environment variables, but it didn't fix the problem. I'm using Intel compiler 19.
On the other hand, I´ve followed the steps described in section 5.2.3 to execute the OpenFAST regression tests. However, all the tests fail with the following error:
(base) C:\Users\ave\code\openfast\reg_tests>python manualRegressionTest.py ..\build\bin\openfast_x64_Double.exe Windows Intel 1e-5
executing AWT_YFix_WSt                           'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
FAIL

I´m using Anaconda prompt.
Can someone help me with these issues?
Any help would be appreciated.

Thank you for your reply.
See here the executable path:
>>> import os
>>> os.chdir(r'C:\Users\ave\code\openfast\reg_tests')
>>> import sys
>>> print(sys.executable)
C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\python.exe

and here lines from 73 to 79 in manualRegressionTest.py:
for case in casenames:
    print(strFormat(prefix).format(prefix), strFormat(longestName+" ").format(case), end="", flush=True)
    command = "{} executeOpenfastRegressionCase.py {} {} {} {} {} {} {} {} {}".format(pythonCommand, case, openfast_executable, sourceDirectory, buildDirectory, tolerance, machine, compiler, plotFlag, noExecFlag)
    returnCode = subprocess.call(command, stdout=outstd, shell=True)
    resultString = passString if returnCode == 0 else failString
    results.append((case, resultString))
    print(resultString)

Do you have any suggestion to fix the problem with the unit tests?

Thank you @rafmudaf for your reply.
See here the executable path:
>>> import os
>>> os.chdir(r'C:\Users\ave\code\openfast\reg_tests')
>>> import sys
>>> print(sys.executable)
C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\python.exe

For value of command after line 75, please see attached document.
Do you have any suggestion to fix the problem with the unit tests?

ok @aleram06 I've found the bug. Since your python interpreter has spaces in the path, I needed to wrap the execution command in quotes in manualRegressionTest.py. I've tested that this fixes things on my side, but you can verify that it works for you by implementing the change in the last commit of this branch on your local machine.
I've created a pull request for this fix.

Hi, after with unsuccessful attempt of openfast install in windows with cmake and cygwin
64
I managed to install OpenFAST with Visual Studio using Windows 10. Then I´ve been trying to compile the regression test following the  OpenFast documentation, but when I make the target to  regression test I´m getting this error message:

...could you please rectify the error

@manmathan299 Be sure that you have the required dependencies installed as listed here:
https://openfast.readthedocs.io/en/master/source/testing/regression_test.html#dependencies


Infinite not being used

Example:
extern crate num;

use num::{BigInt, BigRational, ToPrimitive};

fn main() {
    let n = BigInt::from(-2);
    let n = n.pow(4001);
    println!("{:?}", n.to_f64());
    let r = BigRational::from(n);
    println!("{:?}", r.to_f64());
}

Result:
None
Some(-inf)

I was expecting some minus infinite and got none. A workaround is to convert to BigRational but it is expensive, a clone is required.

You can also see ToPrimitive sticking to finite values when narrowing, e.g. std::f64::MAX.to_f32() returns None. It's been that way ever since it was first created in rust-lang/rust#9250 (specifically here), and it doesn't appear that this point was debated.
At that time, bigints only directly supported converting to 64-bit integers, and floats would convert from there by the trait default, so larger values would just be None. Then rust-num/num#145 added explicit conversions from bigints to floats, noting that None was used instead of Some(INFINITY), but we didn't debate that point.
So this is actually inconsistent on BigRational's part, which is relatively recent: rust-num/num-rational#52.
That's not to insist that we shouldn't change, but we should be careful and consistent about it.

Another inconsistency: u128::MAX.to_f32() returns Some(INFINITY).

Understood, thank you for clarifying the situation, closing.

I was starting to think we should change -- do you think not?

To make it consistent? Yes. Would it be for finite value or would infinite value be included?

I think we should include infinities -- if nothing else, the fact that they can be positive or negative is better than None.

Agree. Reopening to track the issue.


Update for Hackerone New Asset Type Label : Wildcard

Hi @sw33tLie
Hope All are Going Well !!
I came through an issue, while fetching assets from Hackerone I noticed some of the assets got missed out and digging further found out the reason as Hackerone has introduced new asset type label : Wildcard and most of the programs moved their wildcard assets ( i.e : *.target.com ) to that label and those assets are getting missed while fetching

Thanks & Regards,
@zy9ard3

Dang it, I can see that breaking things. Will check it shortly.
Thank you very much for opening this issue


Data loss in dev environment for credible set overlap table in Study Locus Page

Ricardo and Irene reported a loss of data in the section of the study/locus page where the credible set overlap is displayed.
This in an example of a working page in production that currently has no data --- the Manhattan plots that are visible from this page are missing in the dev page.
The offending endpoint is gwasCredibleSet.
Here is the query we use to pull that data:
In production--> data is there
In dev --> data is absent
-- Jarrod looked into this issue and reported an error in the DB. Unfortunately the API fails silently so doesn't really help indicating that something has gone wrong. He has manually fixed the DB so it will work until the DB is restarted.
Proper fix requires us to rebuild the infrastructure.

The problem is in Clickhouse where one of the columns has the wrong name. This has been temporarily fixed using the command  ALTER TABLE ot.v2d_credset RENAME COLUMN "assumeNotNull(logABF)" TO logABF.
The permanent fix needs to be in the v2d_credset.sql file in `genetics-infrastructure.


nom: 2.1.3 -> 2.1.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/guyfedwards/nom/releases.
meta.description for nom is: RSS reader for the terminal
meta.homepage for nom is: https://github.com/guyfedwards/nom
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.1.4 in filename of file in /nix/store/y75a9fpv3rykija6jbab6crsfp4nfnqm-nom-2.1.4

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
nom

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/y75a9fpv3rykija6jbab6crsfp4nfnqm-nom-2.1.4 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nom https://github.com/r-ryantm/nixpkgs/archive/7e90be2a25599dbb349661033c1a5bcc5dda96d2.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/7e90be2a25599dbb349661033c1a5bcc5dda96d2#nom

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/y75a9fpv3rykija6jbab6crsfp4nfnqm-nom-2.1.4
ls -la /nix/store/y75a9fpv3rykija6jbab6crsfp4nfnqm-nom-2.1.4/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

nom

Maintainer pings
cc @nadir-ishiguro for testing.

Result of nixpkgs-review pr 294297 run on aarch64-darwin 1

1 package built:

nom


When Alita walks near enemies her rotation goes crazy

Description:
When Alita walks near enemies her rotation goes crazy
Build:
v<IP_ADDRESS>
Type:
Alita
Steps to reproduce:
Walk near an enemy
Frequency:
Sometimes

This was the enemies pushing the enemy, but it should be alright now.


Bug with DateTimePicker and timezones persisting or loading wrong value

Package
filament/filament
Package Version
v3.0.81
Laravel Version
v10.28.0
Livewire Version
v3.0.10
PHP Version
PHP 8.2.8
Problem description
After saving a DateTimePicker component with a defined timezone on a resource page, when reloading the page the value gets changed based on the timezone.
If you save, and refresh, and save, refresh etc etc, the value keeps changing.
Expected behavior
I expected the timezone convertion to be handled both on load and on save.
Steps to reproduce

Clone repo
Login with<EMAIL_ADDRESS>and password
Open the only Event
Save the page
Reload the page
See the time change every time

Reproduction repository
https://github.com/adevade/filament-datetime-timezone-bug
Other info

I've only tried this on SQLite databases.
Without the ->timezone('Europe/Stockholm') everything works as expected.
It seems like when the page loads, it skips the defined timezone?
In the table view, everything seems to work fine.

Not a bug. You need to cast the column.

Yep, when I cast to immutable_datetime on the model it works as expected! 🎉
I didn't have it in this reproduction repo, but I could have sworn that I had that cast in my actual project though… I'll have to check later today.
Thanks @sumardi! 👍

I had the cast in place but also an accessor, so that was overriding the cast. There I was providing the timezone in the wrong way:
protected $casts = [
    'start_time' => 'immutable_datetime',
];

public function startTime(): Attribute
{
    return Attribute::get(function (string $value): CarbonImmutable {
-       return CarbonImmutable::parse($value, 'Europe/Stockholm');
+       return CarbonImmutable::parse($value)->timezone('Europe/Stockholm');
    });
}


changing directory results in full rebuild

I'm using a recent nightly Rust version on Windows (10 x64).
The issue that I'm seeing is that "cd myproject;cargo build" followed by "cd src;cargo build" will result in full recompile, including dependencies. I think it has happened with all previous versions of Rust/Cargo that I tried.
P.S. This might be related to the fact that building from rustdt followed by building from console will result in full rebuild (and vice versa).

Thanks for the report! Could you provide some more information like:

What version of Rust are you using?
What version of Cargo are you using?
What dependencies are you using?

Unfortunately I haven't been able to reproduce locally :(

rustc 1.9.0-nightly (d7a71687e 2016-03-24)
cargo 0.10.0-nightly (4e6434d 2016-03-24)
You can try my project at https://github.com/kirillkh/xword_constructor, but it happens with all my Rust projects.

Hm unfortunately I still can't reproduce (even with the same versions). Could you try running with RUST_LOG=cargo::ops::cargo_rustc::fingerprint and gist the output?

I tried again, and I can no longer reproduce it. It definitely has happened at the past, but now I'm suddenly not sure that I rechecked it before opening the bug.
It still does happen with rustdt though (which may have confused me). Posting that log instead.
https://gist.github.com/kirillkh/25585c8fe8026c0cda905152fcf7e9b6

Are you alternating between cargo build --release and cargo build or something like that? Or are Cargo.toml profile settings changing? The reason for recompiling is "target configuration has changed" in all those messages which means that something like the flags has changed.

I obtained the log as follows:

build the project in Eclipse (using rustdt)
run "RUST_LOG=cargo::ops::cargo_rustc::fingerprint  cargo build" from console

I made no changes between the two steps.

Hm it definitely sounds like something suspicious is going on. Do you know if there's a way to see exactly what rustdt is executing in terms of processes and logs? I've tried a few possible variations locally and unfortunately can't reproduce.
Also, are you sure that rustdt and the command line are using the same compiler?

This is the only log I could find. I tried to read rustdt source code, but it's incredibly complex, very hard to analyze just by reading.
Definitely same compiler.

And you're sure that the same Cargo is being used in both cases as well? A good way to verify is to ensure that only one is installed locally

I have only one installed locally and I have checked the path to cargo.exe in the settings of rustdt.

Sorry but I'm running out of ideas :(. It may help to try to add some debugging locally to figure out what rustdt is doing, though?

Found a way to reproduce it outside of rustdt.

start cmd.exe, navigate to project root, run "cargo build"
run "sh -c 'cargo build'"

Interesting! Does the fingerprint log still contain something like:
INFO:cargo::ops::cargo_rustc::fingerprint: fingerprint error for rustc_version v0.1.7: target configuration has changed

And if so, you're still sure that rustc is the same in both contexts? It may have something to do with path names, but I'm not 100% sure where that difference would come from...

Here is a fresh fingerprint log: https://gist.github.com/kirillkh/a54d0883e02273f6568fc942b364953b
I am using the same rustc.

Would you be able to build Cargo locally and test out a patch? I'm curious what's going on here...

Sure.

Ok, can you try apply this patch: https://gist.github.com/alexcrichton/75112eab2324f0e99e987d9272452f6e
and gist the output of both before and after a rebuild? (with the fingerprint log active)

Build fails for me. https://gist.github.com/kirillkh/d3467c17a02476208a7e321c3f87a830

Looks like you may be using the wrong mingw shell by accident?

I don't have any other shell :)

You're right, I was using the 32-bit toolchain by mistake (I think). Let me try and build now...

Now it's failing with this: https://gist.github.com/kirillkh/92a66f218bc9ed5a05072d3d9dca0016

Could you provide the full logs? That looks like it may be an unrelated error

Er rather, it looks like half the error

I ran "cargo clean", and now it's a new error!
https://gist.github.com/kirillkh/ef9c5e27f15594b4c7f37ca0dbfa3a2f
This time it fails before reaching the linking stage, which probably means something I did with the system broke it... I did upgrade msys packages in attempt to fix previuos problems.
Fun fun fun.

Well, I managed to sort it out... I was starting the msys2 console with MSYSTEM=MSYS, and it was conflicting with the mingw64 toolchain. Starting it with MSYSTEM=MINGW64 fixed it.
But now I have another problem. I can't start the built cargo.exe from cmd.exe, it complains about missing dlls (libcurl-4.dll, libssh2-1.dll). I have those dlls in the mingw64 distribution, but then seem to be of incompatible versions. I suppose cargo builds its own versions, but I am not able to find them in the target directory.

Not sure how helpful it is, but here's the log: https://gist.github.com/kirillkh/fd0645f5c99182a92f528dc3db6a90db

All right, managed to get it working (a conflicting dll was on the Windows PATH).
https://gist.github.com/kirillkh/420ef904acced8dfbc690dcf1ba9b013

Nice! To clarify, those last two logs are the logs for cargo in each context? e.g., something like:
$ cargo build > log1.txt
$ sh -c 'cargo build' > log2.txt

The last log is what you called log2.txt. The previous log you should probably ignore, as it was obtained with an older cargo version.

Let me do it all over again. I do the following:

sh -c '<cargo_dir>/target/release/cargo build'
"<cargo_dir>\target\release\cargo build"  => log1.txt
"sh -c '<cargo_dir>/target/release/cargo build'" => log2.txt

log1.txt: https://gist.github.com/kirillkh/5f65af824c620cf5ab8155c7f1de1bb9
log2.txt: https://gist.github.com/kirillkh/b89ead4b087f0ff98b727951577e9d1e

Is there perhaps something special with your H: drive? The two shells are disagreeing on that path to this file:
log1.txt contains "C:\Users\kirillkh\.cargo\registry\src\github.com-1ecc6299db9ec823\rustc_version-0.1.7\src\lib.rs"
log2.txt contains  rustc_version v0.1.7 -- Target { kind: Lib([Lib]), name: "rustc_version", src_path:
"H:\devel\MinGW\msys\home\kirillkh\.cargo\registry\src\github.com-1ecc6299db9ec823\rustc_version-0.1.7\src\lib.rs"

It's a regular NTFS drive. C:\Users\kirillkh.cargo is a totally different directory from H:\devel\MinGW\msys\home\kirillkh.cargo

Oh gah of course! This should actually have been fixed by https://github.com/rust-lang/cargo/pull/2681 as Cargo should use the same cache in both instances. How convenient!

Well, I checked out a fresh git version for testing it, so it is not fixed as of earlier today.

You may want to try deleting the old location in H: first as it's prioritized if it exists

Right, that fixed it.


cli: Remove type restrictions

Allows to use any GGML type instead of only legacy quants and the small selection of k-quants.
Some quant types are not compatible with some backends, but having more options is good I think.

I'm really imporessed by "iq4_nl" type. It runs faster than q4_k on my machine, and the quality seems on par with q5_1 (for sd3.5 large models at least).

Thank you for your contribution.


Validate blank spaces in branch names

Fixes #314
Even though abapGit normalizes branch names in the UI, this is a "back-end" validation. Throws an error if the branch name contains blank spaces.

LGTM
sorry, forgot the PRs yesterday


[Bug] ethereum.decode function misinterprets the value

Bug report
I've been trying to decode some raw encoded data (encoded with abi.encode) to use it later, but encountered an error.
What i've been doing:
    const decodedTuple = ethereum
        .decode('(bool, bool, uint256, uint256, uint256, bool)', args)!
        .toTuple();

After it the decoded data will be used this way:
    createOrUpdateNominationConfig(
        address,
        decodedTuple.at(0).toBoolean(),
        decodedTuple.at(1).toBoolean(),
        decodedTuple.at(2).toBigInt(),
        decodedTuple.at(3).toBigInt(),
        decodedTuple.at(4).toBigInt(),
        decodedTuple.at(5).toBoolean(),
    );

With some log output for debugging:
    log.info('decoding: {}', [args.toHexString()]);
    for (let id = 0; id < 6; id++) {
        log.info('Decoded value type: {}', [decodedTuple.at(id).kind.toString()]);
    }

Data to decode: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
The decoding was able to successfully decode encoded values when it was just two addresses or two uint256 values (encoded with abi.encode):
// Works fine with two addresses
function decodeTwoAddresses(calldata: Bytes): Address[] {
    // Decoding two addresses from RLP
    const decodedTuple = ethereum
        .decode('(address,address)', Bytes.fromUint8Array(calldata.slice(4)))!
        .toTuple();

    return [decodedTuple.at(0).toAddress(), decodedTuple.at(1).toAddress()];
}

// Works fine with two uint256
    const decodedTuple = ethereum.decode('(uint256, uint256)', args)!.toTuple();
    return createOrUpdateSignatureCollectionConfig(
        address,
        decodedTuple.at(0).toBigInt(),
        decodedTuple.at(1).toBigInt(),
    );

Setup:

v0.35.1 running in Docker on MacOS

Relevant log output
2024-04-26 14:00:43 Apr 26 11:00:43.068 INFO NOMINATION_PROCESS, data_source: SpawnerFactory, sgd: 39, subgraph_id: QmVXGsTsp6FKTvDQJfV8WhCk3yK9VtUHyQ5dq5dz1yw73y, component: SubgraphInstanceManager > UserMapping
2024-04-26 14:00:43 Apr 26 11:00:43.069 INFO decoding: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, data_source: SpawnerFactory, sgd: 39, subgraph_id: QmVXGsTsp6FKTvDQJfV8WhCk3yK9VtUHyQ5dq5dz1yw73y, component: SubgraphInstanceManager > UserMapping
2024-04-26 14:00:43 Apr 26 11:00:43.069 INFO Decoded value type: 5, data_source: SpawnerFactory, sgd: 39, subgraph_id: QmVXGsTsp6FKTvDQJfV8WhCk3yK9VtUHyQ5dq5dz1yw73y, component: SubgraphInstanceManager > UserMapping
2024-04-26 14:00:43 Apr 26 11:00:43.069 INFO Decoded value type: 4, data_source: SpawnerFactory, sgd: 39, subgraph_id: QmVXGsTsp6FKTvDQJfV8WhCk3yK9VtUHyQ5dq5dz1yw73y, component: SubgraphInstanceManager > UserMapping
2024-04-26 14:00:43 Apr 26 11:00:43.069 INFO Decoded value type: 4, data_source: SpawnerFactory, sgd: 39, subgraph_id: QmVXGsTsp6FKTvDQJfV8WhCk3yK9VtUHyQ5dq5dz1yw73y, component: SubgraphInstanceManager > UserMapping
2024-04-26 14:00:43 Apr 26 11:00:43.069 INFO Decoded value type: 4, data_source: SpawnerFactory, sgd: 39, subgraph_id: QmVXGsTsp6FKTvDQJfV8WhCk3yK9VtUHyQ5dq5dz1yw73y, component: SubgraphInstanceManager > UserMapping
2024-04-26 14:00:43 Apr 26 11:00:43.069 INFO Decoded value type: 4, data_source: SpawnerFactory, sgd: 39, subgraph_id: QmVXGsTsp6FKTvDQJfV8WhCk3yK9VtUHyQ5dq5dz1yw73y, component: SubgraphInstanceManager > UserMapping
2024-04-26 14:00:43 Apr 26 11:00:43.069 INFO Decoded value type: 4, data_source: SpawnerFactory, sgd: 39, subgraph_id: QmVXGsTsp6FKTvDQJfV8WhCk3yK9VtUHyQ5dq5dz1yw73y, component: SubgraphInstanceManager > UserMapping
2024-04-26 14:00:43 Apr 26 11:00:43.069 ERRO Handler skipped due to execution failure, transaction: 0x764f…c85a, address: 0xd9c5…721a, signature: SpawnerCreated(indexed address,bytes32), error: transaction 764fd136e83deb4f563a559d0ec030757b9cc17a762e086ce0983c66ce6ec85a: error while executing at wasm backtrace:     0: 0x3c29 -<EMAIL_ADDRESS>     1: 0x3ee4 - <unknown>!src/entities/process/getProcessSpawnerConfig      2: 0x47fb - <unknown>!src/entities/process/createProcessSpawner          3: 0x4a23 - <unknown>!src/processes/spawner-factory/handleSpawnerCreated: Mapping aborted at<EMAIL_ADDRESS>line 61, column 7, with message: Ethereum value is not a boolean., handler: handleSpawnerCreated, sgd: 39, subgraph_id: QmVXGsTsp6FKTvDQJfV8WhCk3yK9VtUHyQ5dq5dz1yw73y, component: SubgraphInstanceManager

IPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out

[ ] Tick this box if this bug is caused by a regression found in the latest release.
[ ] Tick this box if this bug is specific to the hosted service.
[X] I have searched the issue tracker to make sure this issue is not a duplicate.

OS information
Other (please specify in your bug report)

In log it says that values have type 5, 4, 4, 4, 4, 4 which maps to BOOL, UINT, UINT, UINT, UINT, UINT, which is different from provided types for decoding

ok, looks like the problem was with having extra spaces between the provided types (idk how, but it works), so the correct one will be:
        const decodedTuple = ethereum
            .decode('(bool,bool,uint256,uint256,uint256,bool)', args)!
            .toTuple();

after this fix all the values decode with correct types


Demo commit

Demo PR ....

Hi @OfficeDevPnP, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;


Different cameras focal lengths

Hi,
I've got a question during testing that thing.
In playground.sh window I see that picture

But when I look at rqt visualisation or save frames from the .bag file I see this

Two different images are going to the screen and the .bag file. It seems they have different cameras  intrinsic parameters. How to fix it and get the same images?
Thank you.

Hi,
I am not able to reproduce that behavior. Could you share the calibration file used? The aspect ratio of the images looks weird.
Thanks,
Henri

Sure!
pinhole_mono_nodistort_forward.yaml
label: "simulated_camera"
id: 433585ebda8d1431223927a14788a127
cameras:
- camera:
    label: dvs0
    id: a0fba5412e961934d842d3a2a78e5cba
    line-delay-nanoseconds: 0
    image_height: 540
    image_width: 960
    type: pinhole
    intrinsics:
      cols: 1
      rows: 4
      data: [480.0, 480.0, 480, 270.0]
    distortion:
      type: none
      parameters:
        cols: 1
        rows: 0
        data: []
  T_B_C:
    cols: 4
    rows: 4
    data: [-1, 0, 0,  0,
           0, 0, -1, 0,
           0, -1, 0, 0,
           0, 0, 0, 1]

unrealcv.conf
--data_source=0
--vmodule=unrealcv_renderer=1
--path_to_output_bag=/home/imagingtre/grayscale_catkin_ws/out.bag
--random_seed=1

--contrast_threshold_pos=0.6
--contrast_threshold_neg=0.6
--contrast_threshold_sigma_pos=0
--contrast_threshold_sigma_neg=0

--exposure_time_ms=5.0
--use_log_image=1
--log_eps=0.001

--calib_filename=/home/imagingtre/grayscale_catkin_ws/src/rpg_esim/event_camera_simulator/esim_ros/cfg/calib/pinhole_mono_nodistort_forward.yaml

--renderer_type=3

--trajectory_type=0
--trajectory_length_s=100.0
--trajectory_sampling_frequency_hz=5
--trajectory_spline_order=5
--trajectory_num_spline_segments=100
--trajectory_lambda=0.1
--trajectory_multiplier_x=1.0
--trajectory_multiplier_y=1.0
--trajectory_multiplier_z=0.5
--trajectory_multiplier_wx=0.15
--trajectory_multiplier_wy=0.15
--trajectory_multiplier_wz=1.

--x_offset=0.0
--y_offset=0.0
--z_offset=1.0

--simulation_minimum_framerate=5.0
--simulation_imu_rate=1000.0
--simulation_adaptive_sampling_method=1
--simulation_adaptive_sampling_lambda=2.0

--ros_publisher_frame_rate=300
--ros_publisher_depth_rate=300
--ros_publisher_optic_flow_rate=200
--ros_publisher_pointcloud_rate=50
--ros_publisher_camera_info_rate=10

Update: I tried to capture the image what unrealCV generates before translating it into grayscale here. I got this

It is 2000x2000 pixels image. And its FOV is more than playnground.sh window shows. It seems playnground.sh cuts the image a bit for some reason.
Below this code the image is resized to the camera settings(from the config file I suppose). That's why
the proportion is getting different. I tried to assign SetRes UE4 parameter here with sendCommand function. But the image from unrealCV is stil 2000x2000.
How can I set it to another resolution?


Fixing issue #162 - adding support for document values in 'distinct'

Thanks!

Thanks !
If possible, could you please make another public release ?
On Tue, Aug 11, 2015 at 10:25 PM, Rotem Yaari<EMAIL_ADDRESS>wrote:

Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/vmalloc/mongomock/pull/163#issuecomment-130028956.

Sure. Released 2.3.0.

Thanks !
On Wed, Aug 12, 2015 at 9:35 AM, Rotem Yaari<EMAIL_ADDRESS>wrote:

Sure. Released 2.3.0.
—
Reply to this email directly or view it on GitHub
https://github.com/vmalloc/mongomock/pull/163#issuecomment-130186144.


set-default-repositories-type-to-sources missing from some links

Description
Both missing in profile nav and profile menu:

How to replicate the issue + URL
https://github.com/kidonng?tab=repositories
Extension version
23.3.31
Browser(s) used
Chrome

This is actually not strictly related to the global navigation but your demo link itself right on this issue is broken 😅 because it doesn't have any selectable attributes.
It seems that we should just alter the feature to observe('[href*="?tab=repositories"]', alterLink) and then filter out any unrelated links via !isProfile

It seems that your UI is different from mine too 🤔
URL: https://github.com/fregante?tab=repositories

I.. will add a divider to make it clear

but your demo link itself right on this issue is broken

Hmm have it ever worked? Because the feature never targeted user content (comments etc.).

It seems that we should just alter the feature to observe('[href*="?tab=repositories"]', alterLink) and then filter out any unrelated links via !isProfile

There's a slight issue with isProfile in that it solely relies on github-reserved-names to avoid false positives. But I'm probably worrying too much because:

Adding &type=source is just noop in most pages
If we do find any false positive we can report to github-reserved-names


[TW#11177] BLE scan coexistence and sporadic scan responses

I'm seeing an issue that seems pretty critical and after spending a good 10 hours investigating figured I'd make sure I'm not crazy...
Currently we have setup BLE scanning and WIFI STA connection.  If I scan for BLE advertisements from my device (a remote control), which sends at ~25-35ms intervals, I often will see some very sporadic intervals between reception, some ranging as high as 500ms.  This is with a scan interval/window of 0x50/0x30 and lots of other combinations as well as different settings for PASSIVE/ACTIVE scanning.   This is with strong RSSI the entire time.  I have checked in nRF Connect on Android and confirmed regular intervals of ~25ms coming from my device ignoring a missed packet here and there.  Also this same device (remote control) was used with a previous product with no problems and nothing in excess of a 100ms or so under normal range/conditions.
I can turn off all initialization of the WIFI AP and STA and the behavior is virtually the same, so I don't think its specific to any custom WIFI code I have added.
My question if this behavior is expected?   Should I be able to scan near full duty (while having WIFI enabled) and expect updates a bit faster?
There's still more I will continue to try, but I wanted to probe the experts to see if you guys had any thoughts.  I'll be happy to collect and post my code although its damn close to the gatt client example and a few others I have found searching around the forums and web for possible solutions.  As I mentioned, I'm committed to getting this working since its critical to my product, so will continue to investigate.  I'd even be happy to send one of my devices to a developer if needed.  Unfortunately 500ms delay just won't work.
Thanks in advance for any help!

Here's some screenshots of my advertiser info.

@jkhax0r Not something which will help you, but IMHO there is a lot of problems around BLE scanning (please refer also to this: https://github.com/espressif/esp-idf/issues/421): Missing scans, wrong RSSI values, scattered scan results. I also suspected a coexistence problem, but all these BLE problems are also present, if Wifi is completely off here.
What kind of ESP32 dev board are you using?
However, I doubt somehow, that you will receive any single advertisement frame in case it is sent at 30 ms interval. I'm not receiving that either, and my beacons advertising at 500-600 ms. But I have never seen a stack, which would fire at this rate (not on Android, iOS or OSX).

@neilyoung We've built some custom PCBs that has the ESP-WROOM-32.  I will go and check on our sparkfun thing dev board too.
One thought I had is that maybe the scan cycles through one of the 3 advertising channels after each scan interval and perhaps only one is working, or that 2 out of the 3 are too far out of band or something.  Just a wild ass guess b/c I seem to often get intervals at exactly 3x the scan interval when I setup my phone to advertise at 100ms.  NOTE: This also might explain your symptoms (issue #421) where certain devices just will not show up.  So is there some kind of NVRAM frequency tuning or calibration that might be slightly out of whack, or even just the crystal???  But its probably much more fundamental b/c this doesn't explain wifi connectivity issues impacted by scan interval/window ratio.
Also weird is that I often get advertisements that are spaced at 0 or 1ms ticks apart.  Unless that's some anomaly with the RTOS tasks and priorities, I can't really explain it.  I'll go and print the data (I randomize it on each advert) and see if maybe that's a repeated packet or not.
I'm not expecting 30ms (obviously not with a a scan window that shuts off for 30+ms), but hoping for at least 1 in 4 of these adverts to give around 100ms or even 200ms in the weak worst signal case.  Anything else is easily perceivable.  I have seen this function properly on the 8-bit, 32Mhz, 8051, TI CC2540 chipset, so I don't think its unreasonable to expect.  And my phone (Galaxy S7) was hauling them in at this rate when I took those screenshots (although I didn't explicitly check for the largest gap, i didn't see even one miss out of about 10 I briefly inspected, and the cool plot that nRF Connect shows had at least 10 dots every second for the 5-10 seconds I sampled).
BTW, I don't mean to complain, as I absolutely love this CPU and environment and am already restructuring and planning for my company to create a whole suite of products around it.   Just hoping a dev might chime in with some thoughts...

@jkhax0r Thanks for the detailed response. Yes, I think 100-200ms should be achievable. The crystal is for sure one suspect, but what concerns me a more is your note regarding interferences between Wifi and BLE: This in fact is not that unlikely as it seems. I know that from some Broadcomm chips (combined BLE and Wifi), built into some Motorola Android devices. They definitely cannot operate simultaneously because each one tramples down the other. So maybe we have the same case here?  If you are sure with your observations, then the hardware design has to be blamed and it would be a big CON for all ideas around ESP32 and BLE.
Other than that I'm still waiting for the promised RSSI fix and I hope our friends at Expressif are checking the issue with the RadBeacon. My preliminary verdict is: Right now the ESP32 is not a good choice if you plan to do real BLE stuff and maybe one should better stick with ESP8266 (or others) and TI, which is supposed to work well in some products known to me.

Same issue here, with code from examples on WROOM-32 we have many lost packets. We were changing esp_ble_scan_params_t (scan_interval and scan_window) and things are really messed up (most of the time it works for about 15 seconds and crashes or stops for 2 minutes). Best stability is for default params.
We have mean interval at about 800ms from iBeacon (kontkat.io) set at 350ms.

@Siwykrzywy If you would like to test with my test program: https://github.com/neilyoung/ESP32_blufi_beacon_tracker

Hi there,
Any updates on this topic? I do have the same issues and miss a lot of advertisement data. What is the best strategy for the esp_ble_scan_params_t and the total BLE scan?
Thanks,
Martijn

@Smeedy I think we have fix this bug in the new version of SDK, please update it. Thanks.


Translation files not downloaded

Had to manually execute this:
sudo su -s /bin/bash -c 'grunt transifex --force' xcp

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

We don't auto download them because transifex requires a username and password to do so (and I'd rather not hardcode one in the script).
Warning: You must put a transifex user and password in /home/xcp/.transifex in this format: user:password
 Used --force, continuing.

Can you enhance the fednode doc (near the end) to note this, and provide instructions as to what the user should do to grab them?

fixed here https://github.com/CounterpartyXCP/Documentation/commit/565ff80b77fc1c4ac300717f58c79d0ddb32c1b2


Compile unused modules as part of pipeline

This PR adds a ./b unused option to generate a role (which is git ignored) which contains all of the unused modules. This role is then created and built as part of the standard build pipeline. This means that changes which break unused modules will break the buildkite builds. This is good.

Rather than making the fs writable, would it be possible to instead write the unused role inside the build folder?

@CMurtagh-LGTM Interesting idea. It would need a fair bit more work, because I would probably have to generate the actual C++ role manually, but I don't see anything which would stop me. I'll give it a go.

@CMurtagh-LGTM Interesting idea. It would need a fair bit more work, because I would probably have to generate the actual C++ role manually, but I don't see anything which would stop me. I'll give it a go.

Is it not possible to add an extra folder to look for role files?

It is, with a bit more work than just adding the string though.
But, I was just playing around with this idea trying to make it work and I don't really like it because the role file becomes hidden in the build directory, so you won't be able to see it or access it without ./b shell, which is bad. People will need to use ./b unused -g to generate the role if their build is failing, so they should be able to see it and know if it's being built or not easily, without having to know about the file obscured in the build directory.

It is possible, with a bit more work than just adding the string though.
But, I was just playing around with this idea trying to make it work and I don't really like it because the role file becomes hidden in the build directory, so you won't be able to see it or access it without ./b shell, which is bad. People will need to use ./b unused -g to generate the role if their build is failing, so they should be able to see it and know if it's being built or not easily, without having to know about the file obscured in the build directory.

:shrug: Maybe add a cmake option to build unused modules, then they can clearly see what is going on when they run ./b configure -i.

I think what I have just done is pretty clean. All that changes is the fs is not read-only and the roles directory is writeable by anyone, and then it'll be like a normal (gitignored) role for anyone who wants to generate and use it, including having an option to enable/disable it with the rest of the roles in ./b configure -i

I think what I have just done is pretty clean. All that changes is the fs is not read-only and the roles directory is writeable by anyone, and then it'll be like a normal (gitignored) role for anyone who wants to generate and use it, including having an option to enable/disable it with the rest of the roles in ./b configure -i

I'm thinking that we should put it in the build folder when we do CI and let people do it your way if they want to do it manually.

Is there a problem doing it this way? Having two separate spots to look for role files increases the complexity of NUClearRole.cmake a lot.

I think It would be nice to test the unused modules as a separate step in the pipline instead of testing It all together. Then atleast if the unsed doesnt pass we know it won't break anything in use.

@Y0sh1dk Great idea. I have made it its own pipeline step :+1:

Rather than doing this in python, why not just do it in CMake, in CMake you could just list all the folders in the modules dir, and then call the nuclear_role function. No need for generating anything

I have retooled this PR so that it uses cmake to call nuclear_role(${ALL_MODULES}). This did end up cleaner - thanks for the suggestion @TrentHouliston.
All the unrelated changes were necessary to make the role compile. The change to the RawSensors enum value name was a strange case where it seems that something had defined a macro or preprocessor definition for OK. I renamed that to EVERYTHING_OK, which resolved the error.


Infer uses up a lot of memory and becomes stuck

Hello!
While running infer on a Objective C project it uses a huge amount of memory and as a result (I assume) becomes stuck.
Here's the memory usage for the project:

I tried to run the infer with the flags infer --print-logs --debug to find if there was any particular file that was causing this behavior. Unfortunately, I could not understand from the ouput where it was getting stuck.
If you need any extra information, @priitlatt or @omelkova could provide it

It would be useful to know which phase, capture or analysis, is eating all the memory. Can you see which one of the infer-out/_stats/.json allocates a lot? Feel free to paste all their contents here.

@jvillard all of the files there were of the same size ~300-500B
@dulmarod the issue appeared with both -a linters and -a inferunfortunately sharing the actual logs is a bit complicated due to privacy issues (we are a CI service)

@UkuLoskit I meant the sizes reported inside the files: they contain statistics generated by infer about memory usage.

There have been lots of performance-related improvements to infer since this issue was created. Closing this for now for lack of data, but do feel free to reopen the issue with more information if the current version of infer (0.15.0) still exhibits this behaviour.


Add REQUIRES: asserts to lifetime_dependence lit tests.

 I'm not sure if they are all supported in non-asserts builds.

@swift-ci smoke test


Lightweight Deletes are now GA

Should the README be updated to say that Lightweight Deletes are now GA in 23.3? Is there anything that should be updated config-wise?

We'll update the README but we will need some code changes to make delete+insert the default strategy for current ClickHouse versions.


refactor(rewards): migrate old store keys

in an effort to keep the code base more stable and focus on cosmwasm key migrations are shelved


Mark status LED's as secondary entities

My HA now contains a plethora of pretty useless LED-entities.
Since HA 2021.11 it is possible to mark such entities as 'Diagnostic': https://developers.home-assistant.io/blog/2021/10/26/config-entity .
In order to update the Velbus-integration to do this, we need to be able to differentiate between these type of LED's and real light-entities. Can we add an attribute (to Channel? ) to them to mark them as such?
To elaborate: I think we should even consider add entity_registry_enabled_default=False to the Button-entities from Velbus. This prevents them from appearing automatically in the HA entities list, while the user can still enable them manually if desired. The VMBELO and VMBGPOD in my installation have now created over 50 entities each, most of which don't have any value at all.
A small illustration:

the button-lights are disabled by default (this is code in hass):
class VelbusButtonLight(VelbusEntity, LightEntity):
    """Representation of a Velbus light."""

    _channel: VelbusButton
    _attr_entity_registry_enabled_default = False

Ok, thank you for clarifying that. When looking at git blame I see that this was not yet the case when I added the integration to my HA, and this is not retroactive of course. I will manually clean out my HA-instance.
Some follow-up requests/thoughts:

add: _attr_entity_category = EntityCategory.DIAGNOSTIC to them as well. Maybe also to the Alarm-entities?
add _attr_entity_registry_enabled_default = False to the binary_sensor-entities representing the Velbus-button state.
You can simulate pressing the button by sending the correct messages ourself on the bus. ie. one 'button down' message, followed by 'button up' message. By adding a delay between the two, you can even simulate a long press. We could implement these as Button-entities and add them as EntityCategory.CONFIG to these devices?

the diagnostic idea is a good idea, and everyone should be able to ahndle this, its a verry small code change in hass.
same for the button entity, its a good idea but this is relative new in hass, so did not have time to look at it.
about the alarms and velbus-button, currently i do not know (in hass) that these are special channels, so i have no way to handle them seperatly inside hass.

in velbusaio we know these are special channels, so in theory it should be possible but this requires some work:
these steps below are the same for the 2 requests
1- create a new type of category (button and thermostatchannel or something similar)
2- make sure the get_categories in channels.py returns the correct type
3- in the hass component, handle these 2 types differently and make sure they end up in the correct entity for this type of category
4- build the hass entity

Hi @Cereal2nd , thanks for being so responsive!

about the alarms and velbus-button, currently i do not know (in hass) that these are special channels, so i have no way to handle them seperatly inside hass.

We can also think in reverse: which binary_sensors should be enabled by default? I think that enabling motion-detector channels by default makes sense (and even then: only the first channel per motion sensor), but all other channels could be disabled by default.
What you're proposing sounds fine. I also think that this library should contain the detection logic to categorize them into different categories, which the HA-integration can then use to configure the entities correctly.

yeah maybe this is something to think about
These are all nice ideas, but currently i do not have enough free time to implement this


Issue with the syntax in fluent meshing

When I am trying to use the below command in pyfluent it is throwing invalid syntax
meshing.tui(tgapi-util-get-minsize-face-zone-by-area "origin*")

Please can any one look into this

As tgapi-util-get-minsize-face-zone-by-area is a scheme function, the scheme_eval API is most suitable for it:
>>> import ansys.fluent.core as pyfluent
>>> meshing = pyfluent.launch_fluent(mode="meshing", show_gui=True)
>>> meshing.tui.file.read_mesh("elbow.msh.h5")
>>> meshing.scheme_eval.scheme_eval('(tgapi-util-get-minsize-face-zone-by-area "*")')
30


How to track of deleted users

Is there any good way to know when a user get deactivated from Slack. Like webhooks or something ?

Hi, @yashgandhi-32! Thanks so much for submitting this question! 🙇
You can try to use the user_changed event to track when changes happen to users - it will tell you when a user account is deleted. More info can be found here!
I hope this helps! :)

Ohk I will look into it thanks for sharing..will it work with events api ?

Thanks @hello-ashleyintech its worked. Last time I asked no one mentioned and I build a complex weird script to updated users. It works like charm


DELAYLOAD data import workaround (how is this actually done wtih C++? __asm?)

Imports of data can't be supported. A workaround is to explicitly handle the data import yourself by using LoadLibrary (or by using GetModuleHandle after you know the delay-load helper has loaded the DLL) and GetProcAddress.

If data is imported it's probably implemented by generating additional code to an invisible pointer. So how does that pointer actually get set? This article doesn't say, but suggests there's a "manual" way. Is it in the PE import table? It could use more detail than just leading us to think there's a solution. (Edited: Does the DELAYLOAD option just refuse to link in this case? Or can the program be patched at runtime to avoid bugs? I.e. Is the article suggesting abandoning DELAYLOAD or some kind of runtime patching it doesn't get into?)
P.S. Why doesn't DELAYLOAD offer a simpler option where instead of wrapping functions the consuming program/module can just call a "Load" routine before it touches anything in the DLL? (This hypothetical routine would be generated by the compiler for each instance of the import library.)

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

ID: 155172a5-829f-1869-ce1d-288427b234dc
Version Independent ID: 3933275f-c1f8-e13b-8213-3a972fec3a70
Content: Linker support for delay-loaded DLLs
Content Source: docs/build/reference/linker-support-for-delay-loaded-dlls.md
Product: visual-cpp
Technology: cpp-tools
GitHub Login: @corob-msft
Microsoft Alias: corob

Found some concrete evidence: https://stackoverflow.com/questions/5232912/how-to-use-delay-loading-with-a-dll-that-exports-c-classes
LINK : fatal error LNK1194: cannot delay-load 'two.dll' due to import
of data symbol '"__declspec(dllimport) const TwoClass::`vftable'"
(__imp_??_7TwoClass@@6B@)'; link without /DELAYLOAD:two.dll

@mick-p1982
Interesting questions, but probably boring answers. Delay loaded functions work because you don't know or (usually) care whether you're calling a function indirectly through a pointer fixed up at load time or through an pointer that was fixed up later at run time. The linker can work that magic with a helper function behind the scenes, so your delay-loaded calls look just like regular implicitly-loaded calls.
Data is a little tougher. If you declare some variable __declspec(dllimport) in your client app, it removes the indirection in the caller. You access the data directly, without going through a pointer. Those data addresses get patched up at load time. There isn't any indirection through a table that the helper can patch later when the DLL gets delay-loaded. So, to use data from a delay-loaded DLL, you have to explicitly get the data addresses yourself at run time, using GetProcAddress as described by the docs. It's exactly the same thing you'd do to reference data in any explicitly loaded DLL:
// This example assumes mydll.dll exports int nMyData
// Do something that loads the DLL first, then call:
HMODULE hMyDll = GetModuleHandle("mydll.dll");
if (NULL != hMyDll)
{
    int* pnMyData = static_cast<int*>(GetProcAddress(hMyDll, "nMyData"));
    // . . . do stuff with the pointer to data
}

As you discovered, the linker won't link if there are direct data references to DLLs you tell it to delay-load.
If you want to make a product suggestion, there's a feature built in to Visual Studio under Help > Send Feedback > Suggest a Feature.

Thanks @corob-msft I just felt the docs are a bit too mysterious on this topic and there's not much information out there on this subject (maybe because people normally find out the hard way by getting a LNK1194 error instead of proactively seeking out the answer). In this day and age maybe traditionally obtuse or incorrect MSDN docs can be easily patched up or elaborated on, I don't know.
Without knowing if it's a hard error or not it's not clear if use of __declspec(dllimport) has to be qualified on data or not to enable /DELAYLOAD use of the library. It seems it must based on that LNK1194 error, and maybe things get more dicey when the data is something like a vtable. Yesterday I modified a library that exported data to offer a preprocessor macro to put it into a /DELAYLOAD friendly mode. (Instead of using GetProcAddress it just has a "delayload" function that would simultaneously load the library and fill out the needed data fields, that are provided as an argument. I still think it would be possible to support data if an option was given to manually load the library... instead of the "too clever by half" approach of using function call magic.)


[WIP] Make repositoy topics manageable

Closes #25
Signed-off-by: Christian Berendt<EMAIL_ADDRESS>

According to the API documentation this should work. But it doesn't.

@gtema Works now. The problem was the accept header. This must be set depending on the previews used (see https://docs.github.com/en/rest/overview/api-previews).


Update references to the support page

Purpose of this pull request
This pull request (PR) makes minor updates to Automation Service articles in accordance with changes made to the Support page (which accessible from the "?" button in the upper-right of the UI). These articles were updated:

https://help.sumologic.com/docs/cse/automation-service/about-automation-service/
https://help.sumologic.com/docs/cse/automation-service/automation-service-bridge/

Issue number: CSOAR-356
Select the type of change:

[ ] Minor Changes - Typos, formatting, slight revisions
[x] Update Content - Revisions and updating sections
[ ] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - Updates, maintenance, and new packages for the site, Gatsby, React, etc

Agreed, @pkazmir-sumo. We need to add a link to where the API docs are now. But we can't until the dev work is done by CSOAR-362. Hopefully that will happen very soon.


Unable to resolve module.... .../shims/ReactNativeBridgeEventPlugin"

Curious if anyone's dealt with this issue.
I checked the directory, and ReactNativeBridgePlugin isn't available. Curious why this would be.
Wondering if it's an issue with my current version of React-Native, or the specific version of react-native-gesture-handler
"react-native": "0.48.4",
"react-native-gesture-handler": "^1.0.0-alpha.40",
"react-native-tab-view": "^0.0.74",

Please check compatibility matrix for gesture handler library. Apparently the version you are trying to use is not compatible with react native 48: https://github.com/kmagiera/react-native-gesture-handler#supported-configurations


Dev/feat kqlsyntaxvalidation

Overview/Summary
Provides KQL syntax validation for PRs.
Related Issues/Work Items
This PR fixes/adds/changes/removes

Adds syntax validation script (kpoineal)
Adds login step within relevant workflow with OIDC credentials for script as well as conditions prior to running tests (oZakari)
Fixes broken queries

Breaking Changes

PRs with KQL need to be validated and the label PR: Safe to Test ARG Queries :test_tube:  prior to allowing the KQL tests to run.

As part of this pull request I have

[x] Read the Contribution Guide and ensured this PR is compliant with the guide
[x] Checked for duplicate Pull Requests
[ ] Associated it with relevant GitHub Issues or ADO Work Items (Internal Only)
[x] Ensured my code/branch is up-to-date with the latest changes in the main branch
[x] Ensured PR tests are passing
[x] Performed testing and provided evidence (e.g. screenshot of output) for any changes associated to ARG queries
[ ] Updated relevant and associated documentation (e.g. Contribution Guide, Docs etc.)

Need to adjust the workflow triggers, so putting in draft for now.

Instead of having two scripts with the same validate comments function, can we combine them and just call the functions separately for the two worklow steps?

As discussed with Kyle, leaving this as is for the time and noting as something to be improved in the future.


Add indexer template

live demo from my original repo: https://aptos-full-stack-demo.vercel.app/
In this version, i removed the Source Code link in the root header.

Need to add it to the wizard flow. When adding it, make sure to only provide the nextjs framework option


Only show top scroll button on long pages after scroll up

This change is

LGTM. This is a nice improvement, @mjibson. Thank you.

❤ ––works perfectly, @mjibson


Question about FreeListAllocator

Hi mtrebi,
Thanks for the modification of making it running on Windows first. However I found places that confuse me a lot in FreeListAllocator.
First, is it a must that we have two header type "AdditionalHeader" & "FreeHeader"? I believe an additional header with storing size & padding is enough. And the m_free_list may become type of "SinglyLinkedList", Node type may become "SinglyLinkedList::Node".
Secondly, in the alloc implementation of FreeListAllocator. When adding new block/node due to rest of available memory. Checking "rest > 0" is not enough I believe, because every block must have a header. I checked "rest > sizeof(AdditionalHeader)" instead of "rest > 0", since I only have one additional header. If 0 < rest < sizeof(AdditionalHeader) then we cannot make it a block right?
How do you think of the thoughts above? I am just trying to figure out if it is necessary to have two headers and storing the block size repeatedly. Thanks and would love to hear from you.

First of all, my apologies for the soooooo late reply. I've been really busy the last weeks. I am sorry.
Regarding your first question, the answer is Yes. You can use one single struct for both purposes. But, this will (unnecessarily) increase the amount of data used for the FreeList nodes and thus reducing the amount of data that could be potentially used by the allocator. However, is not that bad.
The answer to your second question is Yes, we should make sure that we have enough space to actually create a new node. I totally agree.
padding will always be empty and that means you will waste 1 byte for block and *.This also makes me think if it
Regarding your second question, you are right in the sense that we need enough space to allocate the header, and we actually make sure of this in the code right before:
{
//...
}

Secondly, in the alloc implementation of FreeListAllocator. When adding new block/node due to rest of available memory. Checking "rest > 0" is not enough I believe, because every block must have a header. I checked "rest > sizeof(AdditionalHeader)" instead of "rest > 0", since I only have one additional header. If 0 < rest < sizeof(AdditionalHeader) then we cannot make it a block right?

I solved this problem using if (rest >= (sizeof(Node)+alignment)) instead if (rest > 0).


Using the rollout coordinates and stop gradient on representations for confidence head

This PR has 2 contributions:
1. Using the rollout coordinates for confidence head
As supplementary information section 4.1,

Several of the heads require predicted coordinates, therefore at training time we do a short rollout of the Diffusion Module from pure noise with 20 steps (Main Article Fig. 2c). No gradients are applied to this mini-rollout.

the predicted coordinates was generate by mini-rollout. On other hand, the denoised coordinates generate by diffusion training step is only one of the denoise step of the predict coordinates.
2. Apply stop gradient on representations and predict structure.
As supplementary information section 4.3.5

During training, a stop gradient is applied to the single and pair embeddings and predicted structure.

@gitabtion thank you Heng!


create repos for CONUS404 processing workflows

Move all CONUS404 processing workflows from here into their own repos. We should end with one repo for each of the following:

conus404_metadata
conus404_raw - conversion of 2D/3D files to zarr store
conus404_bias-adjusted - creation of CONUS404 BA zarr store from CONUS404 BA netcdfs available in data release

We will also need a new repo set up for the CONUS404 PGW processing to zarr, which is currently contained in #507

The following repos have been created and initial commits are completed:
conus404-metadata
conus404-raw
conus404-ba
conus404-pgw  (closes #507)

removed from hytest repo in #556


Chapter 11 - (11-ChapterBiasFairness.Rmd) - replace FP with FN

"-   If your intervention is assistive in nature (e.g., determining who
should receive a food subsidy), individuals may be harmed by failing
to intervene on them when they have need, so you may care more about
metrics that focus on false positives."
Above should be false negatives.

Should be fixed now. Thank you.


feat: add id to useCollectionData and useCollectionDataOnce hooks

Would be useful to have the id in the useCollectionData and useCollectionDataOnce hooks, specially to filter among different  documents. Maybe it could also be one of the parametes if it must be included i'll do it.

I found your PR while researching how to access the IDs while using the useCollectionData hook. You might want to have a look at the docs here which was the solution for me in the end. That approach also well with type safety and avoids that you accidentally add an additional id property to your documents.

Hey @VicenteMerino, I believe what @philippotto shared is the way to go in the future! This library formerly had an option to also store the document id but is was removed in favour of data transformers.
I believe it's cool that you created this PR but given that the decision against an explicit id was already made, it might be best if you close this PR :) Thanks!

@VicenteMerino As per the comments from @philippotto and @mauriceackel, we made the switch in v5 to use data transformers as this is the recommended approach by Firebase. As a side effect, it had the benefit of simplifying the code in react-firebase-hooks and maintained type safety.
Thank you for the suggestion, but we won't be switching back to the old approach, so I'll close this PR now


adjust test for slice due to typeshed changes

A change was made to typeshed to make slice a Generic, which is causing the mypy_nightly tests to fail.  More discussion here:
https://github.com/python/mypy/issues/18225
This fix should allow the CI to pass as well as the mypy_nightly runs.  See comment in code.

Ooops.  Deleted my branch by mistake, but restored it.  So should be good to go

Thank you for navigating the subtle differences between mypy/mpy nightly/pyright!


App crash on Android

I have a runtime error when running sharing on Android (working on iOS):
java.lang.ArrayIndexOutOfBoundsException: length=1; index=1
at nl.xservices.plugins.SocialSharing$2.run(SocialSharing.java:334)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:764)
Does it means something for you ?

How is the plugin invoked to produce this crash?

How is the plugin invoked to produce this crash?

I'm sorry I found a typo in appPackageName which was probably leading to this error.

I'm sorry I found a typo in appPackageName which was probably leading to this error.

@gatelli help my same issue with Android  11
working with other phones

I'm sorry I can't remember but as I said it was an error with my appPackageName

The version 6.0.3 the problem occurred yet.
I just install version from github and the problem was fix and works fine.


Prevent ProgressIndicator warnings by using an EmptyProgressIndicator

The Problem/Issue/Bug:
Resolve #313
How this PR Solves the Problem:
By providing an EmptyProgressIndicator, functionality is maintained while satisfying the cause of the warning.
Maybe it can be solved more elegantly, but the current version is the most concise way I could find.
The chosen solution is marked as obsolete due to the strong suggestion by JetBrains to move to Kotlin.
Manual Testing Instructions:
Open a Windows installation of an IDE and load a project stored on WSL.
Without the patch, warnings appear due to the background executions, with the patch, they no longer appear.
Related Issue Link(s):

Great work, thanks @AkibaAT!


Open Source Vtiger URL Path Fix Documentation

I added the /webservice.php link in the Vtiger documentation because it is required to get the Vtiger plugin to work on the open-source version of Vtiger.

Hello, @RCheesley yes please let me know when you can teach me that. I am in your inbox Jesse Ellis if you want to email me and/or we could meet on Google Meets if you have time.


Nextjs form id doesn't match server-rendered HTML

with uuid instead of nanoid, it now says "Error: Text content does not match server-rendered HTML." If I comment out devtools, it works fine.
Originally posted by @parazit13 in https://github.com/react-hook-form/devtools/issues/157#issuecomment-1182868631

I fixed it in #162 . And we create a beta release 4.2.2-beta.1.
Could you help us test in your project @parazit13?
cc @yangricardo

of course, thanks for the patch and heads up about it. I installed 4.2.2 and it works great!! @jsun969 @yangricardo

thanks @jsun969 for the patch.


The build plan should lose entries as they are provided by each /bin/build

If a buildpack’s /bin/build provides a dependency specified in the build plan, then the build plan entry for that dependency should not be provided to the next buildpack’s /bin/build. Otherwise, the same dependency may unintentionally be provided multiple times.
Notes

This makes it possible for buildpacks to provide basic/generic versions of dependencies that more specialized buildpacks could provide if added to the group.
This makes the provider key unnecessary in almost all cases.
This makes it easy for operators to override buildpack dependencies by placing custom buildpacks in front of the group.

Implementation
Option A) Map build plan entries to layers. Use launch = true and build = true in each build plan entry to determine whether a layer should been provided for launch or for other buildpacks. Automatically remove entries (or change the booleans) based on where/whether the layer was actually provided. Have a separate, special build plan notation for dependencies provided in the app directory. Fail the build if the build plan is not fully consumed.
Option B) Have the buildpacks write the names of the dependencies they provide to launch.toml. Ignore convention around launch = true and build = true. Fail the build if the build plan is not fully consumed.
I prefer option A, as it results in a build plan with a tighter contract as well as a mapping to the file contents of each entry.

An example would help (as usual).

Here's a simple example that ignores the launch and build keys, and also ignores how the buildpacks would mark a dependency as "provided":
Detect Phase
my.buildpack.one:
/bin/detect outputs:
[my-dep-one]
...

my.buildpack.two:
/bin/detect outputs:
[my-dep-two]
...
[my-dep-three]
...

Build Phase
Assuming my.buildpack.two is requesting my-dep-two from my.buildpack.one, and the other requested layers are provided by the buildpack requesting them.
my.buildpack.one:
/bin/build receives:
[my-dep-one]
...
[my-dep-two]
...
[my-dep-three]
...

/bin/build provides my-dep-one and my-dep-two.
my.buildpack.two:
/bin/build receives:
[my-dep-three]
...

/bin/build provides my-dep-tree.

Assuming my.buildpack.two is requesting my-dep-two from my.buildpack.one

How is it doing that? Surely my.buildpack.two should not know about the other buildpack - it only cares that my-dep-two is provided by something.

This proposal is problematic as there is not a a 1:1 correspondence between the entries in the build plan and the layers put down on disk.  For example, when a buildpack requests[openjdk-jre], the provider of that dependency might put down not only /openjdk-jre, but /memory-calculator and /jvmkill.  A second is example is that a buildpack might put [jvm-application] into the build plan, which is used by other downstream buildpacks both during detect and build phases, but no layer is ever created for it.  A final example is a buildpack request [npm] during detect, but that same buildpack providing a /node_modules layer.
This feels like an attempt to tighten the contract to prevent what will be a rare occurrence when it should just be clearly stated the buildpack groups (which are quite lightweight, so you can have many of them) should be created in such a way as to remove the possibility of dependency provisioning collision.  Tightening the contract here, without any evidence that this is a wide-spread problem is reducing our ability to innovate and create new patterns that do not already exist.

This proposal is problematic as there is not a a 1:1 correspondence between the entries in the build plan and the layers put down on disk. For example, when a buildpack requests [openjdk-jre], the provider of that dependency might put down not only /openjdk-jre, but /memory-calculator and /jvmkill

Buildpacks would request all three of those things instead of just openjdk-jre.

A second is example is that a buildpack might put [jvm-application] into the build plan, which is used by other downstream buildpacks both during detect and build phases, but no layer is ever created for it.

This is covered by:
"Have a separate, special build plan notation for dependencies provided in the app directory."

A final example is a buildpack request [npm] during detect, but that same buildpack providing a /node_modules layer.

That buildpack would request node_modules, as the current v3 node buildpacks do.

This feels like an attempt to tighten the contract to prevent what will be a rare occurrence when it should just be clearly stated the buildpack groups (which are quite lightweight, so you can have many of them) should be created in such a way as to remove the possibility of dependency provisioning collision.

Without this feature, it would be difficult to implement manifest dependency overrides, which are a current feature of the CF buildpacks. Additionally, the current implementation puts the onus on operators and developers to know about every layer name their chosen buildpacks provide.
That said, I think Option B satisfies all of your constraints and would solve the problem without tightening the contract.

I don’t believe that it should be a requirement that buildpacks requesting a dependency have internal knowledge of all of the dependencies that another buildpack will provide. For example, a riff buildpack only needs to request that a JRE be present.  It should *not * need to know that some JRE providers will provide an additional memory calculator and jvmkiller whereas other JRE providers will not.  Making all provided dependencies explicit in the build plan creates a very tight coupling where two buildpacks essentially can only depend on one another with deep internal knowledge rather than allowing buildpacks be polymorphic dependency providers that can transparently substitute in for one another.
Also the requirement for both Option A and B

Fail the build if the build plan is not fully consumed.
is problematic as some build plan entries are never meant to be consumed.  At the moment [jvm-application], [node-application], and others like these are used as markers that later buildpacks such as the riff buildpack use to make decisions during their own processing.  Removing them, or requiring them to be removed and preventing them from being visible during the entire execution of the build phase constrains the flexibility of the buildpack implementations

What if, at least for now, we condense this proposal down to:
A buildpack may erase any number of dependencies from the build plan in /bin/build if it chooses, indicating that subsequent /bin/builds should not consider that dependency. (No strong opinions about how /bin/build would specify the names of the dependencies to remove.)
I would still prefer a tighter contract, because I think the current contract is somewhat difficult for new buildpack authors to reason about, but this would solve the problem that I'm trying to solve. It would also be an additive, non-breaking change.

A buildpack may erase any number of dependencies from the build plan in /bin/build if it chooses

It's news to me that a build plan contains dependencies. Is that explicit? The first reference I can find to "dependency" is in the "build" phase, and it's a bit vague there (doesn't mention anything to do with the build plan).

@sclevine Definitely a better choice.  How would such a behavior be implemented since stdout is already occupied for logging?

@dsyer You've hit upon one of the assumptions I was arguing against here.  The build plan was originally conceived as a way to create an inventory of dependencies contributed by buildpacks, conveniently allowing tools to observe and report on them.  However, the design is much more generic than that, acting as a whiteboard pattern that both communicates more than just dependencies and doesn't necessary report all dependencies at the same time.  My vote is for this looser design to continue (it's been very helpful for my buildpacks) rather than restricting it to the original idea.

@nebhale @dsyer I really like where this ended up. Even ignoring the original intent of this change, the detection interface is much more consistent with build. Let me know what you think!

I'm ready to see a spec PR for the change.


BUG: parameter 'args' of optimize.root_scalar() is not usable

Describe your issue.
I can't pass varible to parameter 'args' because it missmatch with 'root_scalar..fprime()' and got this error
TypeError: root_scalar.<locals>.fprime() takes 1 positional argument but 2 were given
From now is my investigation.
The problem occur at scipy\optimize\_root_scalar.py at line 303
        if not fprime:
            # approximate fprime with finite differences

            def fprime(x):
                # `root_scalar` doesn't actually seem to support vectorized
                # use of `newton`. In that case, `approx_derivative` will
                # always get scalar input. Nonetheless, it always returns an
                # array, so we extract the element to produce scalar output.
                return approx_derivative(f, x, method='2-point')[0]

As you see, when user not specified fprime, it will create fprime based on approx_derivative which i believed it is finite difference. BTW, this new fprime doesn't care about arguments given from the parameter  args so it result in argument missmatch.
Reproducing Code Example
import scipy.optimize as optimize
import scipy
def cost_func(x):
    return (x-1) **2
def cost_func_args(x,args):
    return (x-1) **2

sol = optimize.root_scalar(cost_func, x0=0)

print(scipy.__version__)
print(sol)
sol = optimize.root_scalar(cost_func_args, x0=0,args=(None))
print(sol)

Error message
1.11.2
      converged: True
           flag: converged
 function_calls: 54
     iterations: 27
           root: 0.9999999894647739
Traceback (most recent call last):
  File "C:\Users\admin\Documents\GitHub\neural_vis\scipy_bug.py", line 14, in <module>
    sol = optimize.root_scalar(cost_func_args, x0=0,args=(None))
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\admin\AppData\Local\Programs\Python\Python311\Lib\site-packages\scipy\optimize\_root_scalar.py", line 315, in root_scalar
    r, sol = methodc(f, x0, args=args, fprime=fprime, fprime2=None,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\admin\AppData\Local\Programs\Python\Python311\Lib\site-packages\scipy\optimize\_zeros_py.py", line 306, in newton
    fder = fprime(p0, *args)
           ^^^^^^^^^^^^^^^^^
TypeError: root_scalar.<locals>.fprime() takes 1 positional argument but 2 were given

SciPy/NumPy/Python version and system information
1.11.2 1.25.2 sys.version_info(major=3, minor=11, micro=5, releaselevel='final', serial=0)
Build Dependencies:
  blas:
    detection method: pkgconfig
    found: true
    include directory: /c/opt/64/include
    lib directory: /c/opt/64/lib
    name: openblas
    openblas configuration: USE_64BITINT= DYNAMIC_ARCH=1 DYNAMIC_OLDER= NO_CBLAS=
      NO_LAPACK= NO_LAPACKE= NO_AFFINITY=1 USE_OPENMP= SKYLAKEX MAX_THREADS=2
    pc file directory: c:/opt/64/lib/pkgconfig
    version: 0.3.21.dev
  lapack:
    detection method: pkgconfig
    found: true
    include directory: /c/opt/64/include
    lib directory: /c/opt/64/lib
    name: openblas
    openblas configuration: USE_64BITINT= DYNAMIC_ARCH=1 DYNAMIC_OLDER= NO_CBLAS=
      NO_LAPACK= NO_LAPACKE= NO_AFFINITY=1 USE_OPENMP= SKYLAKEX MAX_THREADS=2
    pc file directory: c:/opt/64/lib/pkgconfig
    version: 0.3.21.dev
  pybind11:
    detection method: config-tool
    include directory: unknown
    name: pybind11
    version: 2.10.4
Compilers:
  c:
    commands: cc
    linker: ld.bfd
    name: gcc
    version: 10.3.0
  c++:
    commands: c++
    linker: ld.bfd
    name: gcc
    version: 10.3.0
  cython:
    commands: cython
    linker: cython
    name: cython
    version: 0.29.36
  fortran:
    commands: gfortran
    linker: ld.bfd
    name: gcc
    version: 10.3.0
  pythran:
    include directory: C:\Users\runneradmin\AppData\Local\Temp\pip-build-env-ltcmez9y\overlay\Lib\site-packages/pythran
    version: 0.13.1
Machine Information:
  build:
    cpu: x86_64
    endian: little
    family: x86_64
    system: windows
  cross-compiled: false
  host:
    cpu: x86_64
    endian: little
    family: x86_64
    system: windows
Python Information:
  path: C:\Users\runneradmin\AppData\Local\Temp\cibw-run-j5_khsjf\cp311-win_amd64\build\venv\Scripts\python.exe
  version: '3.11'

This was fixed by gh-19091. The code is now:
https://github.com/scipy/scipy/blob/f1e00700f2143158c6f08a426fdc097dea3a0c37/scipy/optimize/_root_scalar.py#L46-L50
but it was not backported to 1.11.2 because the milestone was added as 1.12.0. The fix will be present in 1.12.0


Union produces anyOf instead of oneOf for OpenAPI generation

First Check

[X] I added a very descriptive title to this issue.
[X] I used the GitHub search to find a similar issue and didn't find it.
[X] I searched the FastAPI documentation, with the integrated search.
[X] I already searched in Google "How to X in FastAPI" and didn't find any information.
[X] I already read and followed all the tutorial in the docs and didn't find an answer.
[X] I already checked if it is not related to FastAPI but to Pydantic.
[X] I already checked if it is not related to FastAPI but to Swagger UI.
[X] I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

[X] I commit to help with one of those options 👆

Example Code
from typing import Literal, Union
from pydantic import BaseModel, Field

class Cat(BaseModel):
    pet_type: Literal['cat']
    meows: int

class Dog(BaseModel):
    pet_type: Literal['dog']
    barks: float

class Pet(BaseModel):
    __root__: Union[Cat, Dog] = Field(..., discriminator='pet_type')

Pet.schema_json()

Description
Hi all,
Example from https://pydantic-docs.helpmanual.io/usage/types/#discriminated-unions-aka-tagged-unions:
Using the class Pet above in FastAPI to allow either Cat or Dog as an input leads to an OpenAPI.json which makes Pet like (printed as yaml)
Pet:
  anyOf:
  - $ref: '#/components/schemas/Cat'
  - $ref: '#/components/schemas/Dog'

  discriminator:
    propertyName: pet_type

both OpenApi (https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/) and the specification https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.2.md#discriminatorObject linked by the pydantic docs (link on top) state that it should be oneOf.
I think it's a pydantic issue, But there was already an issue for pydantic which was closed without resolve:
https://github.com/samuelcolvin/pydantic/issues/656
So I open it here, because it may be more relevant for FastAPI, since it leads to an incorrect OpenAPI file. Let me know if you think differently.
Best
Stefan
Operating System
Linux, Windows
Operating System Details
No response
FastAPI Version
0.75.0
Python Version
Python 3.9.7
Additional Context
No response

While this might be a valid issue (I also encountered this bug and am currently using some ugly workarounds :grimacing:), the problem has nothing to do with fastapi. Schema generation is directly done by pydantic, and fastapi has no influence on the result. I know that the previous pydantic issue was closed by the author, but I still think its a valid issue, so feel free to open a new one there. If no change is possible for backwards compatibility reasons, I would at least like to see a configuration parameter or similar.

+1 👍

I ran into this problem as well when using openapi-generator to generate a TypeScript SDK from an anyOf discriminated union. The generated code looked incorrect when my models used anyOf, but worked just fine once I switched to oneOf.
My workaround was to modify our openapi schema post-generation using the following code:
# openapi_utils.py

def sub_oneof_for_anyof_in_discriminated_unions(openapi_schema: Dict[str, Any]) -> None:
    """
    Modify the provided OpenAPI schema so that all models that represent a discriminated union use the `oneOf`
    polymorphic behavior as opposed to the `anyOf` behavior that is auto-generated by FastAPI.

    For example, the auto-generated object:

    Pet:
      anyOf:
      - $ref: '#/components/schemas/Cat'
      - $ref: '#/components/schemas/Dog'
      discriminator:
        propertyName: pet_type

    would become:

    Pet:
      oneOf:
      - $ref: '#/components/schemas/Cat'
      - $ref: '#/components/schemas/Dog'
      discriminator:
        propertyName: pet_type

    :param openapi_schema: A dict representation of a full OpenAPI spec
    """
    for schema_model in openapi_schema["components"]["schemas"].values():
        _sub_oneof_for_anyof_in_discriminated_unions_recursive_helper(schema_model)

def _sub_oneof_for_anyof_in_discriminated_unions_recursive_helper(obj: Dict[str, Any]) -> None:
    """
    Recursive helper function for `sub_oneof_for_anyof_in_discriminated_unions()`.

    Given a dict of an openapi schema object such as `{"type": object", "properties": [...]}`, check to see if
    it is an `anyOf` discriminated union. We define an `anyOf` openapi discriminated union as an object that:
      1. Has an `anyOf` key
      2. Has a `discriminator` key

    If the object is a discriminated union, substitute the `oneOf` key in place of the `anyOf`. After checking the
    provided object and making a substitution if necessary, proceed to recur on any sub-properties of that object
    and apply the same behavior to those.
    """
    if "anyOf" in obj and "discriminator" in obj:
        # This is where the action happens. We've gotten to an object that represents a discriminated union. Now
        # we can swap out the `anyOf` key for a `oneOf` key.
        obj["oneOf"] = obj.pop("anyOf")

    # determine whether or not the object is actually an {allOf: [list of other objects]}
    is_all_of_object: bool = "allOf" in obj.keys()

    # try to get the "type" of the object
    type_ = obj.get("type", None)
    if type_ is None and (not is_all_of_object):
        # object doesn't have a type, this is a dead end
        return

    if is_all_of_object:
        # When an object is "allOf" then we don't handle the object's properties directly. Rather, we iterate
        # through the array of objects that make up the "allOf" and process each of them individually.
        all_of_model: Dict[str, Any]
        for all_of_model in obj["allOf"]:
            _sub_oneof_for_anyof_in_discriminated_unions_recursive_helper(all_of_model)
    elif type_ == "object":
        # recur through the object's properties to ensure each sub-object is considered
        for sub_property in obj.get("properties", {}).values():
            _sub_oneof_for_anyof_in_discriminated_unions_recursive_helper(sub_property)
    elif type_ == "array":
        # For array types, we actually want to operate on the "items" sub-object which describes what the array
        # actually contains.
        _sub_oneof_for_anyof_in_discriminated_unions_recursive_helper(obj["items"])
    else:
        # dead end, dealing with a primitive like "string" or "integer"
        return

# main.py
openapi_schema = fastapi.openapi.utils.get_openapi(...)
openapi_utils.sub_oneof_for_anyof_in_discriminated_unions(openapi_schema)

I followed up with https://github.com/samuelcolvin/pydantic/pull/4335 for a more long-term fix that would cause Pydantic to generate oneOf in place of anyOf.

What's the status of this? Running into the same issue (different code gen tool).

Thanks so much for taking this up @MaxwellPayne! We just upgraded to the new pydantic and now "oneOf" is added to the schema in case we have a discriminated union. This also works perfectly with FastAPI, when we use the model beyond the "top level field" of the endpoint (speaking both for request and response).
To have the discriminated union as a type in "top level field" (request body, response body), I tried to use typing.Annotated to create a intermediate Type which is discriminated (to provide it as a input to FastAPI).
If I use that approach it still provides anyOf instead of oneOf. Not sure if that is a bug or my approach is wrong...
Here is a minimal example (fastapi==0.89.1, pydantic==1.10.4)
from fastapi import FastAPI, status

from typing import Literal, Union, Annotated
from pydantic import BaseModel, Field

# pydantic schemas

class Mammal(BaseModel):
    mammaltest: str

class Cat(Mammal):
    pet_type: Literal['cat']
    meows: int

class Dog(Mammal):
    pet_type: Literal['dog']
    barks: float

"""This can directly be used as root field for an endpoint"""
MammalBase = Annotated[Union[Dog, Cat], Field(discriminator="pet_type")]

class MammalContainer(BaseModel):
    """Includes a mammal as a field"""
    pet: MammalBase
    n: int

# FastApi

app = FastAPI()

@app.post(
    "/mammal-container-test/",
    response_model=MammalContainer,
    description="Test endpoint",
    status_code=status.HTTP_200_OK,
)
async def mammal_test(mammal_container: MammalContainer):
    """This works perfect both for request and response model and has oneOf"""
    return mammal_container

@app.post(
    "/mammal-base-test/",
    response_model=MammalBase,
    description="Test endpoint",
    status_code=status.HTTP_200_OK,
)
async def mammal_test(mammal_base: MammalBase):
    """This one still provides anyOf"""
    return mammal_base


close connection on server.close()

Relates to webrtc-rs/webrtc#76

Realized there are more places to fix this in the turn package.


Codeql workflows

This PR includes a new workflow for running and advanced setup of Codeql. It is a reusable workflow to be called in a project's CI pipeline.
The configuration of the job ensures that the scan only searches for high or critical severity errors with a high degree of precision.
There are also updates to the README to explain how to call in a pipeline.
Trello: https://trello.com/c/nqaYGM9f/3279-implementation-of-codeql

Hi @ChrisBAshton, yes, I did consider doing it that way. Unfortunately, we need to use an advanced setup for codeQL. This means we need to write our own workflows to include all the additional configurations we would like. As I understand it, enabling via the API would only permit us to use the default settings. Another thing to consider is that we will likely have many more scans running as part of the CI pipeline. Initially these will grow to be SAST and SCA scans with SNYK. But further down the line, we will have IaC, Container and DAST scans too. So I feel a common approach is probably the best way to go. Otherwise we'll be using the govuk-sass-config app for CodeQL and the govuk-infrastructure repo for most other things.

Forgot to mention:
— It looks like the test runs are failing, for example the latest one is failing with You have an error in your yaml syntax on line 23).

We already have a reusable workflow for Ruby linting. If we broadened that existing workflow to be "Ruby linting and analysis" then we could add the CodeQL jobs to that workflow and then they'd run automatically for all our Ruby projects with no need for additional configuration/boilerplate/pain.

Also, how does this relate to the CodeQL findings that already appear in https://github.com/alphagov/support/security/code-scanning? (Would it filter them? duplicate them? not affect them?)

Also, how does this relate to the CodeQL findings that already appear in https://github.com/alphagov/support/security/code-scanning? (Would it filter them? duplicate them? not affect them?)

They remain unaffected. No duplicates are made and no alerts already raised are removed in the evert of increased filtering.

Forgot to mention:

It looks like the test runs are failing, for example the latest one is failing with You have an error in your yaml syntax on line 23).
We already have a reusable workflow for Ruby linting. If we broadened that existing workflow to be "Ruby linting and analysis" then we could add the CodeQL jobs to that workflow and then they'd run automatically for all our Ruby projects with no need for additional configuration/boilerplate/pain.

I've resolved the syntax issue.
OK brilliant, thank you for point this out to me. I was hoping to come across something like this so we could add the SAST workflows into all apps efficiently. I'll make these changes now as it's a much better way of doing it.

Forgot to mention:
* It looks like the test runs are failing, for example [the latest one](https://github.com/alphagov/govuk-infrastructure/actions/runs/5977691343) is failing with `You have an error in your yaml syntax on line 23`).

* We already have a [reusable workflow for Ruby linting](https://github.com/alphagov/govuk-infrastructure/blob/main/.github/workflows/rubocop.yml). If we broadened that existing workflow to be "Ruby linting and analysis" then we could add the CodeQL jobs to that workflow and then they'd run automatically for all our Ruby projects with no need for additional configuration/boilerplate/pain.

The failing test issue is now resolved.
I like the idea of using the Rubocop way of implementation - I've suggested an adapted version detailed in a comment below.

Building on the idea to embed this in the Rubocop workflow, I've reengineered it so that there is a code-scanning workflow with Rubocop, Brakeman, and CodeQL nested inside. In the future, we can add additional code scanning tools here and modify them without requiring changes to the workflows on other repos.
I don't think we should embed the CodeQL job in the Rubocop workflow as I think that could be confusing as it doesn't feel like a natural home for it.
We would need to amend the repos calling the rubocop job at the moment so instead call the code-scans workflow. However, it would be a one-off change that would give us the ability to make changes to code scanning tasks in the future and have the changes instantly effective across all repos.

I've tested the workflow from another repo and am happy that it is working as expected


Align dependencies

Match internal versions

Coverage remained the same at 93.771% when pulling 787fe5bafb4c25d6460bb27c68d63d8260a672f1 on tgianos:allignDependencies into f0219f7a9dbab9f8bf717481d04685f18ec721aa on Netflix:4.1.x.


What licence is this project published under?

It's mentioned in the readme that the project is based on or inspired from yaqlator which has an MIT licence.

@Xorso any thoughts on this question?

Apologies for the long delay. We are going to stick with the MIT License and will get the LICENSE file added.