Promise.all returns a null value when using BigInt in a Where condition in findUnique

Bug description
When using findUnique, if you use a BigInt in the where condition, Promise.all returns a null value. If you use a data type other than BigInt, it returns a normal lookup result, not a null value. Even if you use a BigInt, it returns a normal lookup result if you don't use Promise.all.
findFirst is handled correctly with Promise.all, even when using a BigInt in the where condition.
Currently, this issue occurs when findUnique uses a BigInt in the where condition when using Promise.all.
This was not an issue in Prisma version 4.9.x, but has been an issue since 4.10.x.
How to reproduce

Expected behavior
No response
Prisma information

// Add your schema.prisma

generator client {
  provider        = "prisma-client-js"
  output          = "../../clients/account"
  previewFeatures = []
}

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

model ptest1 {
  id   BigInt @id @default(0)
  desc String @db.VarChar(50)
}

model ptest2 {
  id   Int @id
  desc String @db.VarChar(50)
}

// Add your code using Prisma Client
import { PrismaClient } from "../prisma/clients/account";

const prisma = new PrismaClient();

(async () => {

    const jobs1 = [];
    for (let i = 0; i < 3; ++i) {
        jobs1.push(
            new Promise<string | undefined>(async resolve => {
                const player = await prisma.ptest1.findUnique({
                    where: {
                        id: 1n
                    }
                });
                resolve(player?.desc);
            })
        );
    }

    const jobs2 = [];
    for (let i = 0; i < 3; ++i) {
        jobs2.push(
            new Promise<string | undefined>(async resolve => {
                const player = await prisma.ptest1.findFirst({
                    where: {
                        id: 1n
                    }
                });
                resolve(player?.desc);
            })
        );
    }

    const jobs3 = [];
    for (let i = 0; i < 3; ++i) {
        jobs3.push(
            new Promise<string | undefined>(async resolve => {
                const player = await prisma.ptest2.findUnique({
                    where: {
                        id: 1
                    }
                });
                resolve(player?.desc);
            })
        );
    }

    const result1 = await Promise.all(jobs1);  // null
    const result2 = await Promise.all(jobs2);  // not null
    const result3 = await Promise.all(jobs3);  // not null

})();

Environment & setup

OS: Windows, RockyOS
Database: MySQL
Node.js version: 18.14.2

Prisma Version
prisma                  : 4.11.0
@prisma/client          : 4.11.0
Current platform        : windows
Query Engine (Node-API) : libquery-engine 8fde8fef4033376662cad983758335009d522acb (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 8fde8fef4033376662cad983758335009d522acb (at<EMAIL_ADDRESS>Format Wasm             : @prisma/prisma-fmt-wasm 4.11.0-57.8fde8fef4033376662cad983758335009d522acb
Default Engines Hash    : 8fde8fef4033376662cad983758335009d522acb
Studio                  : 0.483.0

Probably a duplicate of https://github.com/prisma/prisma/issues/18096?

Probably a duplicate of #18096. Can you confirm?

Yes, you're right, it's the same issue.

Hey, thanks for the report! This issue should be fixed by https://github.com/prisma/prisma-engines/pull/3818. I'm not entirely sure the fix will make it to the 4.12.0 release. So either this release or the next one.


Simple 2d rotation example

Objective
Some new bevy users are unfamiliar with quaternions and have trouble working with rotations in 2D.
There has been an issue raised with glam to add helpers to better support these users, however for now I feel could be better to provide examples of how to do this in Bevy as a starting point for new users.
Solution
I've added a 2d_rotation example which demonstrates 3 different rotation examples to try help get people started:

Rotating and translating a player ship based on keyboard input
An enemy ship type that rotates to face the player ship immediately
An enemy ship type that rotates to face the player at a fixed angular velocity

I also have a standalone version of this example here https://github.com/bitshifter/bevy-2d-rotation-example but I think it would be more discoverable if it's included with Bevy.

Looks like there was some kind of infrastructure problem which failed the build.
error: could not download file from 'https://static.rust-lang.org/rustup/release-stable.toml' to '/tmp/rustup-updateeSftq9/release-stable.toml': failed to make network request: error sending request for url (https://static.rust-lang.org/rustup/release-stable.toml): connection error:

bors retry

it's bors try 👍

bors try

related to https://github.com/bevyengine/bevy/pull/2441, and I love the amount of comments here

bors r+

@bitshifter, once you fix the clippy lints I'll merge this in :)

bevy retry

bors retry


feat(logger): check if terminal supports colors as default value

This PR uses the supports-color module to determine if the terminal that is running karma supports colors and sets the initial value of useColors to what supports-color determines. This value was previously hard-coded to true.
Users can still overwrite the setting to whatever they want in their config and the logger will respect that config value.

@googlebot I consent.

Thanks, please rebase or otherwise clean up the diff.

All the other changes keep getting added by the pre-commit hook so I assumed they were supposed to go with the change.

Sorry for the delay I had to fix appveyor.
I think you need to
$git rebase --hard HEAD~2 # remove dcce324ec88e5a434c4bffc774470e081db1ca2a and 40a8f07eb5b84ed7fb0adc162eb673e32035dcfa
$git checkout master
$git pull upstream master
$git checkout no-colors-when-not-supported
$git rebase master
This should put your change on top of the existing master with none of the extra commits.

Sorry for the delay I had to fix appveyor.

No worries 😺

:white_check_mark: Build karma 2410 completed (commit https://github.com/karma-runner/karma/commit/ecfd27fad9 by @johnjbarton)

:white_check_mark: Build karma 2439 completed (commit https://github.com/karma-runner/karma/commit/a62a1f274f by @johnjbarton)

Is this PR still relevant for you @koddsson ?

@jginsburgn I'm ok with closing this.

Ok. Thanks for updating this :)


feat(api): Integrate @opentelemetry/api-logs package into @opentelemetry/api as experimental

Fixes #4400
Migrated api logs package functionality to api package as experimental,
My plan is to delete older project as a different PR, same as updating dependencies using api-logs in other packages.

@open-telemetry/javascript-approvers please take a look, this should be really straightforward, is just moving code around and reusing util code that was duplicated.

My plan is to delete older project as a different PR, same as updating dependencies using api-logs in other packages.

Why delete in a separate PR? If they were done in the same commit, then git would (most likely) recognize the files as having been moved. Then later git --follow ... commands like git log would be able to see the commit history through the moves.

My plan is to delete older project as a different PR, same as updating dependencies using api-logs in other packages.

Why delete in a separate PR? If they were done in the same commit, then git would (most likely) recognize the files as having been moved. Then later git --follow ... commands like git log would be able to see the commit history through the moves.

@trentm I was trying to make it easier for review having the updated files below the hundreds :) is fine for me I will include all changes here.

having the updated files below the hundreds :)

Whoa, will there be 100s? :) I suppose there will be the delete of all the meta files like .eslintignore, etc.
However, if git recognizes the file moves, then the diff for the .ts files will be small or nothing.

We discussed introducing these changes would cause issues to users using Node.js < 12.7 and/or typescript <4.7, there is a proposal to skip this changes and move logs API directly to API package once formal review is done.

How are things coming with the sdk-logs package? I don't know where the best place to look is for information about that.


Save source msg to dlq

I noticed a TODO on line 149 of main.rs:
// TODO: Would be good to include the actual dropped message here but my rust skill issues are preventing me from doing so

So I thought I'd give it a try :) my rust skills are fairly rudimentary also, but this currently compiles, and I'm going to poke around and do some testing now.
Changes

Added two new columns to the DeadLetter table

err_kind: Integer 0 for a DecodeError, 1 for a ProcessError, since we weren't saving any of the former to the db.
source: Text, which is a UTF-8 encoded string from the Vec<u8> message that caused the error.

Previously only ProcessErrors were being saved, so I adjusted that to save DecodeErrors as well (using -1 for the seq)
refactored the ProcessError struct - since they were pretty similar enums, I adjusted it to be a struct with a ProcessErrorKind enum to differentiate between the two kinds.  this way, we're able to save the one struct to the dead letter, rather than needing to handle both enum types.

This was just an attempt to tackle that TODO I noticed in the code, so please call out anything that could be adjusted, as you see fit!

Thanks for this!
I'll take a look some time next week!

@DrewMcArthur Thanks so much for this!
I just pushed a few commits, the main thing I changed is storing err_msg as a blob because it's not valid utf8 (it's a cbor msg/frame).

Just deployed this to prod and it's working well, thanks again!


Global: Fix package.json metadata and register on NPM

package.json updated, to be reviewed before publishing

Done


x/net: incorrect sync.Pool usage leads to EINVAL errors on WriteBatch (sendmmsg)

What version of Go are you using (go version)?

$ go version
go version go1.19 linux/arm64

with a current version of x/net:
require golang.org/x/net v0.0.0-20220822230855-b0a4917ee28c

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/parallels/.cache/go-build"
GOENV="/home/parallels/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/parallels/src/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/parallels/src/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/parallels/bin/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/parallels/bin/go/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/parallels/src/go/src/github.com/lucas-clemente/quic-go/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1105120780=/tmp/go-build -gno-record-gcc-switches"

What did you do?
I'm adding support for WriteBatch to quic-go. Batching writes of QUIC (UDP) packets leads to a significant speedup of QUIC throughput, due to the reduced number of syscalls. Some connections set OOB, others don't, therefore the OOB field in the ipv{4,6}.Message will sometimes be set, other times it won't.
What did you expect to see?
I expect calls to WriteBatch to succeed.
What did you see instead?
Calls to WriteBatch occasionally return a sendmmsg: invalid argument error. I wrote a minimal example that reproduces the bug (even in the Go Playground): https://go.dev/play/p/lALtpTKEgw5
Why does this happen?
A sync.Pool is used to avoid allocations of the msghdr struct: https://cs.opensource.google/go/x/net/+/b0a4917e:internal/socket/rawconn_mmsg.go;l=39-40.
When the pool returns a msghdr where the Control and Controllen is set (this happens if the previous user of the struct set OOB), it is not properly cleared if no OOB is set: https://cs.opensource.google/go/x/net/+/b0a4917e:internal/socket/msghdr_linux.go;l=14-16.
This leads to Control pointing to a memory location that might have already been reused between the two invocations. The kernel will thus see an invalid mmsghdr passed to the sendmmsg, and (rightfully) return an EINVAL error.
Update: Here's a fix: https://go-review.googlesource.com/c/net/+/425914.

cc @neild @ianlancetaylor


[API Integration] EOL

Note we previously integrated via CommonCrawl, and would like to integrate via API now.
Provider API Endpoint / Documentation

https://eol.org/docs/what-is-eol/data-services
SECTIONS BELOW THIS POINT NEED TO BE WORKED ON PRIOR TO INTEGRATION
Provider description

Licenses Provided

Provider API Technical info

Checklist to complete before beginning development

No development should be done on a Provider API Script until the following info is gathered:

[ ] Verify there is a way to retrieve the entire relevant portion of the provider's collection in a systematic way via their API.
[ ] Verify the API provides license info (license type and version; license URL provides both, and is preferred)
[ ] Verify the API provides stable direct links to individual works.
[ ] Verify the API provides a stable landing page URL to individual works.
[ ] Note other info the API provides, such as thumbnails, dimensions, attribution info (required if non-CC0 licenses will be kept), title, description, other meta data, tags, etc.
[ ] Attach example responses to API queries that have the relevant info.

General Recommendations for implementation

The script should be in the src/cc_catalog_airflow/dags/provider_api_scripts/ directory.
The script should have a test suite in the same directory.
The script must use the ImageStore class (Import this from
src/cc_catalog_airflow/dags/provider_api_scripts/common/storage/image.py).
The script should use the DelayedRequester class (Import this from
src/cc_catalog_airflow/dags/provider_api_scripts/common/requester.py).
The script must not use anything from
src/cc_catalog_airflow/dags/provider_api_scripts/modules/etlMods.py, since
that module is deprecated.
If the provider API has can be queried by 'upload date' or something similar,
the script should take a --date parameter when run as a script, giving the
date for which we should collect images. The form should be YYYY-MM-DD (so,
the script can be run via python my_favorite_provider.py --date 2018-01-01).
The script must provide a main function that takes the same parameters as from
the CLI. In our example from above, we'd then have a main function
my_favorite_provider.main(date). The main should do the same thing calling
from the CLI would do.
The script must conform to PEP8. Please use pycodestyle (available via
pip install pycodestyle) to check for compliance.
The script should use small, testable functions.
The test suite for the script may break PEP8 rules regarding long lines where
appropriate (e.g., long strings for testing).

Examples of other Provider API Scripts

For example Provider API Scripts and accompanying test suites, please see

src/cc_catalog_airflow/dags/provider_api_scripts/flickr.py and
src/cc_catalog_airflow/dags/provider_api_scripts/test_flickr.py, or
src/cc_catalog_airflow/dags/provider_api_scripts/wikimedia_commons.py and
src/cc_catalog_airflow/dags/provider_api_scripts/test_wikimedia_commons.py.

-EOL provides 1)Structured Data 2) Classic API (https://eol.org/docs/what-is-eol/data-services)
-EOL is under MIT-LICENSE (https://github.com/EOL/eol/blob/master/MIT-LICENSE.txt)
-they have stable API currently(in context of "classic API" however not sure about structured Data)
-they have stable landing page url
-example https://eol.org/api/search/1.0.json?q=Pinus%2Bcontorta&page=1&key=
However, i am not sure about license and if all required endpoints exist. If someone can review i would like to work on it.

Flagging here that the first two items on the checklist are crucial to moving forward, and this provider cannot be ingested until those have been verified.
@mathemancer will take a look when time allows.


Typo in Dockerfile causes ARCH to be ignored during build process

What this PR does / why we need it:
arm64 support was recently added in #680 however there was a typo in the Dockerfile that sneaked through during the review process.  This PR fixes that typo.  I have already tested this in my own arm64 environment and was able to produce working images.
Which issue(s) this PR fixes:
Fixes https://github.com/vmware-tanzu/carvel-kapp-controller/issues/803
Does this PR introduce a user-facing change?
NONE

Additional Notes for your reviewer:
Review Checklist:

[ ] Follows the developer guidelines
[ ] Relevant tests are added or updated
[ ] Relevant docs in this repo added or updated
[ ] Relevant carvel.dev docs added or updated in a separate PR and there's
a link to that PR
[ ] Code is at least as readable and maintainable as it was before this
change

Additional documentation e.g., Proposal, usage docs, etc.:

Thanks for filing this! Are you able to sign the CLA?

@benmoss Yup, I have signed it and received the confirmation email.


Hide validate code form immediately when account is cleared

Details

We want to hide the magic code validate form as soon as the account data is cleared.
Fixed Issues

$ https://github.com/Expensify/App/issues/21147
PROPOSAL: https://github.com/Expensify/App/issues/21147#issuecomment-1600498246
Tests

Same as QA Steps

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

Offline tests

Requires internet connection
QA Steps

Prerequisites: setup an authenticator

Sign out if you are signed in
Enter your email and press Continue
Enter the magic code from the email
Verify you are brought to the authenticator input page
Scroll to the bottom of the Footer
Press Login
Verify you are scrolled to the top and brought to the login input page
Verify there is no error shown below the login input

Additional tests to make sure sign-in/up functionality still works well.

Sign up for NewDot with a new account.

Sign in to NewDot with an account that does not require 2FA by copy/pasting the magic code.

Sign in to NewDot with an account that does not require 2FA by clicking on the magic code.

Sign in to NewDot with an account that requires 2FA by copy/pasting the magic code.

Sign in to NewDot with an account that requires 2FA by clicking on the magic code.

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

PR Author Checklist

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

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

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

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

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

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

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

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

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

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

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

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

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

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

Screenshots/Videos

Web

https://github.com/Expensify/App/assets/50919443/d7903492-c5c7-40c1-890a-ba0be1b7bcca
Sign up for NewDot with a new account.
https://github.com/Expensify/App/assets/50919443/6288499b-f9f9-4960-871a-4dc31d658784
Sign in to NewDot with an account that does not require 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/511b2f7e-ef5b-4715-9701-5540233421d2
Sign in to NewDot with an account that does not require 2FA by clicking on the magic code.
https://github.com/Expensify/App/assets/50919443/7c9bd129-bcf4-4978-b2bf-28159d8be00b
Sign in to NewDot with an account that requires 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/dfc5241d-90fd-46db-9f69-75d925163913
Sign in to NewDot with an account that requires 2FA by clicking on the magic code.
https://github.com/Expensify/App/assets/50919443/1562773c-bf95-4a1e-a22a-be3e481dd576

Mobile Web - Chrome

https://github.com/Expensify/App/assets/50919443/3de5c84a-1cf3-4091-8384-e9e7482fd1b5
Sign up for NewDot with a new account.
https://github.com/Expensify/App/assets/50919443/9dc07985-81fd-4ab4-a58d-e704e38d6408
Sign in to NewDot with an account that does not require 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/044f01e9-811c-4bc6-993f-672cf782e065
Sign in to NewDot with an account that does not require 2FA by clicking on the magic code.
https://github.com/Expensify/App/assets/50919443/bee68a57-d68d-4232-8ccf-69040b4271d6
Sign in to NewDot with an account that requires 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/b621c4ff-0d7b-430c-a9c3-291e34a948d7
Sign in to NewDot with an account that requires 2FA by clicking on the magic code.
https://github.com/Expensify/App/assets/50919443/a4d52946-c519-4dfb-9c54-09d11a2dc939

Mobile Web - Safari

https://github.com/Expensify/App/assets/50919443/77ef6b2c-69c2-4b04-a989-1f7eb0e9488d
Sign up for NewDot with a new account.
https://github.com/Expensify/App/assets/50919443/7fc76f79-2fb1-43c4-9108-13f2de56f7ad
Sign in to NewDot with an account that does not require 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/2bc6e222-706d-4fa9-b512-3c5bd62c474a
Sign in to NewDot with an account that does not require 2FA by clicking on the magic code.
https://github.com/Expensify/App/assets/50919443/2e0895ae-10d2-4d13-bb15-89243f683a95
Sign in to NewDot with an account that requires 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/25110fa7-dac4-4e3c-adda-9063a8ac4070
Sign in to NewDot with an account that requires 2FA by clicking on the magic code.
https://github.com/Expensify/App/assets/50919443/4737ecf4-1ea6-4303-bd9f-af743eb8f5b4

Desktop

https://github.com/Expensify/App/assets/50919443/8077c376-9605-4ac4-a2c9-d0b97c27cbd7
Sign up for NewDot with a new account.
https://github.com/Expensify/App/assets/50919443/2295e950-d2ca-4162-b633-c25ef6184d35
Sign in to NewDot with an account that does not require 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/3433be61-5923-419f-9e04-a00882af94eb
Sign in to NewDot with an account that does not require 2FA by clicking on the magic code.
Sign in to NewDot with an account that requires 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/a2c5b665-91dd-49f5-8778-04d308382943
Sign in to NewDot with an account that requires 2FA by clicking on the magic code.

iOS

https://github.com/Expensify/App/assets/50919443/8e44fb11-c7b8-4eaa-bfa0-cb7d39f341ac
Sign up for NewDot with a new account.
https://github.com/Expensify/App/assets/50919443/a1467f1f-9d86-46c4-aef9-0155d28e31d2
Sign in to NewDot with an account that does not require 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/2ba4c2d9-0e8f-461e-bccf-944bb68dd5c8
Sign in to NewDot with an account that does not require 2FA by clicking on the magic code.
Not applicable.
Sign in to NewDot with an account that requires 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/4524d86c-f009-4bb4-90f0-805a79f1ab5e
Sign in to NewDot with an account that requires 2FA by clicking on the magic code.
Not applicable.

Android

https://github.com/Expensify/App/assets/50919443/cb6da88c-a964-4bfd-9250-a2dbad6e1272
Sign up for NewDot with a new account.
https://github.com/Expensify/App/assets/50919443/adc2899c-230e-4185-9632-b256d1b3de29
Sign in to NewDot with an account that does not require 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/04e6d5c0-882a-4a49-997e-7839c5744815
Sign in to NewDot with an account that does not require 2FA by clicking on the magic code.
Not applicable.
Sign in to NewDot with an account that requires 2FA by copy/pasting the magic code.
https://github.com/Expensify/App/assets/50919443/70d0a2ec-ff34-47b5-b379-249f9c0ea79d
Sign in to NewDot with an account that requires 2FA by clicking on the magic code.
Not applicable.

@bernhardoj I believe we should test it on all platforms as user won't be able to use app if anything breaks. It is quite critical change.

The issue caused by a Desktop app is open. Closing it solves the issue.

@bernhardoj Can you please link the issue. I am not sure if I understane.

I have a question. How do we test this by clicking on the magic code. on other platforms except web? It's not working for me (auto logging in).

@bernhardoj Can you test it in non-incognito (especially in Safari).

@bernhardoj You need to copy the magic link and replace the initial part of url with your local host or ip.

The issue caused by a Desktop app is open. Closing it solves the issue.

So, is this issue reproducible on staging as well?

Oh, I just realized I didn't change the domain when testing for desktop. I replaced it with localhost and it shows the abracadabra page now, but my desktop app still shows the login page (happens on main too)

When opening the link(with localhost) does it suggest to open on desktop? If it does, let's try opening it in desktop.

I wonder if this happens on native too because there is no way the web can communicate with the app? Haven't tested it yet because I reached max. request of magic code

We can skip the magic link part (test) because a user has no way to open the magiclink in native app.

Yes, it does, but I get redirected to this app instead.

bit strange
@bernhardoj Was your local desktop app open? Is it reproducible on main? Does same thing happen when you try to open other links?

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/jasperhuangg in version: 1.3.39-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/francoisl in version: 1.3.39-11 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Complete desk research around service users inclusion

What
We have done some desk research into inclusion internally, within the organisation. But we can focus our attention on doing some desk research on barriers to inclusion for our service users.
Why
This may allow us to get some information about groups who could prove difficult to reach in the time we have for discovery.
Done when

[ ] Desk research complete
[ ] Themes and outcomes shared with the team

Our initial desk research is done, on Confluence: https://nhsd-confluence.digital.nhs.uk/display/SMDS/Desk+research
We've drafted themes here: https://nhsd-confluence.digital.nhs.uk/display/SMDS/Themes+from+the+desk+research+-+for+internal+organisation
We'll be sharing these team next week.

Our initial desk research is done, on Confluence: https://nhsd-confluence.digital.nhs.uk/display/SMDS/Desk+research
We've drafted themes here: https://nhsd-confluence.digital.nhs.uk/display/SMDS/Themes+from+the+desk+research+-+for+internal+organisation
We'll be sharing these team next week.

Agreed desk research will continue in the background between meetings and other work, but as there is nothing major to share with the wider team yet, this will remain in the backlog for now.


Refactor loyalty to bank

Refactor most of backend services from loyalty to bank naming.

@loafyloaf main and credit-card are the same right now. I was planning on making the this branch the default one when we update the pattern page.


"dnu restore -s" with multiple sources

The only example I could find online was from beta 4, and the example apparently doesn't work with beta 7/8.
Basically I need to call dnu restore with 2 source (the generic source and a company source).
I have tried both of these but they don't work:
dnu restore -s https://mycompanysource -s https://www.nuget.org/api/v2
dnu restore -s https://mycompanysource -f https://www.nuget.org/api/v2
The documentation says that -s supports a list of sources, but I can't find an example.
What am I doing wrong?

This issue is being closed because it has not been updated in 3 months.
We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.


Update two_sp_queue_traffic_test.go

Leaf-ref and interface-ref validation added for cisco

Pull Request Functional Test Report for #1799 / 035131a798c1c586c510ace2b3fdcdd84b83d168
No tests identified for validation.
Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1341

Relevant Lines:
2814

💛  - Coveralls


Reformat breaks nested bulleted lists.

Kdoc such as the following:
/**
 * Paragraph
 * * Top Bullet
 *    * Sub-Bullet
 */

Would normally be rendered as:

Paragraph

Top Bullet

Sub-Bullet

This plugin will reformat the documentation as follows:
/**
 * Paragraph
 * * Top Bullet
 * * Sub-Bullet
 */

This significantly changes the markdown rendering of the comment:

Paragraph

Top Bullet
Sub-Bullet

Fixed in 1.4.1. Thanks for the report. (The IDE plugin is pending review in the plugin portal.)


Admin logout

admin logout routes should be developed and in the frontend admin pannel admin logout button should be displayed

do not need to add logout routes in the backend. since I already passed the jwt tokens, what you have to do is clear the jwt token in the local storage and navigate to the admin login page
function logout() {
localStorage.removeItem('access_token');  // or remove it from cookies if stored there
localStorage.removeItem('refresh_token');
window.location.href = '/login';  // Redirect to login or another page
}

Admin logout implemented: tokens cleared and redirected to login.


refactor(test): ensure pytest turns warnings into errors

Adds
filterwarnings = [
  "error",
  "ignore:numpy.ndarray size changed, may indicate binary incompatibility. Expected 16 from C header, got 96 from PyObject"
]

to our pyproject.toml.
The first is to turn all warnings into errors.
Line 2 is to ignore the numpy compatibility warnings that netcdf4 generates.

Nice!
ValueError: The following units are not recognized:
dilution_change_from_core_rad: ducks
edge_impurity_concentration_in_core: chickens


Replace multierr util with go-multierror

Closes #174
Test results are here
Let me know how this looks!
Thanks
P.S. thanks for yet another great tool!

Code LGTM, I just kicked off the tests!

Code LGTM, I just kicked off the tests!

Tests are passing, so I'm going to merge this! Thanks for the contribution, Casey!

Tests are passing, so I'm going to merge this! Thanks for the contribution, Casey!


Improve the current HTML Audio Player UI

The current audio player is very primitive and has poor UI, there are so many better material custom HTML/CSS audio players available out there, we should port to them else the simple player at the top of the screen in http://openings.moe works well too.

[x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
[x] This issue is for enhancement/bug fixing.
[ ] This issue is an addition to JSON database.
[x] I have gone through Contribution Guidelines.
[ ] Assign this issue to me.

Hi @anshumanv, please kindly check my PR https://github.com/anshumanv/ongaku/pull/211 :)


Docs: Update UG to explain tags

Resolves #89

Coverage decreased (-0.1%) to 92.698% when pulling 34c638ce9a9d7f817b7f0a39753829006e5b5cdd on nicholaschuayunzhi:ug-tag into d3ecc13787e3b41291df83d94563f0bcae2a1161 on CS2103AUG2017-W11-B4:master.


Can't preview an HTML file in a Codespace

Checkout https://github.com/microsoft/vscode-dev-chrome-launcher/pull/20 in a GitHub codespace
Preview options.html
:bug: preview doesn't work
See notification about application running on forwarded port
:bug: open in browser also doesn't work -- I see a 401 error

note to verifier:

Use the prerelease of the extension
You'll need to authorize both ports before you use live preview on codespaces (because of #111). Once you open the preview, go to the Ports panel and open the external links that are there for the http and websocket ports in your browser. This should authorize the private ports and allow you to use the extension.

Also you can install http port view by running  npm i -g http-server in the terminal and after installation, type http-server which will open the http port you can view the file. Then open the browser and paste the address : ex:  http://<IP_ADDRESS>:8080


feat: add boolean rule to the core rules

This pull request adds the boolean rule to the core rule, modelled after Laravel's boolean rule that accepts true, false, 1, 0, "1", and "0".
closes #113

LGTM, nice.


Register assets from copied block

Blocks that register assets break when pasted from the clipboard after reload. By calling registerViewAssets (if available) this is solved.

To clarify: assets are added to the page as normal, until the scrapbook is cached after which assets are no longer included with the page.

Thanks!


Consider adding convenience to processing and outputting date and time

We often have to write numerous helpers to process and output date and time strings
Server APIs also tend to require and return date formats inconsistently
Simple arithmetics on days, months, and years are also somewhat common right before, or in-between network requests, and we've had to use other libraries or write extra code just to do these
Setting, tracking, maintaining, and converting to the correct timezone where needed is often a loosely handled programming process (at least to me), so it'll be nice if Netable has a design that helps make this process more transparent and easier

We might be able to use property wrappers to handle this instead of including it in Netable


kernel: tls: don't use TLS for thread ptr if tracing is enabled

When tracing is enabled, do not use thread local storage to store thread pointer, and revert to getting current thread pointer via z_current_get(). This is due to tracing being used in swap code for marking threads being swapped in and out, and the very first time a thread is swapped in, the thread pointer in TLS has not been setup yet. This means that the tracing function will be passing thread pointer with random value around (for example, to _get_thread_name()), which might result in memory access faults. On the other hand, since the location of thread local variables are generated by compiler. It is not a good idea to pre-calculate the location to populate the thread pointer in the TLS area, as the compiler can change it between toolchain version... not to mention that the location is also architecture specific. So workaround this by not using TLS for thread pointers when tracing is enabled.
Also, on x86 and x86_64, populate CPU registers needed for TLS at the first switch to main.

Use #51413 instead.


Bad calculation

start = datetime(2015,2,23,hour=16, minute=0)
end = datetime(2015,2,24,hour=14, minute=20)
bt = BusinessTime(weekends=(SAT, SUN), holidays=holidays, \
            business_hours=(time(7), time(16)))
        business_time = bt.businesstimedelta(start, end)

Output is 7:20:00
start = datetime(2015,2,23,hour=16, minute=1)

Output is 0:00:00
Tested on Python 3.4.0

@JosefJezek I just released a new version, v0.1.5, with a fix for this


Thinning FC layers

The thinning methods support only removing channels or filters of a CONV layer
        # We are only interested in 4D weights (of Convolution layers)
        if param.dim() != 4:
            continue

[1]
How about thinning FC layers, even if you are not going to support it, can you provide, what all one should take care of if one wants to implement say remove_rows( ) or remove_columns( ) corresponding to neuron pruning ?
[2]
Its seems hard to simply extend the thinning_recipe approach as it seems to be too tied to removing CONV structures. Any suggestions ?
[3]
Also If we are thinning, pruned pytorch models, what could be the reason for its accuracy drop ?
Because we are strictly removing only zero structures, the math should be about the same and cause the same classificaiton ?
You seem to be taking into consideration a possible perofrmace drop by preparing to thin even the gradient tensors.

Hi Vinu,
I was thinking how to answer you, so it took me some time to write back to you.
A proper answer would require some time.  Basically, "thinning" is a process that transforms a network structure according to some "script" which I called the "thinning recipe".
Leclec et. al call this Neural Garbage Collection and describe this as:

Smallify decides on-the-fly which neurons to deactivate. Since Smallify deactivate a large fraction of neurons, we must dynamically remove these neurons at runtime to not unnecessarily impact network training time. We implemented a neural garbage collection method as part of our library which takes care of updating the necessary network layers as well as updating optimizer state to reflect the neuron removal.

Thinning in PyTorch is not trivial mainly because the structure (layers, connectivity and layer sizes) are all described in code (compare this to Caffe's protobuf format which is straight-forward to manipulate with code).
To deal with this I came up with the concept of a "thinning recipe", which is a set of instructions on how to manipulate a PyTorch module "graph" once it is instantiated.  We start by creating a model from scratch.  The modules of a network (model) are created in the constructor.  For example, this is TorchVision's ResNet constructor:
https://github.com/pytorch/vision/blob/fb63374cf76a54cc4a5dde361f1966afacd36cad/torchvision/models/resnet.py#L157-L166
So in the example above, when an object of type ResNet is instantiated, all of the modules in the network (sometimes referred to as model) are instantiated and we can go and change their configuration.  For example, we can go and change the number of input channels in a Conv2d object.  We can also go and remove channels from the weights tensors by making the tensors phyiscally smaller.  We do this by following instructions in a thinning recipe that we also stored in the checkpoint file.
Now the model is ready to load the physically pruned weights (no zero filters or channels - they were physically removed and their smaller version was stored in the pickle checkpoint file).
And then we are ready to go.
This was the second part of "thinning" - the part that "executes" thinning instructions.  The first part is more challenging, and it is creating the thinning recipe.  The challenge here is to understand the dependencies between the layers.  For example, imagine a Batch Normalization layer that follows a Conv2d layer.  If we reduce the number of output channels (and remove weight filters), we also need to understand that there's a BN layer following and that it also requires changes in its configuration (number of inputs) and in its parameters (mu and sigma tensors).  And these dependencies can get quite complex (we also need to transform tensors that the Optimizer may have; and the gradients - see [3] below).
But this is made even more challenging, because PyTorch doesn't creating a representation of the DNN graph in memory, until you run a forward pass (this gives PyTorch the flexibility to run a different path each forward-pass).  Without an in-memory graph of the network data-dependency (connectivity), we can't analyze layer dependencies.  To overcome this challenge I convert the PyTorch model to an ONNX model (which does a forward-pass) and then I "traverse" this ONNX object graph to construct a distiller.SummaryGraph object which hold an in-memory representation of the ONNX graph.  A distiller.SummaryGraph is used in other situations besides thinning.  For example to print the compute cost of each layer in the model.
Phew!
Let's catch our breath ;-).  That's a lot of stuff going on and this was, believe it or not, a short and perhaps unsatisfying explanation of everything involved in "thinning".  I've been planning on properly documenting this because the code is hard to follow.
Now to your questions ;-):
[1] Thinning FC layers is important (e.g. in RNNs) and is in my queue.
[2] I believe the "thinning" method is naturally extendible to FC (and other) layers.  You need to dive into the details (perhaps once I document them; perhaps by reverse-engineering the code) to see this.
[3] I'm not sure why we see a drop after thinning, which requires further fine-tuning.  This assumption might need to be re-examined.
The we transform the gradients for a different reason.  Say we removed a filter from a weights tensor of a Conv2d layer.  Well, we also need to remove a filter from the tensor storing the gradients of this weights tensor, other wise we can't perform any backward passes (the weights and the gradients tensors have the same shape, of course).
This was long but short.
Cheers
Neta

Thank you, Neta for your above description and answers.
I am getting used to your style of designing data structures to solve model compression problems.
aka. "prepare-first-execute-next". There have been days where I felt some data structures have been overdesigned, but thinking more about all the dependencies, looks like we need such rich structures to hold the information necessary to solve the problem at hand.
I understand your approach to thinning. I like to think of your design as a graph algorithm, thinning requires graph traversal, so you obtained a proper graph data structure to operate on.
I have a few particular questions on certain aspects of your design, there are low-level ones, I vaguely see why you might have done this, but clarifying this from you will benefit the community.
[1 ] Necessity of Sub recipes.
ThinningRecipe = namedtuple('ThinningRecipe', ['modules', 'parameters'])

Here is my understanding/notes for your choice of "modules" and why you might have considered having two sub-recipies for a ThinningRecipe.

Regarding the choice of the word "module".
So PyTorch model is simply a set of model parameters, and each parameter has a name.
You have come up with a term "module" to represent the same parameters, hold certain information
about them.
Everytime param_directives are updated, modules will also get updated to reflect the changes made to the paramters.
modules help you handle special layers like BN.

[2] The case where Linear follows a Conv2d
This is slightly simplified view of what you do, when executing param_directives for the case of Linear followed by Conv2d.  Could you please explain the logic that follows: if len(directive) == 4:
    for param_name, param_directives in recipe.parameters.items():
        param = model_find_param(model, param_name)
        assert param is not None
        for directive in param_directives:
            dim         = directive[0]
            indices     = directive[1]
            len_indices = indices.nelement()

            if len(directive) == 4:

                selection_view = param.view(*directive[2])

                if param.data.size(dim) != len_indices:
                    param.data = torch.index_select(selection_view, dim, indices)

                param.data = param.view(*directive[3])

[3] Handling of BN layer separately.

You have chosen to handle BN layer separately, was there an inherent restrictive posed by graph traversal or the data structure to do this ?
For example you could have added BatchNormalization to the following seccessor_list, in addition to Conv and Gemm.
successors = sgraph.successors_f(normalize_module_name(layer_name), ['Conv', 'Gemm'])
and a condition to check isinstance(layers[successor], torch.nn.modules.BatchNormalization)

Lets say we have a BN followed by Conv2d:

VGG(
  (features): Sequential(
    (0): Conv2d(3, 64, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
    (1): BatchNorm2d(64, eps=1e-05, momentum=0.1, affine=True, track_running_stats=True)

and 64 became 34 due to pruning, we need to adjust the configuration (number of inputs) 64 to 34 in the next BN, my understanding is that this is the only change required and in its parameters (mu and sigma tensors) will remain the same as the values removed are zeros so the mean and the variance will remain unchanged.
[4] Handling gradients

I need to actually run thinning on a real network to see if the accuracy drops at all, if so by how much post thinning. From the numerics of Gemm and BN, the classification should be unchanged. I am really keen to see if there is even a sinlge image that is misclassified. If that is the case then its like "garbage-collection is causing program to produce a different output".

Hi Vinu,
I'm currently traveling so it will take me a few days to answer.
Cheers
Neta

Sure Neta, No Problem.
[1] I was able to easily add support for Thinning FC layers.
Using modules {} sub-recipe to "Reduce" dimensions and parameters {} sub-recipe to "Remove" neurons, via the append api's to access these recipies.
[2] My changes seems to work fine for small networks, I test it by SummaryGraph, Forward pass.
[3] I notice that the accuracy remains the same too, still have not seen a misclassification yet.

Hi Vinu,
Sorry for taking such a long time - I was away in a conference and on vacation. Do you want to share your new code for thinning FC layers?
Cheers,
Neta

Sure Neta, I will do it this week.

Hi,
Closing this due to staleness.


Tweak Schema basics and Type hints docs

Description
This is a proposal to tweak and harmonize Schema basics and Type hints docs the following way:
-add missing import in complete example
-remove unneeded import
-add return type
-reference class with identifier
-use mutation decorator in Mutation types as in Mutation docs
Types of Changes

[ ] Core
[ ] Bugfix
[ ] New feature
[ ] Enhancement/optimization
[X] Documentation

Issues Fixed or Closed by This PR

None.

Checklist

[X] My code follows the code style of this project.
[X] My change requires a change to the documentation.
[X] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[X] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

Thanks for contributing to Strawberry! 🎉 You've been invited to join
the Strawberry GraphQL organisation 😊
You can also request a free sticker by filling this form: https://forms.gle/dmnfQUPoY5gZbVT67
And don't forget to join our discord server: https://strawberry.rocks/discord 🔥


Update contrib/debian and remove system json_spirit patch.

That patch has been broken for a long, long time (forever?) and doesn't make sense.
Reference:
https://github.com/bitcoin/bitcoin/commit/3563824c602cb2b42cc21970935f45ce646c3964

Looks good, that patch hasn't ever been used with paycoin that much I know.


Adding Lambdatest support

Steps

Run tunnel using your creds with name jasmine,  in case you're using a different name then please change browsers[key].tunnelName = 'jasmine' in js/tests/karma.conf.js file to the name being used (This step is required to run karma web server)
in the root folder do npm install and export below variables

export LAMBDATEST=true
export LT_USERNAME=username
export LT_ACCESS_KEY=accessKey

Run tests using command npm run js-test-karma

@mukesh-lt we should not remove support of browserstack. rather we have to add support of lambdatest. also, do not remove real devices. LT real devices support browser automation.


Unexpected token import/export

Vue.js version
2.0.2
Reproduction Link

package.json
{
  "name": "test",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "dev": "webpack-dev-server --open --inline --hot"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "vue": "^2.1.0",
    "vue-strap": "^1.1.32"
  },
  "devDependencies": {
    "babel-core": "^6.18.2",
    "babel-loader": "^6.2.8",
    "babel-preset-es2015": "^6.18.0",
    "css-loader": "^0.26.0",
    "html-webpack-plugin": "^2.24.1",
    "vue-loader": "^10.0.0",
    "vue-template-compiler": "^2.1.0",
    "webpack": "^1.13.3",
    "webpack-dev-server": "^1.16.2"
  }
}

.babelrc
{
  "presets": [
    ["es2015", { "modules": false }]
  ]
}

webpack.config.js
var path = require('path')
var webpack = require('webpack')

module.exports = {
  entry: './main.js',
  output: {
    path: path.join(__dirname, './dist'),
    publicPath: '/dist/',
    filename: 'build.js'
  },
  module: {
    loaders: [
      {
        test: /\.vue$/,
        loader: 'vue-loader'
      },
      {
        test: /\.js$/,
        loader: 'babel-loader',
        exclude: /node_modules/
      }
    ]
  },
  devServer: {
    historyApiFallback: true,
    noInfo: true
  },
  devtool: '#eval-source-map'
}

node -v  6.2.0
npm -v 3.8.9
do npm run dev   and then this error is appear
the answer in google is not work
urgency!!
Steps to reproduce
What is Expected?
What is actually happening?

Hi, please make sure to follow the Issue Reporting Guidelines before opening an issue. Thanks!


Likely unwanted Motion Spike on this chart

https://osu.ppy.sh/beatmapsets/100265#mania/266136

6ade84ad15c06346bb48bface826a0f82dbab706 Fixed in this commit


Child (async) actions and promise handling

Async actions
There has been some discussion on asynchronous actions (https://github.com/spoike/refluxjs/issues/57, https://github.com/spoike/refluxjs/pull/103) and where to best handle them.
The consensus seems to be that triggered execution is best kept outside of the stores, and I personally agree. In my opinion, the store shouldn't worry about how actions are run, focusing merely on their results. It also makes testing easier, as a few folks have noted.
The pattern proposed in the update on v0.1.8 links the execution of asynchronous code to the preEmit hook of an action, after which it triggers events on "Completed" and "Failed" actions, like so:
var ProductAPI = require('./ProductAPI');
// contains `load` method that returns a promise

var ProductActions = Reflux.createActions({
    'load',         // initiates the async load
    'loadComplete', // when the load is complete
    'loadError'     // when the load has failed
});

// Hook up the API call in the load action's preEmit
ProductActions.load.preEmit = function () {
     // Perform the API call, get a promise
     ProductAPI.load()
          .then(ProductActions.loadComplete)
          .catch(ProductActions.loadError);
};

Issues with preEmit
While this is definitely the cleanest way I've seen, some things still bothered me about it:

There is no semantic link between the "load" and "loadComplete" / "loadError" events. Nothing in the interface reflects the fact that they are related.

Putting an API call, or some other asynchronous code, in the preEmit hook seems hacky to me. Others have expressed similar sentiments (https://github.com/spoike/refluxjs/issues/57).

I think it's overly verbose. There's still some unnecessary boilerplate here, and for every async event (of which there can be loads) we have to now manually define 3 separate actions. If at some point we want to add a "Canceled" action as well for all our calls, we'll be doing busy-work for a while.

Proposal: Child actions
It appeared to me that if we could define child actions (attached to a parent action), we could design a much nicer interface. This commit is an implementation of that idea. The general interface looks as such:
// ProductActions.js

var ProductAPI = require('./ProductAPI');
// contains `load` method that returns a promise

// Define action with child actions
var ProductActions = Reflux.createActions({
    'load': {children: ['completed','failed']}
});

// And here is how you would hook it up to a promise
ProductActions.load.listen( function() {
    // Bind listener context to action by default
    ProductAPI.load()
        .then(this.completed)
        .catch(this.failed);
});

// ProductStore.js

var ProductActions = require('./ProductActions');

// This is how you would listen for a completed load
ProductActions.load.completed.listen(function(result) {
    // do something with result
});

// listenToMany (and ListenerMixin) will still work intuitively
var Store = Reflux.createStore({
    init: function() {
        this.listenToMany(ProductActions);
    },
    onLoad: function(){
        // product load started
    },
    onLoadCompleted: function(product){
        // product load completed
    }
});

Common-case helpers
I figured it would make sense as well to provide some helper methods and options to make the 80% case easier. This works as such:
// Define actions with async option to auto-create
// 'completed' and 'failed' child events
var ProductActions = Reflux.createActions({
    'load': {async: true}
});

// Hook up standard async child functors
// to a promise easily:
ProductActions.load.listen( function() {
    // Have the action attach callbacks to the promise
    // and pass on data to "complete" and "failed" actions
    ProductActions.load.promise(ProductAPI.load());
});

// Or even easier for the 80% case, a method that
// hooks ups callbacks to a returned promise directly
ProductActions.load.listenAndPromise( function() {
    return ProductAPI.load();
});

Alternative uses
For custom cases, you could create alternative children events:
var ImageAPI = require('./ImageAPI');

// If we need custom child actions, we could do so:
var ImageActions = Reflux.createActions({
    'pictureUpload': {children: ['progressed','completed']}
});

// Hook things up to a non-promise-based API
ImageActions.pictureUpload.listen(function(){
    ImageAPI.upload({
        onProgress: this.progressed,
        onSuccess: this.completed
    });
});
```

## Notes
Note, while createActions now operates on an associative Object, the interface remains backwards-compatible and accepts Arrays as well.

This has cleaned up my action definitions quite a bit. Curious to hear your critical thoughts / feedback! Thanks!

Congrats to everyone, particularly @willembult & @spoike, for this update!
I'm modifying a large codebase with this support now.  Can someone post a concise example on how this affects stores?
Currently, I've been using this helper:
Reflux.StoreMethods.promise = function(action) {
  var args = Array.prototype.slice.call(arguments, 1);

  return new Promise(function(resolve) {
    this.listen(resolve);

    action(args);
  }.bind(this));
};

// MyActions.js
Reflux.createActions(['fetch', 'fetchSuccess', 'fetchError']);

// MySore.js
Reflux.createStore({
  onFetch: function(query) {
    MyApi.search(query, function(response) {
      return response.ok ? MyActions.fetchSuccess(response.body) : MyActions.fetchError(response.error);
    });
  }
});

And consume it via:
MyStore.promise(MyActions.fetch, { id: 123 }).then(function(results) {
  console.log('Promised results:', results);
});

So, naturally, I just got the error Error: Cannot override API method promise in Reflux.StoreMethods, but I'm still wrapping my head around the changes.
Thanks!

Felt the need to comment here if anyone else runs across this as I've spent the last hour debugging a non-issue with this new Reflux feature: When using the 6to5 compiler with ES6, children callbacks will never get called if using the => function form:
ResponseActions.load.listen(() => {
  Api.fetch()
    .done( this.completed )
    .error( this.failed );
});

Though the former form works perfectly:
ResponseActions.load.listen(function() {
  Api.fetch()
    .done( this.completed )
    .error( this.failed );
});

Feel free to delete this comment if totally out of place!

@damassi This is only due to the lexical binding in ES6.

Thanks @jsdir -- I wasn't aware that this was going to be implemented, thinking instead that it was a bug in the compiler.


FAQ's: last paragraph

FAQ's: the last paragraph, the bullet points are aligned left and the text is aligned to the center.
Suggestions:
Maybe this paragraph could be entirely aligned to the left?
Or the whole FAQ's aligned to the left?

I think it would be cool to have the whole FAQs left aligned. This was also the intended behaviour. But I think things changed when merged into the new design.

done :)


Unstable behavior for warning Failed to get discriminator value for tagged union serialization ?

Initial Checks

[X] I confirm that I'm using Pydantic V2

Description
So after upgrading to pydantic==2.9.2 we started getting Failed to get discriminator value for tagged union serialization warning.
I found the issue #10355 and that it was resolved by #10400.
But I have decided to open a new issue, since:

we don't use raw discriminator function as in #10355, we use Field(discriminator="type")
if we change the order of field types, we do not get a warning (please see example code below)

I just find it kinda strange that there's a warning depending on the field types order.
Maybe remove warning at all or add to the documentation notes about the difference when changing type order?
Example Code
from typing import Annotated, Literal
from pydantic import BaseModel, Field

class Cat(BaseModel):
    type: Literal["cat"]
    name: str

class Dog(BaseModel):
    type: Literal["dog"]
    name: str

type Pet = Annotated[Cat | Dog, Field(discriminator="type")]

class Foo(BaseModel):
    maybe_pet: Pet | str | None = None  # like this we get a warning
    # maybe_pet: str | Pet | None = None  # like this there's no warning

foo = Foo.model_validate({"maybe_pet": "hi"})
print(foo)
dumped = foo.model_dump()

Python, Pydantic & OS Version
pydantic version: 2.9.2
        pydantic-core version: 2.23.4
          pydantic-core build: profile=release pgo=false
                 install path: D:\Code\project\.venv\Lib\site-packages\pydantic
               python version: 3.12.3 (tags/v3.12.3:f6650f9, Apr  9 2024, 14:05:25) [MSC v.1938 64 bit (AMD64)]
                     platform: Windows-10-10.0.19045-SP0
             related packages: fastapi-0.112.1 mypy-1.11.1 pydantic-settings-2.4.0 typing_extensions-4.12.2
                       commit: unknown

Yeah, we should fix this. Thanks for bringing to our attention.

If anyone wants to get their hands dirty with some rust, this would be a good issue.

This has been partially resolved by https://github.com/pydantic/pydantic-core/pull/1513/files

Working on fixing fully in another PR now.


Literal should not appear in the public API surface except as optional parameters for operations.

Currently, the code autorest.csharp generator is generating Literal in the public API, as seen here. However, Literal should not be generated on the public API surface unless they are optional parameters for operations.

I believe this issue should resolve this issue automatically.


[Divider] Add support for CSS variables

[x] I have followed (at least) the PR section of the contributing guide.

one of https://github.com/mui/material-ui/issues/32049
Preview: https://deploy-preview-32519--material-ui.netlify.app/experiments/material-ui/divider/
cc: @mui/contributors

@mnajdova I am left with a doubt. When I added the type, it didn't autocomplete or make the dividerChannel suggestion, did I miss something else?

@mnajdova I am left with a doubt. When I added the type, it didn't autocomplete or make the dividerChannel suggestion, did I miss something else?

I think we will have to revisit the type system for using CSS variables again. We consider CSS variables support for Material UI as a new feature so developers have to opt-in (at least for v5). For the type, I think we will need module augmentation to extend theme in various APIs eg. styled, sx, etc. Developers have to do this:
import { ThemeVars, Opacity } from '@mui/material/styles';

declare module "@mui/material/styles" {
  interface Theme {
    vars: ThemeVars
    opacity: Opacity
  }
};

// ...
// then
const Test = styled('div')(({ theme }) => ({ opacity: theme.vars.opacity.placeholder }));

@vicasas What do you think? cc @mnajdova

@vicasas What do you think?

Yes, it seems fine to me. Keeping in mind that it is somewhat experimental at the moment and can be polished along the way.


VectorFieldLines(VDF2D) makes Renderer(DX11) stop working and sometimes Windows Blue Screen

Hi!
First of all thanks for the excellent library! been having loads of fun with it.
I´m having an issue with VectorFieldLines(VDF2D) and my new laptop (Lenovo Legion, NVIDIA Rtx 2070 ) in both vvvv beta 39 and 38.1
With my previous laptop, a macbook pro late 2010 running bootcamp and vvvv 38.1 was working just fine.
So every time I connect VectorFieldLines(VDF2D) to a Renderer(DX11) it makes the whole screen blackout for a few seconds and when it comes back, the renderer output is frozen, sometimes it makes vvvv crash and sometimes it makes Windows go into Blue screen of death!
Any ideas what it could be happening?
Thanks a lot!
Best
Juan Hurle

Hi Juan,
The difference between machine is most likely a graphics driver version.  Please note with both this and Instance noodles it's recommended  to use the studio drivers.
Having said that, it's still obviously not ideal to have situations like that!  It's a little hard for me to check since I don't have the problem, but would you mind having a look if this fixes it before updating your drivers?
https://github.com/everyoneishappy/FieldTrip/commit/8f42d6f91e8eb05e1df6a2caa5c64304a6dde817

Hi Kyle!
wow that fixes it! it now seems to run without a problem! Thanks a lot for the extremely fast response and solution !
one last question though, where Is the best to post general usage questions of both Fieldtrip and instance noodles?
all the best and once again thanks a lot for your time and effort!
J

Cool, glad that worked.  I would still highly recommend to use the studio drivers if possible- have had other issues that were only resolved that way.
General usage stuff- here or probably on vvvv.org, or just contact me directly.


SP800-90B Keyed Conditioning Component Keys

Hardware implementations of the keyed SP8900-90B conditioning components (HMAC, CBC-MAC, CMAC) tend to use fixed keys, since there is no place for the key to come from and the actual security requirement is independence of the key from the input data. E.G. Intel uses AES-CBC-MAC with k = {AES_0(1) || AES_0(2)} as a suitable NUMS value. Fixing this value in the hardware saves a lot of gates through synthesizing out the unused key schedule hardware. So it's what is done.
The format E.G. 7.2.1 in https://pages.nist.gov/ACVP/draft-celi-acvp-conditioning-components.txt) doesn't seem to provide a field for specifying a fixed key value in the algorithm description. So the resulting key as described in 9.2 would likely be impossible to use.

This github is an implementation based on the ACVP specifications, not the source for the specifications. If you have comments about specifications or drafts please direct your comments to the author in question or the github that contains the specifications.

Yes. I figured that was probably the case. NIST already knows what I think.
I've made this comment in the CMUF working group and Alan R
acknowledged it.
I expect NIST to make accommodation for fixed keys in an update to the acvp
specs. We shall see how speedy they are.
Thanks,
DJ
On Thu, Jun 3, 2021 at 4:13 PM Barry Fussell @.***>
wrote:

This github is an implementation based on the ACVP specifications, not the
source for the specifications. If you have comments about specifications or
drafts please direct your comments to the author in question or the github
that contains the specifications.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cisco/libacvp/issues/624#issuecomment-854244975, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYMCGI2FXAL73LNQICHVEDTRAEDBANCNFSM46BI5E2A
.


Ensure that from_array creates a copy

[ ] Closes #xxxx
[ ] Tests added / passed
[ ] Passes pre-commit run --all-files

Yikes, I ran into this when working on linear fusion. Testing that gave me a bunch of weird collision errors which are explainable by the missing copy here

Hello - is there an issue associated with this? I hope I haven't missed a discussion, but I'm not sure that this is a useful change. Please allow me to try and explain ...
The proposed change to from_array looks like it will always copy an array_like input. But what if we don't want to do such a copy, for memory usage and speed concerns, or because we want to leverage in-place changes at some stage down the line? Is it not better leave any copying to the user (e.g. da.from_array(a.copy())), or we could provide a copy=<bool> keyword argument (defaults to False to preserve backwards compatability) to from_array, which will try to call the input's copy method, doing nothing if an AttributeError is raised? That said, I realise that it's cleaner, more general, and less typing to just pass in a copy and not have the keyword!
If the input is, e.g., a list, then it is already copied when it gets converted to a numpy array (which is fine), so we don't want to copy it again, in any event, I think. Some information in the docstring about copying might be all that's required? (I guess something along the lines of "the input is not copied, unless it is a list or tuple, which gets copied into a numpy array").
Thanks,
David

This is a pretty bad bug (but no issue associated)

because we want to leverage in-place changes at some stage down the line?

This is a very strong -1 from me, anything that changes an array inplace that was passed into a Dask Collection is a very very strong anti pattern and should never be relied upon, especially since we say our collections are immutable.

for memory usage and speed concerns

A copy is pretty cheap and everything that you do afterwards will have a lot more overhead than just copying the array once. If one copy really screws up the performance of your computation, then Dask is probably not the best tool anyway. Additionally, you really shouldn't pass large arrays into from_array anyway, you should load the data from storage.

Hi. Thanks for responding.
 Isn't Dask exactly the right tool to use my 10GB data? A copy on that sized array on my laptop would take ~1 second. I have thousands of these, so we're really adding up the time.
I appreciate that the in-place change I described is unusual, and could be not recommended, but I can think of workflows that leverage: Instantiate two Dask arrays from the same numpy array, build up different graphs on each, have the option of changing the source in both prior to computation (i.e. before anything has been passed to the scheduler). I don't want to do that at the moment, but I don't think we should disallow it.
It's rightly up to Dask to choose its own copying strategy (fully endorsed by the Python Array API), but whatever its default is, I believe that the user should have options.
I think that the proposed solution not only takes our options away, but also produces inconsistent results between different input types: Input types without a copy method, input types whose copy method is "shallow", and in input types whose copy method is "deep" would all give different outcomes - i.e. there's no guarantee that a copy is always going into the Dask graph. Better for the user to pass in a copy if they want to (which they can today), guided by better documentation (which could exist tomorrow)
Cheers,
David

(P.S. Would it be OK to open an issue for this?)

I appreciate that the in-place change I described is unusual, and could be not recommended, but I can think of workflows that leverage: Instantiate two Dask arrays from the same numpy array, build up different graphs on each, have the option of changing the source in both prior to computation (i.e. before anything has been passed to the scheduler). I don't want to do that at the moment, but I don't think we should disallow it.

That would screw with a bunch of different things since the content of your array goes into the graph generation and influences the keys. Again: You really should not do that under any circumstances

If I have a 10Gb numpy array and I make a copy, on my 16GB laptop, then everything is killed, that can't be right! Isn't Dask exactly the right tool to use my 10GB data? A copy on that sized array on my laptop would take ~1 second. I have thousands of these, so we're really adding up the time.

Where are you getting these arrays from? You should use Dask directly to create them instead of putting them into the graph.

It's rightly up to Dask to choose its own copying strategy (fully endorsed by the Python Array API), but whatever its default is, I believe that the user should have options.

I disagree, mutating the thing inplace has so many potential pitfalls that barely any user will be aware off.

Hi,

Where are you getting these arrays from?You should use Dask directly to create them instead of putting them into the graph.

I don't follow this, I'm afraid. Dask is not the only softwre library out there, and my 10GB array could have been made by another piece of software that outputs (say) numpy arrays, I still want to use Dask to process that output (to perform a reduction, for instance).

I disagree, mutating the thing inplace has so many potential pitfalls that barely any user will be aware off.

So let the user be aware of these! Numpy has benefits and dangers from it's view/copy approach - they're well advertised and we're all good with that. I really don't see a problem with making it clear ... perhaps the issue that prompted this wouldn't have arisen if there was a description of the input array in the from_array docstring. Currently there is none, but how about:
        x : array_like
            The array to be converted to a dask array. `list` and `tuple` inputs are copied but
            for all other input types, any in-place changes made subsequently to *x* will
            also affect the returned dask array.

Could we please open an issue on this, as per the development guidlines?
Many thanks,
David

Hi,

Where are you getting these arrays from?You should use Dask directly to create them instead of putting them into the graph.

I don't follow this, I'm afraid. Dask is not the only softwre library out there, and my 10GB array could have been made by another piece of software that outputs (say) numpy arrays, I still want to use Dask to process that output (to perform a reduction, for instance).

This is possible of course and this is also what this API is for. However, you will achieve better performance if you let dask do the generation/data loading. The data copy that is being introduced here is one example why that is better. There are other reasons that are more complex to explain (TLDR if we use a specialized API we can make certain assumption we can't make for the generic from_array)

I disagree, mutating the thing inplace has so many potential pitfalls that barely any user will be aware off.

So let the user be aware of these! Numpy has benefits and dangers from it's view/copy approach - they're well advertised and we're all good with that. I really don't see a problem with making it clear ... perhaps the issue that prompted this wouldn't have arisen if there was a description of the input array in the from_array docstring. Currently there is none, but how about:

I think there is a conceptual misunderstanding. In the numpy case, these "dangers" or "pitfalls" are mostly there because the API is sometimes not clear and it is easy to make a mistake. Experienced users can still navigate and leverage this.
Dask operates differently. We don't have the concept/distinction of views vs copies. There is no way for users to guarantee that inplace mutations are safe. This mostly comes from us executing things in parallel. The fact that intermediate results are not mutated is a core assumption the dask architecture builds on.

Hello,

Dask operates differently. We don't have the concept/distinction of views vs copies. There is no way for users to guarantee that inplace mutations are safe. This mostly comes from us executing things in parallel. The fact that intermediate results are not mutated is a core assumption the dask architecture builds on.

OK, I understand that, but it is not enforced anywhere else in Dask, so why should it be in from_array? (notwithstanding the out-of-memory and speed issues I have already highlighted). Consider the following, which quite happily embeds a non-copy of a numpy array in a dask graph:
In [25]: import dask.array as da

In [26]: import numpy as np

In [27]: dx = da.arange(3)

In [28]: x = np.array([4, 5, 6])

In [29]: dy = dx + x

In [30]: dy.compute()
Out[30]: array([4, 6, 8])

In [31]: x[0] = 999

In [32]: dy.compute()
array([999,   6,   8])

Dask can't always account for what we choose to put inside a graph. Rather it should it make it clear to users that what they put in (by whatever means) is not a copy, and they should put copies in if they need to.
By automatically copying, you're going to prevent Dask being used tomorrow in cases for which it works perfectly well today, and there won't be a nice error message, rather the session will just get killed when it runs out of memory.
Thanks,
David

P.P.S. surely it's time for an issue to be opened on this :)

Consider the following, which quite happily embeds a non-copy of a numpy array in a dask graph:

This is incorrect, we are calling from_array under the hood

This is incorrect, we are calling from_array under the hood

Interesting - and I get point. If you were to make from_array copy numpy arrays (and variously some other things), you can propagate this copying through all operations. Which makes me even more worried :) If x is automatically copied, how could I do dy = dx + x for a large enough x?

However, you will achieve better performance if you let dask do the generation/data loading

Only if dask is capable of the generation/data loading - it can't do everything :)
If no one else wants to start an issue on this, I shall ...

Hi @fjetter and @phofl,

@davidhassell it seems like you care about this deeply. If you do, I suggest opening an issue to discuss if there are ways to support a non-copy version as optional. There are probably a couple of nontrivial implications to think through.

Sorry for the delay in response ... I appreciate you both taking the time to discuss this with me :) I think I will open the issue you suggest, after consulting with some colleagues where I work, and look forward to continuing the interesting debate.
David

@phofl Can you maybe comment on the effects this copy might have on memory mapped numpy arrays?  This appears to load memory mapped object completely into RAM which is not ideal in many cases.  I can do some further testing of this but some guidance beforehand might be nice.


Clarification on how to create custom color themes

Is your feature request related to a problem? Please describe.
I am trying to customize the color theme for my website but I am finding myself having a hard time figuring out which color is used where and how to create the shades for the transparency.
I am mostly going with trial and error at this point, changing a color and then looking for the elements that change.
Describe the solution you'd like
I would like some clarification as to which colors are used where and how could I generate the transparency shades.
Describe alternatives you've considered
???
Additional context
I've been wanting for a while to change the colors to a darker palette but I did not really like any of the built-in ones. I have implemented Giscus comments on my blog and I wanted to change the palette to make the iframe fit in better, so I am trying to implement like a "github-dark" theme or something.
Maybe it would be useful for others as well to have some more variety on the color schemes? Some of the more common ones, like Darcula, Github dark, Github light etc.

Hey @mirceanton regarding what is used where, you can check the tailwind files, or other css files to get that info. There is basically three colora: neutral, primary, and secondary. That's it.
Regarding generating the variants, I had built a tool for that to help me generate the themes in blowfish...  https://github.com/nunocoracao/fugu
The tool was for my personal use, so it has no docs. It's a one line command that gets 3 hex colora and generates a css. If you think it's useful I can try to wrap up the project. It should be good for your use-case.

I managed to create a color theme by tweaking your tool a bit, thank you! I also made a PR to add a quick-start guide showing a command example and the setup

Thanks @mirceanton shall we bundle it with blowfish?

@nunocoracao Not sure what to say.
While I do think it can be useful to generate a starting point for a theme, I do think (and correct me if I am wrong) that most people use the theme as a submodule in the themes/ directory.
That being said, if we add it to the repo and add a script to run it with npm, you won't be able to run it from the root of your website repo, which I think can get a bit confusing, especially for new users. I think it would be best to keep it as an external repo and just mention it in the docs.

Makes sense. Let's keep them separated. I will consider mentioning the repo in Blowfish's docs.


Update in_memory_session_interface.py

This will raise  KeyError exception, if we do not use request["session"].
"xxx/sanic_session/utils.py", line 112, in delete
    del self[key]
KeyError: 'session:fc46d8d890254821a0ce9b8c9af29a0d'

from sanic import Sanic
from sanic.response import text
from sanic_session import InMemorySessionInterface

app = Sanic()
session_interface = InMemorySessionInterface()

@app.middleware('request')
async def add_session_to_request(request):
    # before each request initialize a session
    # using the client's request
    await session_interface.open(request)

@app.middleware('response')
async def save_session(request, response):
    # after each request save the session,
    # pass the response to set client cookies
    await session_interface.save(request, response)

@app.route("/")
async def index(request):
    # interact with the session like a normal dict

    return text("request['session']['foo']")

if __name__ == "__main__":
    app.run(host="<IP_ADDRESS>", port=8000, debug=True)

Thanks for catching this. This has failing tests (I should add CI to the project), so it'd be great if you could update the test as well.
___________________________________________________________________________________ test_should_delete_session_from_store ___________________________________________________________________________________

mocker = <pytest_mock.MockFixture object at 0x10ee290b8>, mock_dict = <class 'tests.test_in_memory_session_interface.mock_dict.<locals>.MockDict'>

    @pytest.mark.asyncio
    async def test_should_delete_session_from_store(mocker, mock_dict):
        request = mock_dict()
        request.cookies = COOKIES

        session_interface = InMemorySessionInterface(
            cookie_name=COOKIE_NAME)
        session_interface.session_store.get = mocker.MagicMock(return_value=None)
        session_interface.session_store.delete = mocker.MagicMock()
        await session_interface.open(request)

        response = mocker.MagicMock()
        response.cookies = {}

        await session_interface.save(request, response)

>       assert session_interface.session_store.delete.call_count == 1
E       assert 0 == 1
E        +  where 0 = <MagicMock id='4545167936'>.call_count
E        +    where <MagicMock id='4545167936'> = {}.delete
E        +      where {} = <sanic_session.in_memory_session_interface.InMemorySessionInterface object at 0x10ee29c50>.session_store

tests/test_in_memory_session_interface.py:130: AssertionError

Fixed by 5dfaa9b


Entity sensor.ecus_avg_outdoor_temperature is using state class 'total' which is impossible

Describe the bug
I see this message in Home Assistant:

3-10-11 14:08:42.271 WARNING (MainThread) [homeassistant.components.sensor] Entity sensor.ecus_avg_outdoor_temperature (<class 'custom_components.bosch.sensor.energy.EnergySensor'>) is using state class 'total' which is impossible considering device class ('temperature') it is using; expected None or one of 'measurement'; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/bosch-thermostat/home-assistant-bosch-custom-component/issues

To Reproduce
Steps to reproduce the behavior:

Configure Junkers CT100 with NEFIT (other metrics are working fine from here)

Expected behavior
No warning log
Version

HA version? 2023.10.1
HA Bosch component version? 0.23.4

Fixed in https://github.com/bosch-thermostat/home-assistant-bosch-custom-component/commit/e5967066caa58622bb0ccf13c4795bde1503ea63

@pszafer could you publish a release with the latest commits?


Use fetchcontent to import FTXUI. Fix compile errors.

Thank you much for this contribution!
The reason I have cloned my own version of FTXUI is that I use this program in windows terminal, and I get blinking with the version the CMAKE download points to in this pull request. Perhaps FTXUI could add support for modes, where only the modified characters are drawn on refresh? I think this will fix the issue.
My instructions point to my local clone of FTXUI, where I have fixed the blinking issue https://github.com/aaleino/FTXUI. It is a quick and dirty fix, so I did not create a pull request based on it. But I would be happy to make to point to the original repository, once FTXUI works with windows terminal.
I tried to reproduce the issue in this example:

Aleksi

Done. I made fetchcontent to point toward you repository instead.
If you can explain what is the bug, could you open an issue on the FTXUI repository?

Thanks. This was helpful, as now the compilation instructions got simpler. I did leave a general issue about this. I also readded ".focusable" -lines that caused compilation problems with the original library. This was just a quick hack to prevent the focused elements from disappearing. But I'm sure there is a better way to do that.


Improve contrast

Improve contrast in some parts of UI for better accessibility.
1. Borders
before

after

2. Collapsible

3. Help
This one, I'm not sure about. I made the headings purple because I felt the help menu looked like a wall of text, but it's kind of awkward.

Looks good but I will have to make sure it works properly with custom themes once I have access to my Windows machine. Also, make sure the code is properly formatted.

I will add back the fix for this when I have time, but how did you get a custom theme?? 😯

https://github.com/rbxrootx/Roblox-Studio-CustomTheme-Patcher

Made some additional changes
Help widget
I don't like colored headers so made the wiki link use a branded color. Also it's fine that this page looks like a wall of text since users are meant to use argon.wiki anyway.

Settings collapsible
I don't think we need to introduce a new color here. I reused a more subtle one that we already have and added some logic to it.
https://github.com/user-attachments/assets/d6d20d06-4134-4dd2-b44b-e44a9389f3ba
Border contrast
Here I only changed how it's implemented. Hardcoding color values is not a good idea.


Vulnerability roundup 112: tcpreplay-4.4.1: 5 advisories [7.8]

search, files

[ ] CVE-2022-27940 CVSSv3=7.8 (nixos-unstable)
[ ] CVE-2022-27941 CVSSv3=7.8 (nixos-unstable)
[ ] CVE-2022-27942 CVSSv3=7.8 (nixos-unstable)
[ ] CVE-2022-25484 CVSSv3=5.5 (nixos-unstable)
[ ] CVE-2022-27939 CVSSv3=5.5 (nixos-unstable)

CVE details
CVE-2022-27940
tcprewrite in Tcpreplay 4.4.1 has a heap-based buffer over-read in get_ipv6_next in common/get.c.
CVE-2022-27941
tcprewrite in Tcpreplay 4.4.1 has a heap-based buffer over-read in get_l2len_protocol in common/get.c.
CVE-2022-27942
tcpprep in Tcpreplay 4.4.1 has a heap-based buffer over-read in parse_mpls in common/get.c.
CVE-2022-25484
tcpprep v4.4.1 has a reachable assertion (assert(l2len > 0)) in packet2tree() at tree.c in tcpprep v4.4.1.
CVE-2022-27939
tcprewrite in Tcpreplay 4.4.1 has a reachable assertion in get_layer4_v6 in common/get.c.

Scanned versions: nixos-unstable: 710fed5a248.
Cc @proteansec

All unfixed upstream

Fixed:

nixos-unstable: tcpreplay-4.4.2


Fixed broken links

Looks good @CorwinDev - merged! We forgot to change these after improving the URL slug.


Version problem with nanomsg's mangos

Describe the bug
This is not a bug actually, rather, an update request.
To Reproduce
You can try to install ava on raspberry pi OS.
Expected behavior
A brand new node on ava test network.
Operating System
Raspberry pi OS
Additional context
I tried to install ava on my raspberry pi 4, but it failed at dependency installation part. First, I though it is an architecture problem and was about to give up, then I realized it is about version of mangos that is used in go.mod file: nanomsg.org/go/mangos/v2 v2.0.8. However, I found this caveat at mangos's github page: "The import path has changed! Please change any references from nanomsg.org/go/mangos/v2 to go.nanomsg.org/mangos/v3. The old v2 imports will still work for old applications, provided that a sufficiently modern version of Go is used. However, no further work will be done on v2." So, I believe go.mod file and maybe some other parts must be updated in compliance with mangos v3.
By submitting this issue I agree to the Terms and Conditions of the Developer Accelerator Program.

Thanks for reporting this! Just opened a PR to update the mangos dependency


PR workflow check integrity isn't trigger when the PR is created from release workflow

Description
Currently when the release caller workflow finish, the last job is create the release PR for the next development iteration, we expect trigger the PR workflow to check the PR integrity but isn't triggered.

Pull requests created by the action using the default GITHUB_TOKEN cannot trigger other workflows. If you have on: pull_request or on: push workflows acting as checks on pull requests, they will not run.
When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.

Workaround

Pull the release branch  (release/x.y.z)  linked in the release PR and push an empty commit to trigger the PR workflow to check the PR integrity.
Add the reviewers
Request the review PR

Tasks

[ ] Follow the documentation to implement a fix https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow

Do we need this? When we create a release we are only creating a new branch of what is currently in master and then changing some of the values to the next iteration, which shouldn't really cause the check PR workflow to fail. All checks would have already ran when doing the merges from branch to master and master should always be in a working state.


solved issue #178

Make the navbar size same for scholarship  and job potion and also make links visible.please accept my pr request under gssoc-ext level so that i could get gssoc-ext contribution level.

Next time wait for assignement i did not assign you the issue
This is not good practice
I am merging this pull request with a final warning

Also join discord dont create pull request without asking me there

Also why did you work on someone elses issue if you do this again i am blocking you from contributing in this repo


Error getting corpus iterator

Hi, I am trying to build the graph (just the graph) following the readme example, but I get this error:
Traceback (most recent call last):
  File "/mnt/MX500/corpus_graph/build_graph.py", line 31, in <module>
    main()
  File "/mnt/MX500/corpus_graph/build_graph.py", line 13, in main
    idx.index(dataset.get_corpus_iter())
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/elias/miniconda3/envs/pyterrier/lib/python3.11/site-packages/pyterrier/datasets.py", line 414, in get_corpus_iter
    it = tqdm(it, desc=f'{self._irds_id} documents', total=total)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object is not callable

What should I do?
Thanks,
Elias

Hi Elias!
Thanks for reporting. You’ll need to import pyterrier and run pt.init() before importing pyterrier_adaptive.
We’ve got plans to move more features out of pt.init() to avoid these sorts of issues, put haven’t done pt.tqdm yet.

sean

Ok, thanks!
Best,
Elias

We’ve got plans to move more features out of pt.init() to avoid these sorts of issues, put haven’t done pt.tqdm yet.

And this one is an easy fix :-)


Fix repr for And and Or matchers

I cannot use the And matcher in my tests, since the test crashes if mock decides to print out the matcher using __repr__. It looks like the __repr__ functions for And and Or incorrectly have the value argument?
I assume these haven't actually been used previously, since these two methods also reference self.matchers instead of the correct self._matchers (which would have been caught earlier if they were actually called).
Let me know if the value arg is intended behaviour. It seems that the value arg is not used though, and it's highly unusual for __repr__() to have more args than just self.

This is absolutely a bug. __repr__ never takes any arguments.
Thanks for fixing it!

I made a 0.2.2 release to include this fix.