More helpful error message when a stray Cargo.toml is present

Problem
Newcomers to Cargo occasionally end up with a Cargo.toml file that is irrelevant to the project they're trying to run. (It is often in their home directory; perhaps they ran cargo init not understanding what it does, but that's speculation.) When this happens, they get an error message that doesn't really explain what is going on. An example from today:
$ cargo run
error: failed to parse manifest at '/home/user/Cargo.toml'

Caused by:
  this virtual manifest specifies a 'dependencies' section, which is not allowed

New users don't know what a “virtual manifest” is, and are dealing with too many new concepts already to notice that /home/user/Cargo.toml isn't their project directory, nor do they know that it doesn't make sense to have one there. (And this message doesn't even contain the word “workspace”!)
Proposed Solution
Two parts:

When Cargo produces an error, the error is related to an invalid workspace manifest, and the purported workspace manifest path was found in a parent directory (rather than being the direct output of the locate-project algorithm), produce a message which prints the paths of both manifests rather than only the workspace manifest, with some explanation that these are two different manifests and how each relates to the situation.

If the purported workspace manifest is at least two levels up from the project manifest, or is located in the user's home directory, produce an additional help message which speculates that the workspace manifest may be extraneous and should then be either deleted or relocated to avoid nesting unrelated projects.

Notes
@rustbot label +A-diagnostics +A-workspaces +E-easy

I just tried to reproduce this and didn't get any errors.  Could you provide more concrete reproduction steps and use cases that lead to these mistaken workspace manifests so we can better consider how the user gets into these situations so we understand what errors to look at and how to improve them?

I can't provide concrete steps for the original example, because the user that had that problem didn't tell us how they got there. In general, issues of this type come from users that don't remember what they did, or don't have enough model of Cargo to say what the relevant things they did are. But here is an example sequence of steps which will produce a (different) broken configuration:
$ cargo init
    Creating binary (application) package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
$ rm -r src/ # we decided we didn't want this but didn't notice the other file
$ cargo new foo
    Creating binary (application) `foo` package
      Adding `foo` as member of workspace at `/<...>/project-structure-test`
warning: compiling this new package may not work due to invalid workspace configuration

failed to parse manifest at `/<...>/project-structure-test/Cargo.toml`

Caused by:
  no targets specified in the manifest
  either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
$ # IDK what that warning means so I will ignore it
$ cd foo
$ cargo check
error: failed to parse manifest at `/<...>/project-structure-test/Cargo.toml`

Caused by:
  no targets specified in the manifest
  either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present

To be clear, this is an unreasonable sequence of things to do all at once. Imagine, in between the parts, a lot of poking around with file managers and/or editors, trying different cargo commands, and possibly even moving files to different directories (“oh, I don't want my source code here…”). New users don't know what matters and I'm proposing that, for manifest errors involving supposed workspace manifests, Cargo can do a better job of mentioning what things do matter.

So what you are wanting to see is something like
$ cargo check
-error: failed to parse manifest at `/<...>/project-structure-test/Cargo.toml`
+error: Could not parse workspace for ...
+
+Caused by:
+    failed to parse manifest at `/<...>/project-structure-test/Cargo.toml`

Caused by:
  no targets specified in the manifest
  either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present

Experimented with this a bit and not thrilled with the results
failures:

---- workspaces::error_if_parent_cargo_toml_is_invalid stdout ----
running `/home/epage/src/personal/cargo/target/debug/cargo check`
thread 'workspaces::error_if_parent_cargo_toml_is_invalid' panicked at tests/testsuite/workspaces.rs:1420:10:

test failed running `/home/epage/src/personal/cargo/target/debug/cargo check`
error: stderr did not match:
1   1     error: expected `.`, `=`
2   2      --> ../Cargo.toml:1:9
3   3       |
4   4     1 | Totally not a TOML file
5   5       |         ^
6   6       |
    7    +error: could not parse workspace for /home/epage/src/personal/cargo/target/tmp/cit/t35/foo/bar/Cargo.toml

other output:

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- workspaces::new_warning_with_corrupt_ws stdout ----
running `/home/epage/src/personal/cargo/target/debug/cargo new bar`
thread 'workspaces::new_warning_with_corrupt_ws' panicked at tests/testsuite/workspaces.rs:1147:10:

test failed running `/home/epage/src/personal/cargo/target/debug/cargo new bar`
error: stderr did not match:
1   1         Creating binary (application) `bar` package
2   2     error: expected `.`, `=`
3   3      --> Cargo.toml:1:5
4   4       |
5   5     1 | asdf
6   6       |     ^
7   7       |
8   8     warning: compiling this new package may not work due to invalid workspace configuration
9   9
    10   +could not parse workspace for /home/epage/src/personal/cargo/target/tmp/cit/t58/foo/bar/Cargo.toml
10  11    note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

Part of the problem is that annotate-snippets reporting is handled very differently than other errors and its less ideal in this situation.  We are also wanting to move as many errors to annotate-snippets as possible.

So what you are wanting to see is …

More like this:

error: failed to parse manifest at /<...>/project-structure-test/Cargo.toml
help: the current directory, /<...>/project-structure-test/foo/, contains a Cargo.toml manifest file, but is considered a workspace member due to the presence of a manifest file in the parent directory, but that file is currently not a valid workspace manifest. If foo is not intended to be part of a larger project, then move foo/ out of project-structure-test/ or remove the Cargo.toml file from project-structure-test/.

Whichever way, that runs into the same problems.  More even since we can't add help: to regular errors, only annotate-snippet errors.  We sometimes emulate it but the result isn't the best.
btw that help: is too long that it would just lose people.

I'd enjoy something simple, like:
error: Failed to parse a package description in this workspace's Cargo.toml file.

Caused by:
	the surrounding workspace doesn't match its Cargo.toml file.

That moves away from the "workspace manifest" terminology while remaining helpful for more-experienced users.
If there is a way to add a help section, and we can tell if there's some issue with the package location, I'd like to see something similar to this:
help: Try checking the placement of your Cargo.toml file and its packages.

Also, if you do wish to continue using the manifest terminology, linking to the glossary may be neccessary: https://doc.rust-lang.org/cargo/appendix/glossary.html#manifest
In any case, if you have any advice for my input, please let me know! I'm looking to contribute more to Cargo and Rust in general. 😄

I stumbled across this thread trying to fix the same problem but for a different reason. For some reason, I'd accidentally deleted a character of the 'package' TOML header so it read 'packag'.
All fixed now, but I wanted to know why Cargo just blindly accepted [packag] as a heading instead of throwing an error / warning about an unrecognised keyword.
Furthermore, why does Cargo just assume it's a virtual workspace just because the [package] header is missing? Any answers are appreciated :)
[packag]
name = "li"
version = "0.0.2"
edition = "2021"

[dependencies]
bevy = { version = "0.14.0", features = ["dynamic_linking"] }
serde = "1.0.204"

...

opt-level = 3

I wanted to know why Cargo just blindly accepted [packag] as a heading instead of throwing an error / warning about an unrecognised keyword.

Instead of erroring on unused keys, Cargo warns.  This is helpful when we are adding new functionality to Cargo.toml that doesn't otherwise require an MSRV bump, like adding [lints].

Furthermore, why does Cargo just assume it's a virtual workspace just because the [package] header is missing?

A package must have at least

[package] (or [project])
[workspace]

I can see improving the error if neither is present, rather than falling through to assuming its a virtual workspace.

@epage Thanks for the info!

After taking a look into fixing this, it appears that the way Cargo stores data during manifest parsing isn't... optimal.
There are a TON of free functions that take in data. That data could easily be held by some struct instead. Also, it's relatively difficult to tell which functions clone the data passed in, which can obfuscate what's going on when optimizing parsing.
Beyond that, a refactor would allow for better error messages - we could have multiple types which are constructed only when we've hit a certain step during data collection, allowing for fleshed-out errors with stronger diagnostics.
I've been playing with this kind of design in my spare time, including with my most recent crate. It's nice to keep things clean and have easy access to errors. For Cargo, it would seriously clean up resolve_toml and many of its friends to work on an UnfinishedManifest instead of countless passed references.
Has anyone spoken about similar changes in the past? If so, how did things go?
Cleaning things up would help enable future improvements in this space. :)

@onkoe this might be a case where people have different priorities wrt "clean code".
I just recently did massive refactors to all of that code to make it what it currently is.  That doesn't mean its ideal but I'm not sold on the areas you are talking about

I prefer more precise information on what a function needs than providing a "god type"
free functions make it clearer what state they mutate (and you don't have to worry about what type to associate them with)

obfuscate what's going on when optimizing parsing.

If you are optimizing clones, then you are likely trying to optimize the wrong thing.

Beyond that, a refactor would allow for better error messages - we could have multiple types which are constructed only when we've hit a certain step during data collection, allowing for fleshed-out errors with stronger diagnostics.

I don't see how the changes you mentioned would help with error reporting.

Thank you for the swift reply! I saw the refactor when skimming the commits - it already did a lot to aid accessibility. However, I see some additional changes that could help avoid large function calls.
A very basic idea of the transitions would be something like: (TOML) -> UncheckedManifest -> Manifest, where UncheckedManifest has methods to create the necessary fields on Manifest. It would contain lots of the existing free functions as methods, allowing for patterns like: let dependencies = unchecked.resolve_dependencies()?;.
State Transitions
There are some issues with doing a one-to-one mapping of the free functions, though, as some rely on being called in certain contexts, after you parse things you'd put in its parameters. In that case, you can either continue with that pattern, or make additional states to represent their requirements.
The latter of these options is helpful when adding new features (or errors), as you'd need to add another state transition to put in an additional level of parsing.
For errors in particular, this prevents unrelated ones (like "this virtual manifest specifies a 'dependencies' section") from being created outside their types. It would make something like checking if we're at a weird location more obvious:
// this is what we'll have by the end. all of its
enum FinishedManifest {
    VirtualWorkspace(VirtualWorkspaceManifest),
    Workspace(WorkspaceManifest),
    Package(PackageManifest),
}

// a way to represent the kind of manifest we parsed, without
// all the `Option`s :)
enum ManifestKind {
    VirtualWorkspace {...},
    Workspace {...},
    Package {...},
}

struct UncheckedManifest {
    parsed_toml: ParsedToml,
    // potentially other things?
}

struct ParsedToml {
    /// Top-level TOML "tables" started by `[headers]` alongside
    /// their defined key-value pairs.
    tables: Vec<ManifestTable>,

    // ...(other fields if needed)
}

impl ParsedToml {
    type Document = toml_edit::ImDocument<String>;

    pub fn new(document: Document) -> Self {
        // parse the toml into tables? i wouldn't keep it as an ImDocument
        Self { ... }
    }
}

impl UncheckedManifest {
    pub fn new(parsed_toml: ParsedToml) -> Self {
        Self { ... }
    }

    // some first step. starts the chain
    pub fn make_first_step(self) -> CargoResult<FirstStepManifest> {
        // operations to make the first step
        FirstStepManifest::new(self)
    }

    /// Builds the Manifest through several waves of check/construction steps.
    pub fn build(self) -> CargoResult<ParsedManifest> {
        self.make_first_step()?
           .other_ops()? // ...
           .check_validity()?
           .check_dependencies()?
           .other_ops()? // ...
           .finish() // creates the ParsedManifest from the data we've gathered
   }
}

// ...

struct ManifestValidity {
    // ...fields from the prior step...
}

struct ManifestDependencies {
    // ...fields from the prior step...
}

// ...

impl ManifestValidity {
    pub fn check_validity(self) -> CargoResult<ManifestDependencies> {
        // run a bunch of checks

        // at some point, check if we have a [workspace], [package], or both!
        // (the "manifest.transpose().map(ManifestKind:: ...)" pattern)

        Ok(ManifestDependencies {
            // ...other fields
            manifest: ManifestKind,
        })
    }
}

impl ManifestDependencies {
   pub fn check_dependencies(self) -> CargoResult<ManifestNextStep> {
      // ...
   }
}

// ...

If the manual returns bother you, there are also generic versions of the pattern:
// note: you can use a trait instead. this would work fine if error states
// don't need to build on one another.
trait Scan {
    type NextState;

    pub fn scan(&self) -> NextState;
}

pub fn parse_manifest<S: Scan>(document: Document) -> CargoResult<UncheckedManifest> {
    let mut step: CargoResult<Either<S, UncheckedManifest>> = ParseToml::new(document);
    loop {
        // `?` the CargoResult, then check if they returned the type we want or not.
        // consider using a functional style for this.
    }
}

I'm not a big fan of those, as they feel a bit like weird linked lists, but some folks seem to like them nonetheless.
Conclusion
In any case, I'm in favor of having a state machine with unmistakable steps for Cargo's manifest parsing + analysis. It would require many changes to the codebase, but could overall help separate the manifest creation and avoid meddling across modules.
Both points assist with error handling, as we now know enough about where things went wrong to give little note or help diagnostics like the compiler. It becomes much easier to specify to the user that we assumed they have a virtual workspace, as that's now a type!
Future diagnostics could be more helpful for users, maybe even reaching the ease of adding lints to something like Clippy, as it becomes much easier to detect faulty state.
Thank you for your help and attention!

Ah, sorry, @epage. Just realized you likely don't watch all these issues, so here's a tag! 😄
Also, I did want to clarify a few things:

If I misused "parse", please imagine it as something better. I didn't want to make hard suggestions as I haven't worked with this codebase long-term.
Your ideas on organization are spot-on! I'm not quite after "clean code", though. Instead, these changes should improve accessibility for contributors. In any way that's done, I'll be happy. A 'tangible' state machine is still my preference, though, but that may prevent the "god type" you were mentioning. So... our thinking might be in line.
For the "optimization" part of things, I meant more streamlining the analysis process. Sorry for the confusion!

Again, thanks for your quick and detailed reply! :)

@onkoe Overall, I feel like that would make the design more complex, with lots of types with unclear roles in the process, and this would make it harder to refactor as changes in the inputs for a part of the process could easily cause a shuffling of the stages.
This is also getting pretty far afield from the actual issue.


Allow deleting a project

[ ] Allow the user to delete a project.

[ ] If the project is empty (no applets) show a confirmation dialog.

[ ] If the project contains at least one applet, notify the user that all applets will be stopped and deleted forever if they delete the project

@uu-z I can't find this feature implemented anywhere in w3bstream studio: can you please point me to how to delete a project?

@simonerom
You can right click the project.


client: impl IntoUrl for String for convenience

client: impl IntoUrl for String for convenience
client: Add tests for using String with IntoUrl

Thanks!


Revert changes for template literal types, keeping tests.

We have reservations about inferring template string types by default, so this PR applies the revert for work discussed at https://github.com/microsoft/TypeScript/issues/42589.

Will probably merge in an hour or two

So #42588 undoes #41891, right?  Just cross-linking them.

I hope you can bring it back at some point 🙏

Yeah, we had a lot of mixed feedback. I will say about half the team really wanted this and another half felt uneasy about it. We got feedback from existing projects that inferring template literal types by default was questionable at best.
Even though the original concern was about combinatoric explosions of string types, I think in the future we might be open to inferring literal strings when they can be constructed, but not necessarily template string types.
For example
function foo(x: "a" | "b")
  const str = `hello ${x}`; // "a" | "b"
}

but not
function foo(x: string)
  const str = `hello ${x}`; // `hello ${string}`
}


Create 'locations list' component for menu

Relates to #468
The 'locations' section in the about us menu has a unique component with a link-list with flags.

This is not something we currently have.

Is this component unique to the menu, or is/can it be used elsewhere as well?


Avoid query execution path for simple count(*) queries.

For count(*) queries without filters and group by's, we can simply add
up total.raw.docs from all segments, instead of going through the query
planning/execution path which is very expensive for such queries.
This does not help for hybrid usecases, as time filter is added
internally before sending to the OFFLINE/REALTIME tables.

Codecov Report

Merging #1452 into master will increase coverage by 0.04%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master   #1452      +/-   ##
=========================================
+ Coverage   67.85%   67.9%   +0.04%
=========================================
  Files         785     785
  Lines       38141   38164      +23
  Branches     4969    4973       +4
=========================================
+ Hits        25880   25914      +34
+ Misses      10566   10563       -3
+ Partials     1695    1687       -8

Impacted Files
Coverage Δ

...core/query/executor/ServerQueryExecutorV1Impl.java
87.68% <100%> (+1.06%)
:arrow_up:

.../pinot/core/common/datatable/DataTableBuilder.java
98.88% <100%> (+0.08%)
:arrow_up:

...com/linkedin/pinot/transport/common/SegmentId.java
34.78% <0%> (-8.7%)
:arrow_down:

...e/query/aggregation/groupby/utils/LongToIdMap.java
68.75% <0%> (-6.25%)
:arrow_down:

.../linkedin/pinot/transport/common/SegmentIdSet.java
53.84% <0%> (-5.13%)
:arrow_down:

...not/core/query/pruner/DataSchemaSegmentPruner.java
53.65% <0%> (-4.88%)
:arrow_down:

.../pinot/core/realtime/impl/RealtimeSegmentImpl.java
66.55% <0%> (-4.64%)
:arrow_down:

...re/operator/docvalsets/UnSortedSingleValueSet.java
64.61% <0%> (-4.62%)
:arrow_down:

...filter/SortedInvertedIndexBasedFilterOperator.java
77.02% <0%> (-2.71%)
:arrow_down:

...rEqualitiesToInClauseFilterQueryTreeOptimizer.java
90.9% <0%> (-2.6%)
:arrow_down:

... and 20 more

Continue to review full report at Codecov.

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

+1 for idea. However the implementation could be done better. The planning phase can setup operators that can simply work on the metadata instead of actual data. With this, we can extend this logic to min/max and other aggregation functions and it also follows the same execution flow.

@kishoreg Agreed, that is a good idea. Filed PR-1460 with an initial ground work that supports serving count(*) using metadata, and makes it easy to add support for other such queries as well.


fix: typo in lua/lush_theme/arctic.lua

Just happened to see this while customizing :slightly_smiling_face:

Nice! Thanks 👊


fix(gallery): show last nft card

Last data wasn't loading
PR type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Screenshot
Before

After

This is not fix.
The problem is that a NFT can have editions (eg. same picure 5 times on the page).
and we group them by the image.
So if you have first set to 10
and one nft which have 5 edition it means that there would be 6 images on the page.

Oh ok didn't know about that.
Is there any example I can find with multiple editions of same NFT ?

Subquery is currently working on groupby feature


Add a shutdown task after tests

Add a shutdown task after tests

This is blocked because of this issue https://github.com/open-feature/java-sdk/issues/552


Prepare v1.0.0

Description
Currently the Env-Linter supports node version 10. Node Version 10 is not maintained anymore and therefore needs to be deleted.
Also the packages need to be updated. Package updates that meet the following requirements can be updated:

Supports node version 12
Is not a ESM package

published as 1.0.0


fix: move @types/jest to dependencies to work well with yarn 2

Summary

Because we export mocked, a util function, as a public function but we also refer to @types/jest here which isn’t complied with yarn 2
This PR moves @types/jest to dependencies list.
Fixes #1857
Test plan

Not sure how to test with yarn 2 for this except other similar issues in the past solved by moving to dependencies list
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information
N.A.

Pull Request Test Coverage Report for Build 5566

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 92.989%

Totals

Change from base Build 5565:
0.0%

Covered Lines:
1093

Relevant Lines:
1128

💛  - Coveralls


Decide library project layout template.

I made a library project generation function in Version 1.0.0.


Chrusher security database

This is a start at adding authentication to thrimshim by adding the editors table to the database. This also adds the editor, edit_time and upload_time to the events table and modifies thrimshim and cutter to update these columns at the appropriate times. Currently the editor field is set to PLACEHOLDER in thrimshim until the actually authentication code is written to provide the actual email.

Authentication tested with Thrimbletrimmer. Please review

Improvements based on ekim's suggests and a fix a bug discovered while retesting


Test if retention polices are handled as expected

It looks like we currently not use retention policies on our cluster.
We may want to test if our operator can handle them as expected.

Maybe we also want to add an example in the readme?


firebird 3 - cant change table from null to not null

code generated  by  flame robin is this
UPDATE RDB$RELATION_FIELDS SET RDB$NULL_FLAG = 1
WHERE RDB$FIELD_NAME = 'STOKADI' AND RDB$RELATION_NAME = 'STOK_HAREKETLERI';

error mesage
Preparing statement:
UPDATE RDB$RELATION_FIELDS SET RDB$NULL_FLAG = 1
WHERE RDB$FIELD_NAME = 'STOKADI' AND RDB$RELATION_NAME = 'STOK_HAREKETLERI'
Statement prepared (elapsed time: 0.000s).
PLAN (RDB$RELATION_FIELDS INDEX (RDB$INDEX_15))

Executing statement...
Error: *** IBPP::SQLException ***
Context: Statement::Execute(
UPDATE RDB$RELATION_FIELDS SET RDB$NULL_FLAG = 1
WHERE RDB$FIELD_NAME = 'STOKADI' AND RDB$RELATION_NAME = 'STOK_HAREKETLERI' )
Message: isc_dsql_execute2 failed

SQL Message : -902
can't format message 13:98 -- message file C:\Windows\SYSTEM32\firebird.msg not found

Engine Code    : 335545030
Engine Message :
UPDATE operation is not allowed for system table RDB$RELATION_FIELDS

Total execution time: 0.005s

The system tables (RDB$—) are now read-only. Attempting any DDL or insert/update/delete statement on them will be rejected.
https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-compat-systables.html

Refs #57 and 7b2da34
have fun kid ;)


feat: Tignes

There’s a small problem, the website shows the lift status from an iframe, but the iframe domain does not match the Tignes website one. This means the resort URL will point to an unaccessible page.

Thanks, I updated it, I also noticed there was an existing parser for lumiplan so I reused it

I also fixed the parser as it wasn't applying title case and many resorts put the names all uppercase


ARROW-4297: [C++] Fix build error with MinGW-w64 32-bit

Improvements for ARROW-4297. This PR is a follow up to the discussed patch from https://github.com/apache/arrow/pull/3443.

It seems to build now on mingw32. Is there a test that checks if it actually does the right thing?

We need #3675 to enable tests for MinGW build.

Could you remove allow_failures?
https://github.com/apache/arrow/blob/master/appveyor.yml#L39-L46

#3657 has been merged.
We will be able to build and run tests with the following change:
diff --git a/ci/appveyor-cpp-build-mingw.bat b/ci/appveyor-cpp-build-mingw.bat
index 4d399274..d70fce1a 100644
--- a/ci/appveyor-cpp-build-mingw.bat
+++ b/ci/appveyor-cpp-build-mingw.bat
@@ -44,8 +44,10 @@ cmake ^
     -DARROW_PYTHON=ON ^
     -DPythonInterp_FIND_VERSION=ON ^
     -DPythonInterp_FIND_VERSION_MAJOR=3 ^
+    -DARROW_BUILD_TESTS=ON ^
     .. || exit /B
 make -j4 || exit /B
+make test || exit /B
 make install || exit /B
 popd

Some tests are now failing to build,
make[2]: *** No rule to make target 'gflags_ep-prefix/src/gflags_ep/lib/libgflags.a',
needed by 'release/arrow-json-integration-test.exe'.  Stop.

We need to install gflags package.
diff --git a/ci/appveyor-cpp-setup-mingw.bat b/ci/appveyor-cpp-setup-mingw.bat
index 471e7426..0c3d633c 100644
--- a/ci/appveyor-cpp-setup-mingw.bat
+++ b/ci/appveyor-cpp-setup-mingw.bat
@@ -25,6 +25,7 @@ pacman -S --noconfirm ^
     "%MINGW_PACKAGE_PREFIX%-cmake" ^
     "%MINGW_PACKAGE_PREFIX%-flatbuffers" ^
     "%MINGW_PACKAGE_PREFIX%-gcc" ^
+    "%MINGW_PACKAGE_PREFIX%-gflags" ^
     "%MINGW_PACKAGE_PREFIX%-gobject-introspection" ^
     "%MINGW_PACKAGE_PREFIX%-gtk-doc" ^
     "%MINGW_PACKAGE_PREFIX%-lz4" ^

@kou @wesm the nodejs and python travis error seem unrelated, are they currently failing for other builds?

@javierluraschi Indeed, they should be unrelated.

@kou @wesm could we merge this PR as is? While there are additional suggestions, like enabling Python tests, troubleshooting AppVeyor can be time consuming when a local environment does not reproduce the remote environment. Besides, I believe starting with a subset of the tests for a new build flavor is in general acceptable. Thanks!

We can merge this by opening JIRA issues for remaining tasks.

@kou thank you! Here are the JIRA issues that would complete this PR:
ARROW-4724: C++ Python not being built nor test under MinGW builds
ARROW-4725: C++ Dictionary tests disabled under MinGW builds
ARROW-4726: C++ IntToFloatingPoint tests disabled under 32bit builds

Thanks!
I'll merge this.


Components / Facets (fix): fix default values of list/tree facet

When the user setup an object "Facet" that will be used in a facet-multi component, if the properties such as "showCount", "searchable" etc... are not set by the user in the object, then they will be undefined.
Instead of using the default value of the Input in the component facet-list/facet-tree, the values will be set to undefined.
This is due to the fact that the object first passes through the component facet-multi where the object is then sending "undefined" values to the facet-list/facet-tree component, instead of not sending any value at all.
By adding an "ngOnInit" phase to the component, we can check for the input's value and set their default value if they are "undefined".

Smart move! Actually, these tests could even be set in the ngOnChanges() method (currently these inputs never change, but there's no reason why they couldn't), don't you think?

Actually, I realized we could also use getters, that would make the code probably cleaner.
For example, we would have the following implementation for "showCount":
@Input("showCount") _showCount: boolean = true;
get showCount() {     return this._showCount === undefined ? true : this._showCount; }
What do you think?
A setter could also be added in case there is possibility to modify the value manually, but I don't think there are such cases here right?

Hmm for me the getter approach actually makes the code a bit harder to read...

Alright, we'll go for the test in ngOnChanges then. I'm finishing my day here, so I'll code the change tomorrow and submit it again!
I'm less used to the ngOnChanges so it might have a few mistakes at first submit though.

OK, I think the implementation can be the same with ngOnChanges() as the one you did for ngOnInit()

I applied the change like you explained, it looked like it's working just fine.


[ ] ?
[ ] ?
[ ] ?
[ ] ?
[ ] ?
[ ] ?
[ ] ?
[ ] ?

Now labelling each numbered sand, this is gonna take forever lol

Animatic all done. started marking out some sands. Ending todo list not up to date with video currently

many many music modifications, and endings all blocked out, and more intro blocked out, and many sands ordered.

updated with storyboard and voice progress, also restructured to use final scene breakdown

updated with more sands

confession voice concept done

you have fortnite sand but no cat sand
why

[ ] make initial "tode is..." section a zoom out money shot with lens blurs to transition
[ ] make "1." on a white background.
[ ] try making "1." start centered, and then slide into place. can extend section if need (probably will need)
[ ] swap out first b roll and/or start fade later.
[ ] tune back timing offset of titles.
[ ] can black titles get more punch?
[ ] something feels off about Sandpond saga title. is it even needed???

how long is this going to take, just asking

ten bazillion years

mrpjmmmmmmmmmm,,,,,,,, samd

ten bazillion years

yes

actually it's pronouced bazillion lol

or nine hundred ninety-nine quadrillion nine hundred ninety-nine trillion nine hundred ninety-nine billion nine hundred ninety-nine million nine hundred ninety-nine thousand and nine hundred ninety-nine

Yay I got featured in something

Hey @TodePond , I have a New kind of sand: Sculpture sand. When one atom of Sculpture Sand can't move, it is now in the Dormant state. Sculpture Sand atoms in the Dormant state behave like stone. When The Sculpture sand touches an Active Sculpture Sand or some water, it has a 10% chance of becoming active as well. Just Sayin' tho

That kinda sounds cool

Maybe it could come out next year??


I get this error, but all files are fine and also the config.json

We couldn't connect to 'https://huggingface.co' to load this model, couldn't find it in the cached files and it looks like ./pretrained_weights/sd-vae-ft-mse is not the path to a directory containing a config.json file.
Checkout your internet connection or see how to run the library in offline mode at 'https://huggingface.co/docs/diffusers/installation#offline-mode

Hello @gunjahman , have you install complete files of sd-vae-ft-mse? The issue is likely caused by missing the file path, so I suggest you check the path and its configuration in the config file.

Thank you for your answer.
I have checked the path in the config file (configs/prompts/animation.yaml) and it is correct (pretrained_vae_path: "./pretrained_weights/sd-vae-ft-mse")
I have in the root a folder named: .pretrained_weights and in there a folder named: sd-vae-ft-mse and in there there are three files: config.json,  diffusion_pytorch_model.bin, diffusion_pytorch_model.safetensors.
But I'm getting that error.
Any ideas?

the folder name in the root may be pretrained_weights/ instead of .pretrained_weights. Is it right?

Good idea. I tried it and now I get a different error:  raise AssertionError("Torch not compiled with CUDA enabled")
AssertionError: Torch not compiled with CUDA enabled

This seems you don't install torch with a cuda version. You can first check whether the cuda is enabled by this:
import torch
print(torch.cuda.is_available())

If output is False, you could reinstall torch.

We haven't encountered this issue in our environment, but I have two ideas:

Check if there are any errors when loading weights, for ReferenceUnet
Ensure that the image encoder is installed correctly according to the link we provided. We expect the hidden_dim of enocder_hidden_state to be 768, not 1024. I suspect this might be the reason.

Sorry, I'm a newbie. Where do I write:
import torch
print(torch.cuda.is_available())

you can create a new .py file within the folder and run it

Thank you.
I did it, and you were right, I get FALSE
python check.py
False
What should I do?

@gunjahman
https://pytorch.org/


[Shadowrun5thA] only delete charsheet content when the import will be…

… successful
Changes / Comments
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[ ] Does the pull request title have the sheet name(s)? Include each sheet name.
[ ] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[ ] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.


Enhancement: component variant styling

This is a fairly expansive enhancement that allows the card and hero to have four prescribed variants.
The hero implementation is more complete, as the use case for card variants is less clear.

Merging this in so we can make use of the compiled CSS.

This is great. Awesome


Css variables part 1

A much less ambitious version of https://github.com/wagtail/wagtail/pull/6349
This PR:

Adds sass functions and mixins for easier authoring/modifying of CSS variables, as documented in the other MR
Adds postcss-custom-properties to the sass gulp task so that the admin will continue working on IE despite the lack of support for css variables
changes the $color-teal sass variable (and all the variables that depend on it) to reference the --color-primary css variable

@thibaudcolas As far as your comment:

It feels to me like it would be better to just refactor existing colors to not rely on modifying the darkness/lightness/saturation

How would you recommend dealing with the one-off colors in _listing.scss and _tabs.scss? Add a new color variable ($color-teal-darkerer? $color-teal-darkest?) that's close enough to those values that I can replace them?

@JNaftali Thank you for the PR. Great effort! Also on the more advanced one 👏
I've been requested to review your PR. Maybe because I contributed the previous color changes. When we went from low contrast lime to the higher contrast teal.

Thanks for the review!

How does this work in practice? What does an integrator need to know to change the admin colours? The docs are missing. I need the guidance too ;)

I had been holding off on docs while I wasn't sure if the PR was going to go through any major changes. I'll have a go at writing some tonight or tomorrow.
In the mean time - to customize the admin colors you need to insert a stylesheet into the wagtail admin (often using https://docs.wagtail.io/en/v2.10.2/reference/hooks.html#insert-global-admin-css ). That stylesheet needs to have a :root selector that defines some css variables. For example:
:root {
  --color-primary-hue: 45;
}

This PR adds 5 customizable colors: color-primary, color-primary-darker, color-primary-dark, color-input-focus, and color-input-focus-border. Ideally these should be set using 3 css variables per color - color-primary-hue (a unitless number), color-primary-saturation (percentage), and color-primary-lightness (percentage) (with equivalents for each of the other 4 colors). Assuming you choose a good color for color-primary, you shouldn't have to touch any of the other colors.

I do get that branding is important. More important is that Wagtail strives to be WCAG2.1, AA level compatible. The Wagtail color scheme and contrasts ratios are carefully crafted. I'd like the docs to have a warning about braking contrast and how to avoid that.

That was absolutely something that I planned to do. Do you have a preferred browser extension for checking contrast values? If not I'll probably call out Axe.
Will try to update the PR with docs tonight

Yup, everything you wrote there is correct. I don't know of any work coming up to standardize anything like this - since coming up with all this I've run across https://una.im/css-color-theming/ so I know that I'm not the only one to imagine doing stuff this way. It wouldn't shock me if there ends up being a way to make color functions in css whenever houdini support becomes the norm but I haven't seen anything written about that specifically.
Seems like even sass is trying to de-emphasize darken in favor of color.scale - https://sass-lang.com/documentation/modules/color#darken

@allcaps Hey! Hate to be a bother, but are the docs that I added sufficient? Or are there further changes you would like to request?

Thank you @JNaftali, honestly this is so future-thinking I wasn’t too sure how to review it. I wasn’t expecting something so fancy! I’ll do one more round of tests on Friday, and hopefully merge this then.

Thanks for the review @allcaps! Made those changes.
And that's super exciting to hear, @thibaudcolas! This is my first time contributing a feature to an open source project that I use, nice to hear it described like that

Again, thank you! This is a much requested feature. I'm sure many people are happy to see it realised. :D
I'll leave the final review and merge to @thibaudcolas.

@thibaudcolas I did not actually test on IE11 - I don't have a great way to run it, so your help debugging that would be very much appreciated.

According to caniuse it looks like IE11 doesn’t support calc in color functions. No matter, the usage of calc in the IE11-only fallback really is just a remnant of the custom properties setup and shouldn’t actually be needed. I’ll try to use https://github.com/postcss/postcss-calc to remove the unneeded & incompatible calcs and report back.

@thibaudcolas Still haven't managed to get IE running to test there but I added postcss-calc as you suggested and it seems to have removed calc from the backup declarations. So hopefully fixed whatever issues existed on IE

👍  thank you, I’ll assign this back to myself and see whether that was enough / take over from there.

Thank you that doing this @JNaftali! I have played with your branch and  it works very well.
So far I found one thing - in the stream field add block button on hover has old default wagtail color #007d7e. The problem is here.

So far I found one thing - in the stream field add block button on hover has old default wagtail color #007d7e. The problem is here.

Thanks for testing this out!, @dest81!
Given that react-streamfield is a separate package I don't think I want to mess with that until this PR is merged in... But! Since css variables exist at runtime, react-streamfield could fairly easily reference wagtail's color variables in their css. Thanks for making me aware of this, I might take a swing at that next :)

@thibaudcolas I wonder if/when this PR can be merged?

@dest81 when I get time to test it in IE11 and it works there as well – last time I tested this the styles were completely broken in that browser.

@thibaudcolas Obviously you should test this in your own time, but I managed to get VirtualBox up and running on my machine and it seems to be running well on IE! Screenshot attached (of IE accessing the Squash branch).

I have tested on IE11 via BrowserStack and can confirm it works.

Hi guys,
Sorry that annoying you but any news here?
I still see "needs work" label on this PR, shouldn't be changed to "Needs review"?
I know your are all busy but can you give me rough estimate when it can be reviewed and possibly merged?

Hi guys,
Sorry that annoying you but any news here?
I still see "needs work" label on this PR, shouldn't be changed to "Needs review"?
I know your are all busy but can you give me rough estimate when it can be reviewed and possibly merged?

Hey @dest81, you’re right, I’ve updated the labels. I have the branch checked out locally and am halfway through reviewing it. There is a blocker with https://github.com/wagtail/react-streamfield/pull/14 but I managed to find another way to do this that doesn’t involve changes to this separate package, so we’re in a good place. I’ll close that PR once I’ve confirmed my approach does work.
I still have more testing to do – I wouldn’t have noticed https://github.com/wagtail/react-streamfield/pull/14 had @JNaftali not reported there, so I want to make sure I’m not missing other things like this.
One other thing I’m still unsure of is color-primary-darkest – it’s very annoying to have to introduce this new shade for just 2 places out of the whole of Wagtail, and I think I found a way to change how those styles are made so we don’t need this. But here as well, more testing to do.

Hey @dest81, you’re right, I’ve updated the labels. I have the branch checked out locally and am halfway through reviewing it. There is a blocker with https://github.com/wagtail/react-streamfield/pull/14 but I managed to find another way to do this that doesn’t involve changes to this separate package, so we’re in a good place. I’ll close that PR once I’ve confirmed my approach does work.
I still have more testing to do – I wouldn’t have noticed https://github.com/wagtail/react-streamfield/pull/14 had @JNaftali not reported there, so I want to make sure I’m not missing other things like this.
One other thing I’m still unsure of is color-primary-darkest – it’s very annoying to have to introduce this new shade for just 2 places out of the whole of Wagtail, and I think I found a way to change how those styles are made so we don’t need this. But here as well, more testing to do.

@thibaudcolas thank you very much for the quick response, if you need any help (maybe with testing) I would be very glad to help ...

@thibaudcolas thank you very much for the quick response, if you need any help (maybe with testing) I would be very glad to help ...

One other thing I’m still unsure of is color-primary-darkest – it’s very annoying to have to introduce this new shade for just 2 places out of the whole of Wagtail, and I think I found a way to change how those styles are made so we don’t need this. But here as well, more testing to do.

I look forward to hearing what you come up with! Let me know if there's some way I can help

One other thing I’m still unsure of is color-primary-darkest – it’s very annoying to have to introduce this new shade for just 2 places out of the whole of Wagtail, and I think I found a way to change how those styles are made so we don’t need this. But here as well, more testing to do.

I look forward to hearing what you come up with! Let me know if there's some way I can help

@dest81 this is now published in Wagtail 2.12rc1 if you want to try it out: https://pypi.org/project/wagtail/2.12rc1/. Release notes: https://docs.wagtail.io/en/latest/releases/2.12.html#admin-color-themes.

@dest81 this is now published in Wagtail 2.12rc1 if you want to try it out: https://pypi.org/project/wagtail/2.12rc1/. Release notes: https://docs.wagtail.io/en/latest/releases/2.12.html#admin-color-themes.

@thibaudcolas I did a quick test and it works as expected. Will work with it more closely after wagtail 2.12 release. Thank you  @JNaftali and @thibaudcolas for the great job

@thibaudcolas I did a quick test and it works as expected. Will work with it more closely after wagtail 2.12 release. Thank you  @JNaftali and @thibaudcolas for the great job


Security Fundamentals Dashboard new update

Service Connector Errors Widget filter update to only show the LA-related errors
New Widgets: Logging Analytics Log Upload Size over time
New Widgets: Logging Analytics Active Storage Usage over time

@kgvarun We have updated the Security Operations Dashboard with new widgets covering the LA active storage usage growth, can you please review and approve the change?


Python: Add showcase integration tests

The integration tests are expected to be failing currently. They should be passing when @lukesneeringer cuts a new release of googleapis-common-protos that includes the annotations in longrunning_pb2.py.

Codecov Report

Merging #2343 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #2343   +/-   ##
=========================================
  Coverage     86.71%   86.71%
  Complexity     5194     5194
=========================================
  Files           454      454
  Lines         20641    20641
  Branches       2229     2229
=========================================
  Hits          17899    17899
  Misses         1960     1960
  Partials        782      782

Continue to review full report at Codecov.

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


In Process and Auto Build on Browser Request Behavior

Migrating the hosting model to In-Process changes the "auto build on browser request" behavior when saving .cs files.  With in-proc hosting, the project needs be built manually when the controller is modified, for example.  Since this is a change to the "Save and press F5 to reload" workflow, a mention of that would probably be helpful.
Note: I'm guessing the changed behavior this is not a bug and a consequence of using in-proc hosting.

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

ID: 46a10a5c-bacc-1bcf-a7ae-499715e1bfdd
Version Independent ID: 1585163b-b1d7-eeb8-ebc6-adfc2730f393
Content: Migrate from ASP.NET Core 2.1 to 2.2
Content Source: aspnetcore/migration/21-to-22.md
Product: aspnet-core
GitHub Login: @scottaddie
Microsoft Alias: scaddie

@jhigh2000 See :point_right: Browser Link in ASP.NET Core
Since this is more of a migration scenario to Core, it might be best for Migrate from ASP.NET to ASP.NET Core.

Note that Browser Link is covered in the topic that I linked ... a brief remark about it with a link. The link doesn't go to our topic tho. I'll add a link to our topic there.

This is a change in behavior from 2.1 to 2.2 in-proc. 2.2 out of process has the same behavior.

I didn't think Browser Link was ever a default scenario for the save-and-reload experience (or only briefly so in a prior version). The Microsoft.VisualStudio.Web.BrowserLink package isn't even in the App package. Browser Link is required either way, and it has to wired up manually via package reference and middleware add. There's no behavioral change between 2.1 and 2.2 that I'm aware of.†
†:smile: Let's ask @tdykstra ... he may encourage me not to operate my PC after taking so much cough syrup. lol ... I have a cold today. 🤧

This is what happens when you spend TOO much time in VSC!
Hold on a sec while I see if there's a reported issue on it. brb

@barrytang TL;DR ... Does the change to 2.2 IIS in-proc hosting possibly break the VS auto build on browser request scenario?
If it should be business-as-usual, then would you like @jhigh2000 to file a bug via Report a problem?
If we need to cover something in the migration topic for in-proc and this scenario, what do we need to cover?

@DamianEdwards confirmed that this is by design.
Definitely think this deserves mention in the 2.1 to 2.2 migration docs and maybe even in some of the tutorials, since in-proc hosting is the default behavior with 2.2.
Thanks!

Cool ... perfect ... I'll get that into the topic by EOD. Thanks for your issue and tracking down the info.


where do I find documentation on which tags i can use?

Hi @rlzijdeman ,
Do you mean in the query decorators?
#+ tags:
#+   - dbpedia

These tags are completely arbitrary -- so you can add whichever tags you want and as many of them as you see fit.

Good question -- there isn't any good documentation for it. But @albertmeronyo has been working on writing a tutorial which will explain all of them. And it will be ready... soon.

thanks @albertmeronyo @c-martinez https://github.com/CLARIAH/grlc/wiki/Query-decorators


Missing degree of freedom parameter in return value from stats.ttest_ind

I should mention first that this is an enhancement request rather than a bug issue.
The return type of the stats.ttest_ind function, testing for equal means two samples, comprises the t statistic and its associated p value. However, the degree of freedom parameter, computed in the function to estimate the p value from the t statistic, is missing in the return type, although it could be useful to the user (it is to me for instance).
In the distantly related issue, the issue author points out to the R function performing the t test (factorized in one function instead of 3 functions, depending on function arguments). Efforts could be combined to factorize the functions and enhance the return type by getting inspired by the R function (other values could be useful for the user).

I just skimmed through the codebase and I understand that backward compatibility would not be trivial

It actually is trivial (now) to maintain backward compatibility. The bunch object works just like a NamedTuple (e.g. can be unpacked as a tuple) for all the attributes already included, but we can add additional attributes.
@tirthasheshpatel What do you think? Shall we convert the returned object into a bunch and add df as an attribute?

What do you think? Shall we convert the returned object into a bunch and add df as an attribute?

Returning a df attribute sounds good (although it does complicate the API a bit since it doesn't apply to all tests as you mentioned, adding it across all t-tests mitigates the issue). R's t.test and cor.test (with method pearson) also give the df of the null distribution in the output so worth considering returning a df field in pearsonr too (if and when we add it in t-tests).

Ok, sounds reasonable. @LeBarbouze would you like to submit a PR?

@mdhaber I'd be interested but I am not sure I will find time in the coming weeks. I will try my best to find a slot in the coming month or so.  It'd be a first time for me (looking now at https://scipy.github.io/devdocs/dev/hacking.html and https://scipy.github.io/devdocs/dev/dev_quickstart.html#dev-quickstart), I'll get back here if I need further guidance. Of course if someone else does it in the mean time, just mention it here so that I don't duplicate the effort.

@mdhaber is there an issue specifically tracking adding the confidence interval in the return of ttest? Or is it generally just part of the much larger gh-9485?

I don't think so. Personally, I don't think we need an issue to track it, because confidence intervals for all of our hypothesis tests is on my mind pretty frequently. Ideally, I'd like to wait until I can write the hypothesis test infrastructure I've proposed elsewhere so that all the hypothesis tests don't have to reinvent the wheel.
On the other hand, it would probably be worthwhile to get these into the t-tests because it's so fundamental. I submitted gh-16835 to get that started.

@mdhaber thanks for the info and definitely don't rush it on my account! Understand if you want to wait to do it all at once in a larger refactor to bring those t-tests into one. Agree though it's a pretty fundamental thing to want to have :)
If you do go forward with gh-16835, will that cover ttest_ind as well? Or that will be follow-on work?

It would be a follow-up. I expect ttest_ind is the is the most important t-test function, but it is probably the most challenging to get right because ttest_ind has options for performing many different variations of the t-test. (Besides equal and unequal variances, it does trimmed mean and permutation-based version of the test.) If we want the confidence interval to somehow respect those options, it is more work. So I thought I'd start simple, and consider others once we get that right.

Makes sense! Thanks for the follow up. Yeah I was wondering about the complexity of the permutation test and such. Definitely a lot of work with those additional options and after a quick perusal, maybe not clear agreed upon solutions (I'll let you know if I find one). So the iterative approach sounds like the right one..

A permutation test CI can be calculated as the maximum and minimum shifts that can be applied to one of the samples before the permutation hypothesis test would begin to be rejected at p=1-confidence_level. I'm not sure we really want to implement that, though. Thinking again, though - we'll want confidence_interval to be a method rather than just returned by the test, so actually it doesn't necessarily need to respect all the same options.

Ah, that makes sense (I think..). FWIW this was one of the better things I found (along with the links to the papers by Ernst, Garthwaite and Ngyuen): https://stats.stackexchange.com/questions/409376/how-to-calculate-a-permutation-confidence-interval

Yeah, I ran accross the abstract mentioned there:

The OP links to an abstract by Tableman, Nguyen, and Ernst (2014), who mentioned a method for permutation CIs but didn't actually describe it in their abstract.

and I also noticed that the method was not actually described there. Thanks for finding it!
Note that we need to be careful not to use the R code in the poster you linked; just the ideas (or look at Nguyen's thesis). It sounds like it is an excerpt from a package, which is probably GPL licensed, and therefore not compatible with SciPy's license.

It actually seems to be MIT licensed: https://github.com/ColbyStatSvyRsch/CIPerm/blob/master/LICENSE.md but maybe your point still stands.

Oh, great. No, that's compatible. R code is usually GPL.

The return type of the stats.ttest_ind function, testing for equal means two samples, comprises the t statistic and its associated p value. However, the degree of freedom parameter, computed in the function to estimate the p value from the t statistic, is missing in the return type, although it could be useful to the user (it is to me for instance).

+1
I would also add as evoked above a ''.confidence_interval" method for ttest_ind.

The holdup here is that ttest_ind has evolved a complicated API, and we cannot easily provide a confidence interval for all combinations of options. We can raise a NotImplementedError as needed, but wading through all this is somewhat tedious. I'll take a look shortly and suggest a plan.


Unable to access Azure Storage Explorer  - looks like account disabled

{
"message": ""{\n  \"message\": \"\\\"AADSTS500571: The guest user account is disabled.\\\\r\\\\nTrace ID: 3333c240-b7e4-4a1a-abdd-9cd827641200\\\\r\\\\nCorrelation ID: e462d9fa-7d33-48a2-9e6e-984677707987\\\\r\\\\nTimestamp: 2023-07-26 18:14:20Z\\\"\"\n}""
}

@gokulbab you will need to reach out to Azure support for help with this problem.


Change in Variables

Hello,
I am working on a project with TwinCat and AMR. I am using python as communication medium between the two systems. I have an issue of waiting for the variable to change value. I have a variable of type 'BOOL' and want to perform certain action when the variable changes, Can someone help me with this? P.S. I have notified for change in variable as well.
StnF = PLC.read_by_name('GVL.AGVgotoStnF', pyads.PLCTYPE_BOOL)
print(StnF)
if StnF == 'TRUE' :
ArrStnF = PLC.write_by_name('GVL.iPosAGV',3,pyads.PLCTYPE_INT)
print(ArrStnF)

Abhishek81723 I'm sorry but Github issues is not the right place to ask for help on using this package. Please use communities like Stackoverflow for this. Kind Regards.


Gradle exiting abnormally on debug

Steps to Reproduce

Add flutterfire dependencies and google sign-in pubspec and Android
flutter run

Logs
Please review your Gradle project setup in the android/ folder.

#0      throwToolExit (package:flutter_tools/src/base/common.dart:24:3)
#1      _readGradleProject (package:flutter_tools/src/android/gradle.dart:158:7)
<asynchronous suspension>
#2      _gradleProject (package:flutter_tools/src/android/gradle.dart:111:34)
<asynchronous suspension>
#3      getGradleAppOut (package:flutter_tools/src/android/gradle.dart:105:29)
<asynchronous suspension>
#4      AndroidApk.fromAndroidProject (package:flutter_tools/src/application_package.dart:154:23)
<asynchronous suspension>
#5      ApplicationPackageFactory.getPackageForPlatform (package:flutter_tools/src/application_package.dart:46:32)
<asynchronous suspension>
#6      FlutterDevice.runHot (package:flutter_tools/src/resident_runner.dart:345:56)
<asynchronous suspension>
#7      HotRunner.run (package:flutter_tools/src/run_hot.dart:253:39)
<asynchronous suspension>
#8      RunCommand.runCommand (package:flutter_tools/src/commands/run.dart:428:37)
<asynchronous suspension>
#9      FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:559:18)
#10     _asyncThenWrapperHelper.<anonymous closure> (dart:async-patch/async_patch.dart:77:64)
#11     _rootRunUnary (dart:async/zone.dart:1132:38)
#12     _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#13     _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#14     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#15     Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#16     Future._complete (dart:async/future_impl.dart:473:7)
#17     _SyncCompleter.complete (dart:async/future_impl.dart:51:12)
#18     _AsyncAwaitCompleter.complete (dart:async-patch/async_patch.dart:28:18)
#19     _completeOnAsyncReturn (dart:async-patch/async_patch.dart:294:13)
#20     RunCommand.usageValues (package:flutter_tools/src/commands/run.dart)
#21     _asyncThenWrapperHelper.<anonymous closure> (dart:async-patch/async_patch.dart:77:64)
#22     _rootRunUnary (dart:async/zone.dart:1132:38)
#23     _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#24     _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#25     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#26     Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#27     Future._complete (dart:async/future_impl.dart:473:7)
#28     _SyncCompleter.complete (dart:async/future_impl.dart:51:12)
#29     _AsyncAwaitCompleter.complete.<anonymous closure> (dart:async-patch/async_patch.dart:33:20)
#30     _rootRun (dart:async/zone.dart:1124:13)
#31     _CustomZone.run (dart:async/zone.dart:1021:19)
#32     _CustomZone.bindCallback.<anonymous closure> (dart:async/zone.dart:947:23)
#33     _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
#34     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)
#35     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:115:13)
#36     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:172:5)

[✓] Flutter (Channel stable, v1.5.4-hotfix.2, on Mac OS X 10.14.6 18G48f, locale en-US)
    • Flutter version 1.5.4-hotfix.2 at /Users/sethu/development/flutter
    • Framework revision 7a4c33425d (8 weeks ago), 2019-04-29 11:05:24 -0700
    • Engine revision 52c7a1e849
    • Dart version 2.3.0 (build 2.3.0-dev.0.5 a1668566e5)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /Users/sethu/Library/Android/sdk
    • Android NDK at /Users/sethu/Library/Android/sdk/ndk-bundle
    • Platform android-28, build-tools 28.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.2.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.2.1, Build version 10E1001
    • ios-deploy 1.9.4
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 30.0.1
    • Dart plugin version 181.5656
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[✓] VS Code (version 1.35.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.1.0

[✓] Connected device (1 available)
    • Nexus 6P • 8XV7N17425000010 • android-arm64 • Android 9 (API 28)

• No issues found!

@SethuSenthil
If your project is a 'add to existing app', paste content for buildSrc/src/main/groovy/FlutterPlugin.groovy
Otherwise, paste content for app/build.gradle please.


Blocked

Lol, this is blocked, probably because it enables you to track me.

Blocked by what?

My district. I use a chromebook. This is not a bug, just some info.

My district. I use a chromebook. This is not a bug, just some info.

Ok, that has absolutely nothing to do with my website, that's your school. It works fine at my school, but I have added nothing to it.


Add German (de) Language Localization

Added German (de) Language Localization

@Anarchoschnitzel Sehr gut 👌


Add "state_class: measurement" support for long-term statistics

I'm really not sure if this is an issue with the rtl plugin or Mosquitto, so this might be the wrong place to ask.  I currently have a temperature sensor configured (as type temp_hum_c_to_f) in this plugin.  I'd like to be able to use HA's long-term statistics to create a graph.  According to https://www.home-assistant.io/more-info/statistics/, the entity needs a state_class set to "measurement".  Can we do that from within this addon, or does Mosquitto need to support it instead?

Installed this yesterday and it seems to be working as expected.  Thank you so much for your time working on this. Good luck with your new place!


Enforce linting and formatting

Enforcing linting and formatting a little more will make everything more consistent and easier to maintain

Run the format script, which will get us a thousand different changes.
Install Prettier and some extra packages to make it possible to format on save. That should save us the trouble of batch formatting and having lots of files modified at the same time (which equals harder reviews) in the future.
Create a PR with all of these changes.

An easier but less thorough option could be installing and configuring Prettier to make everyone format the files they’re working on on save. That’ll leave us with some unformatted files. So this is discouraged.

@fernandomg @mikheevm PR associated to this issue is already merged. Shall we close this one?

From my side yes

closed now


Add matplotlib as a dependency

matplotlib was required for the tutorial in the jupyter-notebook.

Note: This is a bug in the jupyter notebook - matplotlib is not actually a dependency


Update hflip and vflip with mutable signatures

After this refactor https://github.com/kornia/kornia-rs/pull/102 hflip a and vflip` were pending to be completed

Hi,
I'm interested in taking this up.
As I understand from the linked PR, we have to use a mutable dst parameter for the output instead of returning, and also adjust the loop slightly for that. Please let me know if there is anything else I should consider. I have started with hflip function and hope to have something for your review soon.

@emilmgeorge yes, that's it. Beware that this morning i merged the last of series of PR to ndarray as dep. See: https://github.com/kornia/kornia-rs/pull/116
you might have to rebase

Thanks, yes I saw it just after I posted my prev comment. I have since rebased and updated my changes. Will PR now.

merged in #117


Updated builds from Flight Hub

Fixes issue #104

We've added the 20H1 builds as a separate section of the flight hub, instead of replacing the 19H1 section. Thank you for your contribution.


Updates to the new entry point code from latest vapor.

I wanted to update this template to a/a and the entry point seemed like an easy update.
I've basically given the template a package file that matches what a new project from the toolbox creates.
All tests pass.

Research seems to show there is no vapor images for 5.6 I can find. That is what is preventing the tests from running.


21116 Show user info for Continuation In filings

Issue #: bcgov/entity#21116
Description of changes:

app version = 5.10.24
show user info for Continuation In filings
updated unit tests

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

/gcbrun

The sample filings above were created as staff, so the staff user info displays (which does not include phone number).
Here's a sample continuation in created and opened as BCREG0020 / Severin Dev Account:


REST API CustomerSavedSearch not working at all

Issue summary
ShopifyAPI::CustomerSavedSearch.all(session:session)
returns
ShopifyAPI::Errors::HttpResponseError (Not found)
Any call to CustomerSavedSearch returns a not found? We definitely have saved searches. Session looks good. Can make tons of other calls fine. I have customer_read and customer_write scope permissions. Any ideas?

shopify_api version: 11.0.1
Shopify API version used: 2022-04

Same issue using API version 2022-07


tox.ini: Add flake8 test for undefined names

The flake8 F821 test for undefined names is extremely helpful when porting Python 2 code to Python 3 because it flags names like basestring, cmp, execfile, file, long, reload, unicode, xrange that were all removed in Python 3.  Many large codebases like Node.js and V8 vendor in Python dependencies such as Jinja instead of pip installing them.  As we try to port these codebases to Python 3, Jinja's undefined names are cluttering their test output.
This PR advocates the use of try: except NameError: blocks as discussed in the Python porting guide.

Thanks for working on this. However, _compat isn't worth changing at this point, since it will become completely unnecessary soon. At this point it's easier for me to keep track of what it's doing the way it's written now.
Pallets projects have a standard set of code style configs I use, I'm just not ready to apply them to Jinja yet. Check out Flask or Werkzeug if you're interested in what that looks like.

Closing this as it will be addressed when I apply Pallets code style configs soon.

Things are in good shape across pallets...  The only repos that fail flake8 --select=E9,F63,F7,F82

pallets/click
pallets/flask-sqlalchemy
pallets/flask-website
pallets/jinja


python3Packages.aioshelly: 1.0.8 -> 1.0.9

Motivation for this change
https://github.com/home-assistant-libs/aioshelly/releases/tag/1.0.9
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 158295 run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.shelly
python310Packages.aioshelly
python39Packages.aioshelly


Polynomial Regression

💥 Proposal
Polynomial Regression is a form of linear regression in which the relationship between the independent variable x and dependent variable y is modeled as an nth degree polynomial. Polynomial regression fits a nonlinear relationship between the value of x and the corresponding conditional mean of y, denoted E(y |x). The goal of polynomial regression is to model a non-linear relationship between the independent and dependent variables (technically, between the independent variable and the conditional mean of the dependent variable).
Have you read the Contributing Guidelines on Pull Requests?
Yes

The code is ready. Please assign me the task.

I would like to take this in Java for CH20.


double-beep: Blacklist belean\W*keto

double-beep requests the blacklist of the keyword belean\W*keto. See the MS search here and the Stack Exchange search here.

belean\W*keto has been seen in 4 true positives, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


Inherit movement planning in the HandEyeCalibrationPlanningClient from the RealtimeRobotPlanningClient

This makes the relationship between these tasks clearer.
This is needed in orchestrators since orchestrators cannot hold two planning clients of different types simultaneously.
I'm merging this into master since calibration will need this version in master as well.

" calibration will need this version in master" -> not sure what you mean, there's nothing broken in master right now. let's stick with the orchestrator branch.

I have an MR in calibration (calibration!250) that is against master since there's no calibration orchestrator branch.
If we want to track the tweak there as part of orchestrators, this change is not needed.
If we don't want to track another branch, we need this to keep master ok.

Sure, if we're going to change master at the same time. thanks


Indeterministic hangs during rendezvousing

Sometimes the argument patching-only solution for PyTorch ≥2 does not work correctly and causes indeterministic hangs during rendezvousing.
For now, I'll debug this further in hopes of finding a minimally intrusive solution, ideally without monkey patching. If this is not possible, we'll have to go with monkey patching, which could mean more fine-grained per-version support (a lot more work!).

Fixed in version 0.0.3, which uses the same solution for PyTorch ≥2 as for older PyTorch versions.


Add Version interface to package

Would be nice to see the Version interface in the package. It would a) allow to fetch the version of the Camunda engine easily and b) can be used to do simple health checks.

Created a pull request with all needed changes: https://github.com/jlucansky/Camunda.Api.Client/pull/78


Merge main_merge_vvdash, Implement Playback Cache and Refactor vvplay_async

Merged change from main_merge_vvdash to have prefetching behaviour
Implemented playback cache to store frames that have already been rendered. This reduces the need for re-rendering and improves playback performance.
Refactored vvplay_async by separating its functionality into distinct part under vvplay_async_prefetch

Manually tested:

vv read basic
vvplay
vvplay_async
vv convert ply to pcd(binary)
vv info

This warning is not resolved for now:
warning: the following packages contain code that will be rejected by a future version of Rust: bindgen v0.54.0

Bindgen is a transitive dependency through tmc2rs, to resolve it, we might need to update the package version for tmc2rs.


delete VT_FW_PITCH_TRIM parameter

We don't need this in addition to regular TRIM.

It's only being added to the actuator_control coming from the FW controller. In master - https://github.com/PX4/Firmware/blob/master/src/modules/vtol_att_control/tailsitter.cpp#L403-L404

I'm wondering so the RC Trims will not work in MC mode? It looks like regular TRIM_PITCH parameter is related to the RC Trims.

I've been using this parameter for a tiltwing that hovers at different angle to forward flight (like @bresch  said). What's alternative to set FW pitch angle different to MC? Cheers

@jux2 if you're talking about the FW frame vs MC (not specifically the actuator trim) then take a look at the fixedwing pitch setpoint offset (FW_PSP_OFF).


field name doesn't have default value when i use factories in phpunit

When I use Factories in a test class in phpunit, field value doesn't insert into database.
It returns error
General error: 1364 Field 'name' doesn't have a default value (SQL: insert into province () values ())
My factory is:
use Faker\Generator as Faker;

$factory->define(\App\Provinces::class, function (Faker $faker) {
    return [
        'name' => $faker->name
    ];
});

Is "name" fillable in your model?

Welcome to Laravel! We are glad to have you as part of the community.
Unfortunately GitHub is not an appropriate platform for general application issues. This is only for issues/bugs with the framework code itself.
Please close your issue, and instead try asking your question on one of the many great community support areas that will likely give you a better answer more quickly:
Laravel Slack (https://larachat.co/)
Laravel.io Forum (https://laravel.io/forum)
Laracasts Forum (https://laracasts.com/discuss)
StackOverflow (http://stackoverflow.com/questions/tagged/laravel)
Thanks!


failed to read all data

Hi
I get 'failed to read all data' error in utlis.py, line 122:
assert len(wf.read()) == 0, 'failed to read all data'
In my case, len(wf.read()) equals 257717640 (257 MB) and it seems ok, why it should be 0?

@bgamini
What model do you use ?
What pretrained weight do you use ?

I downloaded weights from AlexeyAB's repository, from this link:
https://github.com/AlexeyAB/darknet/releases/download/darknet_yolo_v3_optimal/yolov4.weights

You can try this command
 detect.py --weights ./data/yolov4.weights --framework tf --model yolov4 --size 608 --image your_image_path

Hi,
I also get 'failed to read all data' error when I follow your tutorial exactly:
assert len(wf.read()) == 0, 'failed to read all data'
when I tun the evaluate.py like blow:
python evaluate.py --weights ./data/yolov4.weights
I wonder where I'm wrong

You can pass —model yolov4, because default is yolov3

You can pass —model yolov4, because default is yolov3

Yes, the problem has been solved. The model can work normally. Your work is amazing. I am a beginner of computer vision. I will study your code carefully in the next few days and train yolov4 on my own dataset，thanks

You can pass —model yolov4, because default is yolov3

I'm so sorry, In my case, YOLO.CLASSES value was wrong. I changed it and problem solved.
But another error occurred:
InvalidArgumentError:  Input to reshape is a tensor with 1472880 values, but the requested shape has 103968
I solved it too, by adding cv2.resize after cv2.imread in detect.py.


[Edit event] The added image is not displayed in edited event

Environment: All
Reproducible: always
**Build found:**05/06/2023
Preconditions

Go to https://www.greencity.social/#/events
An authorized user shoud be logged
Event shoud be created and found

Steps to reproduce

Click on "Edit event" button
Upload 2 images to event
Click "Publish"
Find edited event and click "More" button
Verify that all images are displayed

Actual result
Only 1 image ia displayed
Expected result
All apploaded images are displayed
User story and test case links
E.g.: "User story #3195
[Test case]https://jira.softserve.academy/browse/GC-3202
https://github.com/ita-social-projects/GreenCity/assets/128155213/79869531-2723-422a-89e5-8c824cfdc979

I checked and 3 img were displayed in my event


Add support for eXtended Module format

While training from MIDI files is good, there's a vast tracker music library, with absolute majority being xm format files. It might be interesting to experiment with creation of tracker-style music with neural network.
There's a xm to midi converter on the net, but it isn't any good. However, it's possible to read xm files directly and there's even ready solution for that in python:
https://sourceforge.net/p/xmp/libxmp-python/ci/master/tree/examples/
Not only it allows to read xm files with python, but it also support several dozens of tracker music formats. Entire modarchive is about 50 GB of music and most of it will be readable with libxmp-python.

Looks like xm format has embedded soundfont information, which my network can't really handle. My network is only designed to take in a raw note stream, so I don't think it would easily work with this network.
Perhaps some other, more complex network architecture would work well with xm files.

Yes, all samples used in track are embedded into xm file. But actually, only note stream is necessary to train the network. Those samples could be just considered to be separate insruments. Pretty much like instrument ID in MIDI, xm insrument ID is just a digit - reference to particular instrument slot. You can swap, for example, a piano sample with a violin sample and track will still sound the same, because notes don't change. So it should be still possible to train network on xm files. Embedded sample data could be ignored completely and instrument ID could be used to split track into separate note streams for each instrument.

I've drawn what I mean over the screenshot of MilkyTracker - one of tracker music editors. xm tracks are have several channels. In each channel, any number of different xm instruments could be playing. In note slots, there could be either note, note off, or empty space. For note record, there's a note, instrument number, and (optionally) volume and effect.


README

Please make suggestions for informative README.md files

[x] landing page readme
[ ] notebook readme

I am making some suggestions here.
Let me know what you think!

https://github.com/flatironinstitute/Cryo-EM-Heterogeneity-Challenge-1/pull/34


Chat Export Theme

Hey! Thanks for the nice themes. :) I would like to kindly request a dark theme for the exported chat history. Currently it's blinding white and I requested Telegram countless times for a dark version of chat export. They did nothing about it. I edited the colours in style.css and managed to turn the history dark but I'm sure you can do it better. Here is the original css file.
style.zip
Hope you have time to do it. Thanks! :)

Hi!
Unfortunately, I don't have time to write all the styles by hand and customize them, mainly because I don't use Telegram's chat export feature myself. But I created a repo with a remap script for the current style: https://github.com/VChet/telegram-export-dark
It already has all 4 color themes ready to use and if you want you may customize it to support more colors or even create your own theme.
I'm closing this issue, if you'll have problems or suggestions with those themes, feel free to create a new issue at https://github.com/VChet/telegram-export-dark.


darwin: stop using gccStdenv when stdenv works fine

Motivation for this change
masscan, rig and sl packages are built with gccStdenv on darwin, but they build just fine with stdenv.
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

@ofborg build masscan rig sl

nice


Add option for toggling whether merge success emails are sent.

Closes #150
Cue /giphy i have no idea what i'm doing...
I don't have the means to test or verify this so I'd appreciate help in that regard.

LGTM, simple way to resolve the issue :)

Friendly ping!


Fixed the positioning of the save/cancel button

This is an improvement for #119. Goofy things happen with the save/cancel buttons when you add or edit transactions with the swap cleared/flags feature enabled. This iteration should at least provide a usable/consistent experience, even with split transactions.

Thank you!


Copy & Customize doesn't ask for location or name of the new profile

Currently when you use Copy & Customize on the main profile, the resulting file is auto-named (MixedRealityToolkitConfigurationProfile with a sequence number to make it unique) in a predefined location (MixedRealityToolkit.Generated/CustomProfiles).
We've been working with customers that want to maintain multiple profiles for various devices or situations. Having a better naming convention and a way to determine the place to store it would be more convenient. This would require additional UI like being used for cloning various settings in the Profile and ask for a location and a name.
The work-around now is to just use Copy & Customize and when it's done just move the file and/or rename the file.

Also see #4961 for a follow-up request


Added advanced setting to rotate horizon by 90 degrees (for devices w…

Please make sure these boxes are checked before submitting your pull request - thanks!

[x] Run the unit tests with gradlew app:connectedAndroidTest to make sure you didn't break anything

[x] If you have multiple commits please combine them into one commit by squashing them.
…ith locked orientation, such as

smartglasses, or android pc)

Hey! Sorry I missed this.  I've been neglecting Sky Map and wasn't paying attention.


[BUG] nixvim.highlight does not work?

Field
Description

Plugin
none

Nixpkgs
unstable

Home Manager
unstable

Description

:hi! link @comment.todo DiagnosticInfofixes the issue:

Snippet from generated init.lua:
vim.loader.enable()
-- Highlight groups {{
do
  local highlights =<EMAIL_ADDRESS>= {["link"] =<EMAIL_ADDRESS>= {["link"] =<EMAIL_ADDRESS>= {["link"] =<EMAIL_ADDRESS>= {["link"] = "DiagnosticWarn"},["NormalFloat"] = {["bg"] = "NONE"},["Pmenu"] = {["bg"] = "NONE"}}

  for k,v in pairs(highlights) do
    vim.api.nvim_set_hl(0, k, v)
  end
end
-- }}

Minimal, Reproducible Example (MRE)

programs.nixvim = {
  plugins.comment-nvim.enable = true;
  highlight = {
<EMAIL_ADDRESS>= "DiagnosticInfo";
<EMAIL_ADDRESS>= "DiagnosticHint";
<EMAIL_ADDRESS>= "DiagnosticWarn";
<EMAIL_ADDRESS>= "DiagnosticError";
  };
}

https://github.com/nix-community/nixvim/pull/1036/files implemented an override for existing highlights that get declared by something else and need to be overwritten. The highlights option is declared at beginning of the config so new highlight groups can be used by the rest of the config.


Session from session_id claim in JWT does not exist

Bug report

[x] I confirm this is a bug with Supabase, not with my own application.
[x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug
When I try to use the setSession() I get a response error like: "Session from session_id claim in JWT does not exist", by trying to decode the JWT token, I am able to see that it has the session_id. The authentication is create in two steps, signInWithPassword() in a project similar to "Google Auth" which then do a redirect to another project with the access_token and refresh_token in the query strings, that then is consumed and set in the setSession().
Steps to reproduce the behavior, please provide code snippets or a repository:

Create a project with a basic login that uses the signInWithPassword()
When the authentication is successful, redirect to another project with the session.access_token and the session.refresh_token
When redirect, fetch the access_token and the refresh_token from the query string and use setSession().
The setSession() at that point will return:

{   "code": 403,   "error_code": "session_not_found",   "msg": "Session from session_id claim in JWT does not exist" }
Expected behavior
The setSession() must return a valid session instead of error 403.
Screenshots

System information

OS: Windows 10
Version of supabase-js: 2.43.4
Version of Node.js: 20.10.0

Tried with the following version of auth-js: 2.64.2 and the 2.61.0 (This one is prefered as it prevents the LockManager error in Angular).

Closing this issue as in the authentication application, after the signInWithPassword() and the redirect, there was a signOut() by removing it and by handling the signOut() only from the main application and not the auth, resolve the issue.


Remove arity check from ref prop type

In #54 we added a ref prop type, and in #55 added an arity check for callback refs. Unfortunately, that breaks a common pattern of having an empty function as a default value. For example:
function SomeButton({ buttonRef }) {
  return <button buttonRef={buttonRef} />;
}

SomeButton.defaultProps = {
  buttonRef() {}
};

We could leave the arity check and change default values to undefined, instead. However, that's an unknown amount of work, and I think we're better off removing the arity check and accepting functions with any number of arguments.
@ljharb , what do you think?

Fair point; we could also accept both 0 and 1 but then are we really rejecting anything useful?

Thanks!


[All hosts] Community call agenda update

Adding a few more items for July call.

Docs Build status updates of commit 106efb0:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error: PullRequestMergeConflict] Cannot sync git repo to specified state. Please make sure the pull request is mergeable.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 3428c85:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/overview/office-add-ins-community-call.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit bf14c2e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/overview/office-add-ins-community-call.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


feat: updates from spectrum-tokens sync operation

https://github.com/mrcjhicks/spectrum-tokens-studio-data/actions/runs/6881702928

READING spectrum-tokens: ./spectrum-tokens/packages/tokens/src/
READING  tokens studio: ./spectrum-tokens-studio-data/src/tokens-studio/spectrum2-colors/
TOKENS STUDIO DATA IS COLOR ONLY

WARNING: STUDIO INCLUDES DEPRECATED TOKEN: floating-action-button-shadow-color [f843b1b7-4b2f-496e-a679-b0372e49d575]

LOADED SPECTRUM TOKENS: 2410
LOADED STUDIO TOKENS:   750
NEW TOKEN VALUES:     1
./spectrum-tokens/packages/tokens/src/color-palette.json
blorck


Route recommendation search to recsys 5% of the time + add user_id

Ticket
Closes #334 send some recommended requests to recsys
Approach

doSearch:

If the search options include related_to, route that to the new searchRecommendations which performs the 5% check + appends user_id at the end. This way, we don't need to alter the function signature of doSearch.
Else, run proceed as normal.

Aside
The ticket suggested to use the same method as ads, but not sure why there is a need to multiply by 1000, so I skipped that since the resolution from Math.random() is the same either way and we just want the percentage.

Working great, thank you @infinite-persistence ! Good call on the math.random, that works well too. Johnny said to wait until tomorrow to ship so he can monitor.