Structure & Enumeration has same name will produce weird result

Hi, I found out that when a StructureType and EnumType have the same name will produce weird result.
Here's the whole wsdl files.
Air.zip
In Air.xsd
There's xs:element name="FlightType" which should be generated into StructType/FlightType, also referenced as an attribute in xs:element name="AirSearchModifiers"
<xs:element name="FlightType">
	<xs:annotation>
		<xs:documentation>Modifier to request flight type options example non-stop only, non-stop and direct only,
            include single online connection etc.
    </xs:documentation>
	</xs:annotation>
	<xs:complexType>
		<xs:attribute name="RequireSingleCarrier" type="xs:boolean" use="optional" default="false"/>
		<xs:attribute name="MaxConnections" use="optional" default="-1">
			<xs:annotation>
				<xs:documentation>The maximum number of connections within a
                    segment group.</xs:documentation>
			</xs:annotation>
			<xs:simpleType>
				<xs:restriction base="xs:integer">
					<xs:annotation>
						<xs:documentation>To support other provider like 1P maxConnection values ranged from -1 to 3. Here -1 means user don't know about connection information.
                                 In case of maxConnection -1, maxStop value will be considered.
                           </xs:documentation>
					</xs:annotation>
					<xs:minInclusive value="-1"/>
					<xs:maxInclusive value="3"/>
				</xs:restriction>
			</xs:simpleType>
		</xs:attribute>
		<xs:attribute name="MaxStops" use="optional" default="-1">
			<xs:annotation>
				<xs:documentation>The maximum number of stops within a
                    connection.</xs:documentation>
			</xs:annotation>
			<xs:simpleType>
				<xs:restriction base="xs:integer">
					<xs:annotation>
						<xs:documentation>To support other provider like 1P maxStop values ranged from -1 to 3. Here -1 means provider can ignore the maxStop value.</xs:documentation>
					</xs:annotation>
					<xs:minInclusive value="-1"/>
					<xs:maxInclusive value="3"/>
				</xs:restriction>
			</xs:simpleType>
		</xs:attribute>
		<xs:attribute name="NonStopDirects" type="xs:boolean" use="optional"/>
		<xs:attribute name="StopDirects" type="xs:boolean" use="optional"/>
		<xs:attribute name="SingleOnlineCon" type="xs:boolean" use="optional"/>
		<xs:attribute name="DoubleOnlineCon" type="xs:boolean" use="optional"/>
		<xs:attribute name="TripleOnlineCon" type="xs:boolean" use="optional"/>
		<xs:attribute name="SingleInterlineCon" type="xs:boolean" use="optional"/>
		<xs:attribute name="DoubleInterlineCon" type="xs:boolean" use="optional"/>
		<xs:attribute name="TripleInterlineCon" type="xs:boolean" use="optional"/>
	</xs:complexType>
</xs:element>

And under xs:element name="RepricingModifiers"
It has a same name attribute, which should be generated into EnumType/FlightType
<xs:attribute name="FlightType" use="optional" default="Direct">
	<xs:annotation>
		<xs:documentation>Type of flights to be returned. Values are 'NonStop', 'Direct', 'SingleConnection' and 'NoRestrictions'. Available in AirExchangeMultiQuoteReq only.</xs:documentation>
	</xs:annotation>
	<xs:simpleType>
		<xs:restriction base="xs:string">
			<xs:enumeration value="Direct"/>
			<xs:enumeration value="NonStop"/>
			<xs:enumeration value="SingleConnection"/>
			<xs:enumeration value="NoRestrictions"/>
		</xs:restriction>
	</xs:simpleType>
</xs:attribute>

But the generated result only produced 1 FlightType into EnumType, and AirSearchModifiers's FlightType attribute became an enum instead of an object, now there's no way I could properly set FlightType element into AirSearchModifiers since it only accepts string.
Please help.

As there is an element FlightType and an enumeration FlightType, the SoapClient does only return the element FlightType:
struct FlightType
    boolean RequireSingleCarrier
    anonymous688 MaxConnections
    anonymous689 MaxStops
    boolean NonStopDirects
    boolean StopDirects
    boolean SingleOnlineCon
    boolean DoubleOnlineCon
    boolean TripleOnlineCon
    boolean SingleInterlineCon
    boolean DoubleInterlineCon
    boolean TripleInterlineCon

So there is never a returned type such as:
string FlightType

Consequently, the parsers does not identify and differentiate the two elements...
WIP...

Tell me how it goes with the feature/issue-177 branch,  when you're back :wink:

Any chance you can test?
Thx


Add donwload demo code for the demo repository

for demo i've added a link to the demo repository in case someone need all components and download the zip file

Nice addition. I think there must be an extra break to create a new paragraph.


Generic exception with (seemingly) valid grammar input

Describe the bug
When using Lark, I keep getting generic exceptions instead of any detailed report. I am unsure if this is caused by bad grammar input, or from a bug in Lark (I'm guessing the former), but I'd love it if we could get to the bottom of this.
Traceback (most recent call last):
  File "lark_test\venv\lib\site-packages\lark\load_grammar.py", line 327, in pattern
    term_name = self.term_reverse[p].name
KeyError: ''

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "lark_test\venv\lib\site-packages\lark\load_grammar.py", line 331, in pattern
    term_name = _TERMINAL_NAMES[value]
KeyError: ''

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "lark_test\venv\lib\site-packages\lark\visitors.py", line 91, in _call_userfunc
    return f.visit_wrapper(f, tree.data, children, tree.meta)
  File "lark_test\venv\lib\site-packages\lark\visitors.py", line 390, in _vargs_inline
    return f(*children)
  File "lark_test\venv\lib\site-packages\lark\visitors.py", line 374, in f
    return _f(self, *args, **kwargs)
  File "lark_test\venv\lib\site-packages\lark\load_grammar.py", line 333, in pattern
    if is_id_continue(value) and is_id_start(value[0]) and value.upper() not in self.term_set:
IndexError: string index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "lark_test\main.py", line 5, in <module>
    parser = Lark(grammar.read(), start="PROGRAM")
  File "lark_test\venv\lib\site-packages\lark\lark.py", line 348, in __init__
    self.terminals, self.rules, self.ignore_tokens = self.grammar.compile(self.options.start, terminals_to_keep)
  File "lark_test\venv\lib\site-packages\lark\load_grammar.py", line 604, in compile
    tree = transformer.transform(rule_tree)
  File "lark_test\venv\lib\site-packages\lark\visitors.py", line 170, in transform
    tree = t.transform(tree)
  File "lark_test\venv\lib\site-packages\lark\visitors.py", line 187, in transform
    subtree.children = list(self._transform_children(subtree.children))
  File "lark_test\venv\lib\site-packages\lark\visitors.py", line 116, in _transform_children
    yield self._transform_tree(c)
  File "lark_test\venv\lib\site-packages\lark\visitors.py", line 183, in _transform_tree
    return self._call_userfunc(tree)
  File "lark_test\venv\lib\site-packages\lark\visitors.py", line 97, in _call_userfunc
    raise VisitError(tree.data, tree, e)
lark.exceptions.VisitError: Error trying to process rule "pattern":

string index out of range

Process finished with exit code 1

To Reproduce
main.py
from lark import Lark

if __name__ == "__main__":
    with open('grammar.ebnf', 'r') as grammar:
        parser = Lark(grammar.read(), start="PROGRAM")

grammar.ebnf

program : statement_or_func ("\n" statement_or_func)*
statement_or_func : sequence | func_stat

sequence : statement (le statement)*
le : "\n" | ";"
brackets_seq : (sequence)
brack_or_stat : brackets_seq | statement
statement : ""
        | decl_stat assignment_stat
        | if_stat
        | do_until_stat
        | while_stat
        | return_stat
        | print_stat
        | input_stat
        | func_stat
        | call_stat
        | comment_stat

decl_stat : LET assignment_stat ("," declaration)*
declaration : ID | assignment_stat

assignment_stat : ID "=" expression

if_stat : IF (condition) THEN brack_or_stat elsepart

elsepart : "" | ELSE brack_or_stat

do_until_stat :  DO brack_or_stat LOOP UNTIL (condition)

while_stat : WHILE (condition) brack_or_stat WEND

return_stat : RETURN (expression)

print_stat : PRINT MESSAGE"," expression_list
expression_list : expression ("," expression)*

input_stat : INPUT MESSAGE"," ID ("," ID)*
func_stat : SUB ID funcbody
funcbody : formalpars brackets_seq
formalpars : ("" | formalparlist)
formalparlist : ID ("," ID)*
call_stat : CALL ID actualpars
actualpars : ("" | actualparlist)
actualparlist : actualparitem ("," actualparitem)*
actualparitem : expression | ID

comment_stat : REM MESSAGE
condition : boolterm (OR boolterm)*
boolterm : boolfactor (AND boolfactor)*
boolfactor : NOT [condition] | [condition] | expression RELATIONAL_OPER expression
expression : OPTIONAL_SIGN term (ADD_OPER term)*
term : factor (MUL_OPER factor)*
factor : CONSTANT | (expression) | ID | call_stat

RELATIONAL_OPER : "==" | "<" | "<=" | "<>" | ">=" | "<"
ADD_OPER : "+" | "-"
MUL_OPER : "*" | "/"
OPTIONAL_SIGN : "" | ADD_OPER
ID : (ALPHA)(ALPHA|DIGIT)*

LET : "LET"
DO : "DO"
LOOP: "LOOP"
UNTIL: "UNTIL"
WHILE: "WHILE"
WEND : "WEND"
SUB : "SUB"
CALL : "CALL"
INPUT : "INPUT"
PRINT : "PRINT"
IF : "IF"
THEN : "THEN"
ELSE : "ELSE"
AND : "AND"
NOT : "NOT"
OR : "OR"
RETURN : "RETURN"
REM : "REM"
MULTI_LINE_COMMENT_START : "%*"
MULTI_LINE_COMMENT_END : "*%"
ALPHA : "a".."z" | "A".."Z"
DIGIT : "0".."9"
INTEGER : /-?{DIGIT}{1,5}/
MESSAGE : /"(\\.|[^"\\])*"/
CONSTANT : INTEGER | MESSAGE

I'm using the latest version of Lark installed from PIP, with python 3.9.0

Maybe this will help: https://lark-parser.readthedocs.io/en/latest/recipes.html#unwinding-visiterror-after-a-transformer-visitor-exception

I encountered a similar issue. The cause seems to be the empty patterns ("")

What do you mean by similar issue? What are such cases?

What do you mean by similar issue? What are such cases?

I encountered the same exception string index out of range and found this ticket by google. This is what I meant by similar issue.
The merge request #916 checks such cases, which are empty patterns.


speeding up Travis

https://docs.travis-ci.com/user/build-stages/
https://travis-ci.com/github/aws-cloudformation/cfn-python-lint/builds
Ran for 8 min 33 sec -> Ran for 4 min 42 sec

I don't understand, why did you get rid of the linting? I rely on it, I never bother to run it locally because I know Travis will run it for me..

I don't understand, why did you get rid of the linting? I rely on it, I never bother to run it locally because I know Travis will run it for me..
I don't think I care that Travis takes 8 minutes to run, you can do something else while it works, plus it's the last barrier to catch problems

didn't get rid of anything, just running them in parallel now instead of sequentially

Oh. My bad 🤦♀


[MAINT] Revamp the settings validation steps

Type of PR

[ ] BUG
[ ] FEAT
[x] MAINT
[ ] DOC

Is your Pull Request linked to an existing Issue or Pull Request?
This PR is start of three PRs which are intended to make incremental improvements to the settings object and validation - https://github.com/moj-analytical-services/splink/pull/1675.
The other two will:

Clean up how we load our settings into linker.
Add in additional functionality to the settings validator.

Give a brief description for the solution you have provided
Functionally, the code is the same.
The primary changes in this PR are:

The sprawling classes in the old structure have been pulled apart into functions. This makes reusing the code far easier and the structure flow in a more straightforward manner. For example, the confusing InvalidColValidator is now a series of functions.
Renaming of variables, functions and classes to make them more descriptive. Relatively self explanatory, but I've changed things such as InvalidCols -> InvalidColumnsLogGenerator, because that's precisely what it does...
Removal of the confusing class inheritance structure (see 1).
Renaming of scripts and migration of the log strings to a new settings_validation_log_strings.py script.

PR Checklist

[ ] Added documentation for changes
[ ] Added feature to example notebooks or tutorial (if appropriate)
[x] Added tests (if appropriate)
[ ] Updated CHANGELOG.md (if appropriate)
[ ] Made changes based off the latest version of Splink
[x] Run the linter

Btw, I'm not sure if the lint error is from the base branch or your changes, but would be good to have a tinker with that before merging


Update README.md to include upload to s3 utility

adding description for upload to s3 utility

@idomeidan , @yuvalrhino , can you review and approve?


Shape's outline color from a table column

Currently, the color of a set of shapes can be set according to a column in the table, but for the outline, it's only possible to specify a single color common to all shapes.
I would like to propose the possibility to select different outline colors for different shapes.
My use case is that I automatically generate annotated regions around certain groups of cells and I want to display only the outline because these regions can contain heterogeneous cells (colored + grey) that I still want to be able to show, as in the example in the following image.
If you think it's a good idea I can attempt a PR :)

Hi @marcovarrone, the addition of this feature would very nice, if you could propose a PR it would be super! We are happy to review it and assist you with technical questions.


fixed #175 also for foreign keys with null values

I feel like such a pester but was wondering if you guys had any intention of cutting a formal release for this? If not, no worries - I'm fine working off of the commit sha.
Thank you one more time for the awesome support :)

I think we'll be doing a release once #179 is merged and confirmed. Since it drops support for Django 1.7, we'll be going to 0.7.0.
@hynekcer: I can do a release in the next couple days, or wait if you've got imminent merges. I'm also fine with releasing now and pushing out 0.7.1 later.

It is still about 18 commits before the standard support of Django 1.10 announced as the target of 0.7, however any release is important soon, it was also announced 0.6.9 is the last that supports Django 1.7 a  and simple_select_related is a useful feature that can be in release notes..

Oh, okay, I forgot how we had specified the EOL for 1.7.
In that case, I can do a 0.6.10 release to push these changes out. I'll be merging #179 shortly, and will do the release in the next day or two.


Update index.md

testing project

Why:
Closes [issue link]

What's being changed:

Check off the following:

[ ] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[ ] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@athifbinu
This seems to be opened accidentally, I am going to close it now :yellow_heart: Take a look at the contributing.md to learn how to contribute in this repo. You can open a discussion if you have any questions :sparkles:


Add missing availability guards in tests

Motivation
Some of the test code was missing availability guards for Apple platforms, resulting in build failures for these platforms, e.g.
error: 'init(pemDocument:)' is only available in iOS 14 or newer
             let privateKeyAfterRoundtrip = try Certificate.PrivateKey(pemDocument: privateKey.serializeAsPEM())

Modifications
Add missing availability guards. I've tried to keep them as scoped as possible. Some of the tests rely on initializers in CryptoKit that are only available since iOS 14. One suite of tests used this so extensively that I made the whole suite only available on newer platforms.
Result
Tests can now build and run on iOS and other Apple platforms.

@swift-server-bot add to allowlist


Add new device RD03

Fix operating mode for RD03 model

Change xqnetwork/mode to xqnetwork/get_netmode

Note: Old devices only check Xiaomi AIoT Router AX3600

Add new device RD03
Change MESH value

Note: Only check by using RD03

It has been 10 months since this PR. Are there any blockers that need to be resolved before merging?
I hope that this get merged soon, because the RD03 is a competitive product.

no suport BE 3600 RD15

no suport BE 3600 RD15

This is a PR for RD03, not RD15. You've gone to the wrong place. You shouldn't even comment this in a PR in the first place, because you are raising a bug/feature request and the correct place for these are at the issues page.


Support parameters on path level

This adds support for path-level parameters that can be overridden at operation level, as per this part of the Swagger spec. These parameters were previously ignored, generating incomplete queries and mutations.

Also, please update queryIds.spec.ts, queries.spec.ts and mutations.spec.ts files with the new parameters so we can verify everything is propagated properly, thanks!

Thanks again for the contribution @daniel-pulley . I've published these changes, they are now available under<EMAIL_ADDRESS>on NPM


Wrong versionCode/Name for version 1.1.0

https://github.com/Techno-Disaster/tldr-flutter/blob/54faf59b23ea79a510150815ed9a95a5d121d6ef/android/app/build.gradle#L16-L21
This breaks the F-Droid build, please fix them and tag a new version.

@jspricke It should pickup the version name and code from the pubspec.yaml, but I released the tag first and then pushed the version code and name commit. So to start a new build all you need is a new tag right?

Please don't rewrite git tags as they are not updated by a git pull. Simply make a new release, there are enough numbers left ;).

Published v1.1.0 hopefully that fixes stuff

@jspricke looks like the new version is still not up on f-droid, iirc there was some page where I could see the build logs but can't find it now. Could you link me to it to check if there is any error?

it was not picked up cause the latest version (1.1.0) was already tried and the new tag did not match the version. I fixed it manually: https://gitlab.com/fdroid/fdroiddata/-/commit/627a9291aef72f0be60356cb46092810bc36c1d6

it was not picked up cause the latest version (1.1.0) was already tried and the new tag did not match the version. I fixed it manually: https://gitlab.com/fdroid/fdroiddata/-/commit/627a9291aef72f0be60356cb46092810bc36c1d6

Makes sense, thanks for the help. Will keep in mind when publishing the next update.


[LP] An database error occurred whilst loading permissions data. Please try again later.

I know there are similar issues out there but I am a newbie at all this stuff so didn't understand a word of it. The server boots completly fine but when a player joins the real issue occurrs: [LP] An database error occurred whilst loading permissions data. Please try again later. I looked in the console and found this: https://pastebin.com/XbsVfY3y. I don't know what is happening at all I've had my server for a few days now and it has worked completly fine so I don't know why this is happening although I do know the offending file is: luckperms-h2.mv.db . Sooo... Please help.

Can you please update to the latest version of LP https://luckperms.github.io that may fix it

Thanks it fixed!

Still exist on Nukkit

Open a new ticket and provide your full log. Be sure to follow the template.


systemName Property of FakeFtpServer Does Not Match the Chosen FileSystem

When setting up a FakeFtpServer, the systemName property defaults to 'WINDWS'. If a non-windows FileSystem is assigned during setup, the systemName property is not updated and any calls involving the SYST command will potentially return incorrect values. It is possible to fix this by explicitly setting the systemName property, but it is not clear from the documentation that this is required.
Suggestion: if this is intended behavior, then the documentation needs to mention the need to set SystemName and outline what the valid values are.

FakeFtpServer will now use the systemName from the configured FileSystem for the SYST command, but can be overridden by setting the systemName property on FakeFtpServer.


HydrationBoundary not rendering page with updated cache, like Hydrate used to do.

Describe the bug
In React Query v5,  doesn't behave the same as  in v4 (at least for Next.js pages router).
Despite the migration instructions, it doesn't seem to update the queryCache when the new page is rendering, using client side navigation.
It looks like the query cahce is updated too late, when the new page has already rendered.
In React Query v4 it works fine.
Your minimal, reproducible example
Attached in Steps to reproduce
Steps to reproduce
Minimal example with v5:
https://codesandbox.io/p/sandbox/sharp-dhawan-qm6ykp?embed=1&file=%2Fsrc%2Fpages%2F[[...catchAll]].js%3A27%2C42
Video of v5 (wrong):
https://github.com/TanStack/query/assets/2103443/6dcd1038-2844-47cc-97ae-be5833752ecf

Minimal example with v4 (correct behaviour):
https://codesandbox.io/p/sandbox/determined-fog-jjny9g?embed=1&file=%2Fsrc%2Fpages%2F[[...catchAll]].js%3A27%2C40
Video of V4 (correct):
https://github.com/TanStack/query/assets/2103443/e580953a-a983-4ae4-810c-4916ef122430
Expected behavior
As a user, I expect when using , the cache to be updated before the children render.
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform

Any platform

Tanstack Query adapter
react-query
TanStack Query version
v5
TypeScript version
No response
Additional context
No response

@Ephem: is that possible that this PR relates to the problem described in this issue? Thanks in advance for any helpful insight here.

@emzoumpo Thanks for filing this issue.
@mlazzarini Thanks for doing some research and pinging me!
As that PR describes, and as is described here in the migration guide, this is an intentional change.
In v4, a page transition could kick off, immediately put new data into the cache which would update the current page unexpectedly even before the transition to the next page was done, and even if that transition was then aborted. We had an observable side effect in render which is not allowed in React.
The new approach in v5 isn't perfect either. If the data already exists in the cache it is hydrated after the initial render which can be jarring in some cases, but at least it is eventually consistent.
The story for having external caches like React Query work with React's concurrent features is a bit rough and while there might be ways to improve this in the future, in the meanwhile we want to opt for correctness.
You probably did it that way to showcase the problem, but just to be clear the reason the sandbox you provided isn't updating at all is because useQueryClient().getQueryData(["pageData"]) renders the current data in the cache but never sets up a observer to re-render when the data updates. Using a useQuery as in this fork works as expected.
I'm curious, did you file this issue because you have some current use case like the one in the sandbox where you are reading data from the cache directly, or because you noticed the page is rendering with old data first and then rerendering?

Hi @ephem, thank you for your reply.
It's both. Of course the example is pretty simple to showcase the issue.
We use this pattern a lot, so we have hooks that read directly from cache without subscribing / using useQuery.
The reason for that is that there is a lot of data that is fetched / set on the server, when we call Next.js getServerSideProps(), which is called for both Server & Client Side navigation.
This data cannot and/or should not be fetched on the client side, for security and/or performance reasons.
That means that the cache is populated with the relevant data inside of the getServerSideProps() with prefetch() and is already available to the page components, the same way pageProps are available to the page components when the new page begin rendering.
Looking at the linked PR, I think that the following statement is not true for Next.js Pages Router in general, since <HydrationBoundary /> is called / used potentially on every page transition:
While this doesn't change the API in any way it's technically a breaking change, though I suspect and hope very few will notice any difference, especially since most people currently only use HydrationBoundary once during the initial page load and since all queries are new at that point, that behaviour should not have changed.

Also, I think it is very highly dependent on the app framework / scale / requirements and extend of use of React Query, whether the following statement makes it an ok tradeoff:
This means the new page will first render with existing data+new data, to immediately rerender to show only new data when the effect has run.

If the React Query cache contains a lot of data (that are being supposed to be replaced / merged when the new page renders), rerendering the page first with old date and then once again with new is something that can definitely have detrimental impact on the performance, responsiveness and layout shift of the app.
One of the benefits of Next.js is that you can prerender and / or prepopulate data so when the new page transition happens, data will be there in order to exactly avoid this kind of re-rendering after the page transition (when user expects data to be updated).
So, while I see the reason why this new behaviour is more correct, it comes with non-negligible tradeoffs.
In conclusion, I think that migrating to this new behaviour will be hard to do in our scale, since the options would be to fetch data on the client or add QueryCache listeners I suppose (please correct me if I'm wrong).
Right now this is the only thing that prevents us from upgrading from v4 to v5, and it doesn't look like it can be done incrementally.
If such behaviour is indeed desired for most users, would it be possible to have an option to opt-in to the old behaviour with a different Hydration component or property, so that we can have a chance of assessing and migrating our code gradually?

We use this pattern a lot, so we have hooks that read directly from cache without subscribing / using useQuery.

reading from the cache during rendering without creating an observer was never a recommended pattern. What you'd want is to call useQuery and set enabled:false

@emzoumpo Thanks for providing details around your use case!

I think that the following statement is not true for Next.js Pages Router in general

I agree, that formulation is a bit sloppy. I still hope few notice a huge difference though.

If the React Query cache contains a lot of data (that are being supposed to be replaced / merged when the new page renders), rerendering the page first with old date and then once again with new is something that can definitely have detrimental impact on the performance, responsiveness and layout shift of the app.

So, while I see the reason why this new behaviour is more correct, it comes with non-negligible tradeoffs.

This is all true. Another way to see it is in a way we are opting out of prerendering features when this happens. We still think favouring correctness is the correct path here though to avoid bugs and surprising behaviour. We fully acknowledge that React Query is not fully compatible with concurrent features.
As @TkDodo mentioned, reading in render is problematic and you want an observer. If you still want to mimic the old behaviour in v5 (even though it's not the correct tradeoff for a library, it might be right for you!), the low level hydrate() API is still available so you can build your own <Hydrate> that works as before. I think you can just copy-paste the code from v4 into it's own file and it should work.
(If anyone wants more context, there's an old, and slightly outdated, discussion about it in the React 18 working group: https://github.com/reactwg/react-18/discussions/121)

Thank you very much for the detailed response, @Ephem!
I see now that they are cases in which the logic we're following might not be correct, especially as React, Next.js and React Query evolves, and new rendering modes are introduced.
I can understand that the new behaviour is more correct and an acceptable tradeoff for React Query, and we'd like to eventually migrate to properly support this.
That being said, there are a lot of nice features & improvements on React Query v5, that we wouldn't want to miss, until all of our code is refactored to account for the new behaviour.
I will try to include the code from v4, and hopefully that would be enough to migrate to v5 for now, and then gradually refactor our code so it is correct with the new behaviour, so we eventually remove the workaround.
Thank you once again for pointing out the possible solutions and offering a possible path to move forward!

Hi @Ephem, I encountered a similar issue related to hydration queries. In this scenario, I have queries that are already in the cache but contain empty data.
For example, I have a page with both a ClientComponent and a HydratedComponent, and they both fetch the same query, as shown below:
<>
  <ClientComponent />
  <HydratedComponent />
</>

As ClientComponent created query in cache, then HydratedComponent will not hydrate data in render and will put hydration process in a queue, as result I have empty data from cache for the first render, cause it wasn't hydrated.
Could we improve the condition in HydrationBoundary which checks whether query in cache or it has empty data?
I mean something like that:
if (!existingQuery || !existingQuery.state.data) {
  newQueries.push(dehydratedQuery)
}

By making this change, the first render with empty data would have prefetched data, resulting in a more accurate representation of the content and we will use a hydration queue in case of react transitions to prevent showing new data until the transition is finished.


[tool] Add CADisableMinimumFrameDurationOnPhone to iOS templates

This PR adds CADisableMinimumFrameDurationOnPhone to the iOS templates.
Fixes https://github.com/flutter/flutter/issues/94508
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

I think we should wait until we have some baseline benchmarks for the devices before we land this as the default. Interested users can manually add this pref value if they desire. Once <> PR lands, users will be able to opt-in to default max frame rate by setting this manually, after that we can get some benchmarks specifically targeting lack of idle time and energy usage, we can then make this the default. I attempted to capture the sequence of steps here: https://github.com/flutter/flutter/issues/90675#issuecomment-971863161

Convert to draft so we don't accidentally merge. this is blocked by https://github.com/flutter/flutter/issues/92444

Convert to draft so we don't accidentally merge. this is blocked by #92444

this has been marked WONTFIX, so we should figure out next steps here.

Example migration: https://gist.github.com/jmagman/d7b76fc20ff5d5808f6ce26ea3d622e9

Gold has detected about 10 new digest(s) on patchset 3.
View them at https://flutter-gold.skia.org/cl/github/94509

We need to land this to address some iPhone 13 pro issue, see: https://github.com/flutter/flutter/issues/99151#issuecomment-1062098686


It keeps saying Server error all the time on backstroke.us

Recently for all git repositories I am registering, it is saying git error:

But if I go to the main page clicking on the Links button, the hook is on:

That's weird. Looks like the logs mention that some sort of rate limit from github's end (for your user token) was reached. Where you doing something that called backstroke repeatedly?

No, I was not using the github api, or calling backstroke URLs at the moment, or any time near it. Perhaps, you could put this full message on the website instead of just Server error.

Hmm, let me investigate. I've made that change (more descriptive error messages) in the latest code, will be live next time I deploy.

I was getting this as well trying to link to a forked repo in one of my organizations. I transferred the fork out of the organization to my personal account and it works now.

i was having the issue as well what fixed it for me was to go to the organizations settings 3rd party access and i removed the application restrictions

Huh. What application restrictions are you referring to? Maybe that would help reveal the source of the problem? I can't seem to find the options you are referring to.

In GitHub there options under your organization settings
On Sep 7, 2017 3:43 PM, "Ryan Gaus"<EMAIL_ADDRESS>wrote:
Huh. What application restrictions are you referring to? Maybe that would
help reveal the source of the problem? I can't seem to find the options you
are referring to.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/1egoman/backstroke/issues/63#issuecomment-327946851,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAX46s12uMSk6MeFdIE_mO6hnKLZtgL2ks5sgHGHgaJpZM4Ouibl
.

Fixed by https://github.com/backstrokeapp/server/issues/66


Incompatibility with Windows 7

Which version of TonKeeper is compatible with Windows 7 64bit?

Windows 7 and Windows 8 are not support. Tonkeeper support modern version of Windows OS.


cannot find service pppd-dns on amazon linux

hi i am trying to use this on amazon linux and i cant find the service pppd-dns is there a specific package that i need to install to have the service ?

Sorry for the late response. It should work with for example Ubuntu. I'm unsure how Amazon may have modified their images


[Bug]: selene diagnostics not excluding files from selene.toml config

FAQ

[X] I have checked the FAQ and it didn't resolve my problem.

Issues

[X] I have checked existing issues and there are no issues with the same problem.

Neovim Version
NVIM v0.9.5 Build type: RelWithDebInfo LuaJIT 2.1.1692716794
Dev Version?

[X] I am using a stable Neovim release version, or if I am using a dev version of Neovim I have confirmed that my issue is reproducible on a stable version.

Operating System
MacOS 14.4.1
Minimal Config
-- this template is borrowed from nvim-lspconfig
local on_windows = vim.loop.os_uname().version:match("Windows")

local function join_paths(...)
  local path_sep = on_windows and "\\" or "/"
  local result = table.concat({ ... }, path_sep)
  return result
end

vim.g.loaded_remote_plugins = ""
vim.cmd([[set runtimepath=$VIMRUNTIME]])

local temp_dir = vim.loop.os_getenv("TEMP") or "/tmp"

vim.cmd("set packpath=" .. join_paths(temp_dir, "nvim", "site"))

local package_root = join_paths(temp_dir, "nvim", "site", "pack")
local install_path = join_paths(package_root, "packer", "start", "packer.nvim")
local compile_path = join_paths(install_path, "plugin", "packer_compiled.lua")

local null_ls_config = function()
  local null_ls = require("null-ls")
  local null_ls_utils = require("null-ls.utils")

  local diagnostics = null_ls.builtins.diagnostics
  -- add only what you need to reproduce your issue
  null_ls.setup({
    root_dir = null_ls_utils.root_pattern("selene.toml"),

    sources = {
      diagnostics.selene.with({
        condition = function(utils)
          return utils.root_has_file({ "selene.toml" })
        end,
      }),
    },
    debug = true,
  })
end

local function load_plugins()
  -- only add other plugins if they are necessary to reproduce the issue
  require("packer").startup({
    {
      "wbthomason/packer.nvim",
      {
        "nvimtools/none-ls.nvim",
        requires = { "nvim-lua/plenary.nvim" },
        config = null_ls_config,
      },
    },
    config = {
      package_root = package_root,
      compile_path = compile_path,
    },
  })
end

if vim.fn.isdirectory(install_path) == 0 then
  vim.fn.system({ "git", "clone", "https://github.com/wbthomason/packer.nvim", install_path })
  load_plugins()
  require("packer").sync()
else
  load_plugins()
  require("packer").sync()
end

Steps to Reproduce
In a testing enviroment (a directory for a lua project), have the following files.

Create a selene.toml file with the following config:

std="neovim"

exclude = ["*_spec.lua", ".luacheckrc"]

[rules]
global_usage = "allow"
multiple_statements = "allow"
incorrect_standard_library_use = "allow"
mixed_table = "allow"
unused_variable = "warn"

Create a neovim.yml file with the following config:

---
base: lua51

globals:
  vim:
    any: true
  assert:
    args:
      - type: bool
      - type: string
        required: false
  after_each:
    args:
      - type: function
  before_each:
    args:
      - type: function
  describe:
    args:
      - type: string
      - type: function
  it:
    args:
      - type: string
      - type: function

Create a .luacheckrc file with the following config:

-- Rerun tests only if their modification time changed.
cache = true

ignore = {
  "122", -- Setting a read-only field of a global variable.
  "212", -- Unused argument, In the case of callback function, _arg_name is easier to understand than _, so this option is set to off.
  "631", -- max_line_length, vscode pkg URL is too long
}

-- Global objects defined by the C code
read_globals = {
  "vim",
}

include_files = { "lua", "tests" }
exclude_files = { ".luacheckrc", "tests/**/*_spec.lua" }

-- vim: ft=lua tw=80

Open NeoVim using nvim --clean -u minimal_init.lua and navigate to :e .luacheckrc

Reproducibility Check

[X] I confirm that my minimal config is based on the minimal_init.lua template and that my issue is reproducible by running nvim --clean -u minimal_init.lua and following the steps above.

Expected Behavior
To not display any diagnostics from selene inside excluded files.
Actual Behavior
Displaying diagnostics from selene inside excluded files.
Debug Log
[DEBUG Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/sources.lua:82: registering conditional source selene
[TRACE Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/client.lua:114: starting null-ls client
[TRACE Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/rpc.lua:106: received LSP request for method initialize
[DEBUG Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/client.lua:182: unable to notify client for method textDocument/didOpen (client not active): {
  textDocument = {
    uri = "file:///Users/aome/dev/nvim_plugins/colorscheme-installer.nvim/.luacheckrc"
  }
}
[TRACE Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/rpc.lua:131: received LSP notification for method initialized
[TRACE Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/rpc.lua:131: received LSP notification for method textDocument/didOpen
[TRACE Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/generators.lua:21: running generators for method NULL_LS_DIAGNOSTICS_ON_OPEN
[DEBUG Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/helpers/generator_factory.lua:329: spawning command "selene" at /Users/aome/dev/nvim_plugins/colorscheme-installer.nvim with args { "--display-style", "quiet", "-" }
[TRACE Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/helpers/generator_factory.lua:207: error output: nil
[TRACE Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/helpers/generator_factory.lua:208: output: -:2:1: warning[unscoped_variables]: `cache` is not declared locally, and will be available in every scope
-:2:1: warning[unused_variable]: cache is defined, but never used
-:4:1: warning[unscoped_variables]: `ignore` is not declared locally, and will be available in every scope
-:4:1: warning[unused_variable]: ignore is defined, but never used
-:11:1: warning[unscoped_variables]: `read_globals` is not declared locally, and will be available in every scope
-:11:1: warning[unused_variable]: read_globals is defined, but never used
-:15:1: warning[unscoped_variables]: `include_files` is not declared locally, and will be available in every scope
-:15:1: warning[unused_variable]: include_files is defined, but never used
-:16:1: warning[unscoped_variables]: `exclude_files` is not declared locally, and will be available in every scope
-:16:1: warning[unused_variable]: exclude_files is defined, but never used
Results:
0 errors
10 warnings
0 parse errors

[TRACE Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/diagnostics.lua:181: received diagnostics from source 1
[TRACE Thu May  9 14:45:59 2024] /tmp/nvim/site/pack/packer/start/none-ls.nvim/lua/null-ls/diagnostics.lua:182: { {
    code = "unscoped_variables",
    col = 0,
    end_col = 5,
    end_lnum = 1,
    lnum = 1,
    message = "`cache` is not declared locally, and will be available in every scope",
    row = "2",
    severity = 2,
    source = "selene"
  }, {
    code = "unused_variable",
    col = 0,
    end_col = 5,
    end_lnum = 1,
    lnum = 1,
    message = "cache is defined, but never used",
    row = "2",
    severity = 2,
    source = "selene"
  }, {
    code = "unscoped_variables",
    col = 0,
    end_col = 6,
    end_lnum = 3,
    lnum = 3,
    message = "`ignore` is not declared locally, and will be available in every scope",
    row = "4",
    severity = 2,
    source = "selene"
  }, {
    code = "unused_variable",
    col = 0,
    end_col = 6,
    end_lnum = 3,
    lnum = 3,
    message = "ignore is defined, but never used",
    row = "4",
    severity = 2,
    source = "selene"
  }, {
    code = "unscoped_variables",
    col = 0,
    end_col = 12,
    end_lnum = 10,
    lnum = 10,
    message = "`read_globals` is not declared locally, and will be available in every scope",
    row = "11",
    severity = 2,
    source = "selene"
  }, {
    code = "unused_variable",
    col = 0,
    end_col = 12,
    end_lnum = 10,
    lnum = 10,
    message = "read_globals is defined, but never used",
    row = "11",
    severity = 2,
    source = "selene"
  }, {
    code = "unscoped_variables",
    col = 0,
    end_col = 13,
    end_lnum = 14,
    lnum = 14,
    message = "`include_files` is not declared locally, and will be available in every scope",
    row = "15",
    severity = 2,
    source = "selene"
  }, {
    code = "unused_variable",
    col = 0,
    end_col = 13,
    end_lnum = 14,
    lnum = 14,
    message = "include_files is defined, but never used",
    row = "15",
    severity = 2,
    source = "selene"
  }, {
    code = "unscoped_variables",
    col = 0,
    end_col = 13,
    end_lnum = 15,
    lnum = 15,
    message = "`exclude_files` is not declared locally, and will be available in every scope",
    row = "16",
    severity = 2,
    source = "selene"
  }, {
    code = "unused_variable",
    col = 0,
    end_col = 13,
    end_lnum = 15,
    lnum = 15,
    message = "exclude_files is defined, but never used",
    row = "16",
    severity = 2,
    source = "selene"
  } }

Help
No
Implementation Help
No response
Requirements

[X] I have read and followed the instructions above and understand that my issue will be closed if I did not provide the required information.

@AlejandroSuero This issue has nothing to do with none-ls. You are not using selene exclude correctly (refer to the docs). Also Mixing two linters is by general rule a bad idea.

@Zeioth according to the documentation, in the excluding files section this is how it is supposed to work.
I'm not planning on mixing them (in the minimal I only use one), I am trying to support selene linting for people that don't use luacheck inside a project but want to have the linting diagnostics and have selene already installed, thats all.

Project tree:
 .git/
 .github/
 .gitignore
 .luacheckrc
 .luarc.json
 .markdownlint.json
 .yamllint.yml
 colorscheme-installer-scm-1.rockspec
 contrib/
 doc/
 LICENSE
 lua/
 luacov.stats.out
 Makefile
 neovim.yml
 README.md
 scripts/
 selene.toml
 stylua.toml
 tests/

selene . and selene .luacheckrc excluding the files from command-line:

selene --no-exclude .luacheckrc not excluding the files from command-line:

Diagnostics using none-ls not excluding the files:

With my own config

With the minimal config

@AlejandroSuero I'm looking at this now. In the future, please make your issue replications way more concise.
All you have to do is create any file, ignore it in the selene.toml, and see selene erroneously add diagnostics. We don't need a billion screenshots xd
Anyways, this is peculiar. Thanks for the report!

https://github.com/kmhofmann/selene/issues/15
Asked here- will wait for the response


Improve performance on small reductions by doing multiple reduction per wavefront

Add subwave functions to get indices per the subdivided wavefront.
Add a subwave<> algorithm for reductions
Update dpp_reduce to do partial reduce for smaller sizes
Update compute_block to account for different wavefront sizes across different hardware
Update find_div_const to skip for integrals since this can lead to incorrect results(is x/y is not the same as x*(1/y) when using integers). This was causing some of the newer test cases to fail, which is why its included in this PR.

Locally testing this, I see a 2x perf boost on small reduction sizes.

Codecov Report
Attention: 22 lines in your changes are missing coverage. Please review.

:exclamation: No coverage uploaded for pull request base (develop@fe61d94). Click here to learn what that means.
 Consider uploading reports for the commit 63330bf to get more accurate results

Files
Patch %
Lines

src/quantization.cpp
51.85%
13 Missing :warning:

src/onnx/parse_qlinearconcat.cpp
83.33%
5 Missing :warning:

src/include/migraphx/op/quant_dot.hpp
80.00%
1 Missing :warning:

src/onnx/parse_dynamicquantizelinear.cpp
96.00%
1 Missing :warning:

src/quantize_8bits.cpp
88.88%
1 Missing :warning:

src/simplify_reshapes.cpp
50.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             develop    #2547   +/-   ##
==========================================
  Coverage           ?   91.42%
==========================================
  Files              ?      454
  Lines              ?    17208
  Branches           ?        0
==========================================
  Hits               ?    15732
  Misses             ?     1476
  Partials           ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Tests and formatting are failing

@pfultz2  format issue


Cannot run react application using vscode with ssh remote plugin to WSL.

When I use ssh remote plugin to connect tot WSL on windows, React APP cannot be started through vscode built-in terminal.

Why do you use SSH to a WSL instance? How is that set up?
Can't you use the regular Remote - WSL extension?


Bump knative to enable new features

Changes
This PR is related to https://github.com/tektoncd/pipeline/pull/3156 and splits out the knative version bump from that PR. Knative has some internal changes that we would like to take advantage of like the ability to configure the QPS it accepts which necessitates this version bump.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[x] Includes tests (if functionality changed/added)
[x] Includes docs (if user facing)
[x] Commit messages follow commit message best practices
[x] Release notes block has been filled in or deleted (only if no user facing changes)

Release Notes
knative is upgraded to a more recent version

/kind feature

/ok-to-test

/assign bobcatfish

thanks for taking this on @pierretasci !!

/lgtm
Seems fairly straightforward.
cc @mattmoor

As a heads up, we switched to K8s 1.18 libs last week for our upcoming 0.18 release.  This is notable because K8s made breaking changes to the client-go APIs.  When y'all are ready to pick that up, feel free to ping me and I can help support, but that's largely orthogonal to this.
Glad this seemed so easy 🤩  😅

/test pull-tekton-pipeline-build-tests


pipewire_0_2: add -fcommon workaround

Without the change build fails as:
$ nix build --impure --expr 'with import ./. {}; pipewire_0_2.override { stdenv = clang12Stdenv; }' -L
...
ld: spa/plugins/bluez5/libspa-bluez5.so.p/bluez5-monitor.c.o:(.bss+0x0):
  multiple definition of `spa_a2dp_sink_factory'

Newer versions don't require the fix as upstream removed the code completely later.

Motivation for this change
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.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/767

Before we merge this: Does qtwebengine and qutebrowser still require pipewire 0.2? If not we could just drop it entirely.

I spent some time trying to do s/pipewire_0_2/pipewire/ for qtwebengine and failed.
qtwebengine encodes explicit pipewire version in a few places:

in build system: src/3rdparty/chromium/third_party/weston/src/pipewire/meson.build:            'libpipewire-0.2', 'libspa-0.1'
In a dynamic loader: src/3rdparty/chromium/third_party/webrtc/modules/desktop_capture/linux/base_capturer_pipewire.cc:const char kPipeWireLib[] = "libpipewire-0.2.so.1";

[1.] Is probably easy to worlaround. [2.] is a bit worrying as the plugin extracts exported symbols and I did not follow closely if API changes are important.
As a result the build fails when using new pipewire-0.3 as is:
qtwebengine> ../../3rdparty/chromium/third_party/webrtc/modules/desktop_capture/linux/base_capturer_pipewire.h:16:10: fatal error: pipewire/pipewire.h: No such file or directory
qtwebengine>    16 | #include <pipewire/pipewire.h>
qtwebengine>       |          ^~~~~~~~~~~~~~~~~~~~~
qtwebengine> compilation terminated.

AFAIU the closest upstream report related to pipewire-0.3 is: https://bugreports.qt.io/browse/QTBUG-101505.

bummer but we should try to get rid of it when it is possible


port cron_d resource to core

Port the cron_d resource to core. It's similar to our existing cron resource, but heavily requested by users.

Dupe of #7253


Fix 404 links

FIX #5743
FYI @kenchris

Whoops!
There were 4 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2016/03/web-enabled-internet-of-things.md#L147 - Line must be at most 100 characters
src/content/en/updates/2016/03/web-enabled-internet-of-things.md#L148 - Line must be at most 100 characters
src/content/en/updates/2016/03/web-enabled-internet-of-things.md#L424 - Line must be at most 100 characters
src/content/en/updates/2016/03/web-enabled-internet-of-things.md#L425 - Line must be at most 100 characters

lgtm

:tada: This has been pushed live to https://developers.google.com/web/


customSlots instead of AMAZON.LITERAL

Since AMAZON.LITERAL is not supported in Germany and also deprecated you should switch to customSlots and provide customSlot entries instead default values in utterances.

that's not possible, 'cause there's no way you'd know every possible thing people'd ask the mirror to find. I guess no support for Germany then.

But if using it only for module show/hide this function would work in german english and module names can be managed and handled by custom slots?


The /v: switch for verbose status messages into a log file gives an error as written.

The command for /v: switch above will give an error unless the .log extension is removed.
The article has the switch as "/V:"c:\Users\Admin\Desktop\Uploadlog.log""
It should be "/V:"c:\Users\Admin\Desktop\Uploadlog"

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

ID: d4271558-62a9-db3c-078c-13b5e5fe99da
Version Independent ID: 813d7002-20a2-b1be-2771-975a0b1cfd48
Content: Use network upload to import your organization's PST files - Microsoft 365 Compliance
Content Source: microsoft-365/compliance/use-network-upload-to-import-pst-files.md
Service: o365-seccomp
GitHub Login: @markjjo
Microsoft Alias: markjjo

@shawntr Thanks for the info. What is the error if you include the .log extension?


UserWarning: Setting the 'color' property will override the edgecolor or facecolor properties

Every time I plot a polygon with a specifying the global color I get this warning

[......]/starplot/base.py:491: UserWarning: Setting the 'color' property will override the edgecolor or facecolor properties.
patch = patches.Polygon(

When plotting many circles or ellipses this floods quickly the stderr output and can be quite annoying.
Personally I don't thing this warning is needed as this behaviour is clearly explained in the documentation:
https://starplot.dev/reference-styling/#starplot.styles.PolygonStyle
Another solution might be applying a configurable warning filter to plot classes or even logging.

hahaha, I was thinking the same thing. There's an undocumented debug param to plot constructors that I use to log info when debugging, so I was thinking of enabling all warnings when that's set to True -- maybe it's worth a separate parameter though, e.g. suppress_warnings (default would be True)


unknown variant dockarea`` error when running server

Hi,
When I run cargo run --release server from the project root in the latest master version, I get the following:
❯ cargo run --release server
    Finished release [optimized] target(s) in 0.01s
     Running `target/release/i3-focus-last server`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("unknown variant `dockarea`, expected one of `root`, `output`, `workspace`, `con`, `floating_con`", line: 1, column: 13502)', src/main.rs:110:36
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

That seems to be a bug with swayipc-rs which is missing some parts of the api.


Office 365 onedrive api generate share link error.

Hello,
Could someone explain to me where im wrong? I try to generate a share link via microsoft api but i get this :
{   "error": {     "code": "itemNotFound",     "message": "The resource could not be found.",     "innerError": {       "date": "2020-06-17T18:08:09",       "request-id": "06fe190c-fa09-4544-8a6f-a2921de2941e"     }   } }
The code which i use
curl.exe https://graph.microsoft.com/v1.0/me/drive/root:/test.txt:/createLink -X POST -d '{"type": "view"}' -H "Authorization: bearer myapikey"

Im using a student account on office 365
Edit: English is not my native language sorry for grammar mistakes.

Thanks for your feedback. The error suggests that the file test.txt does not exist in the root folder of the current user's drive.
If you perform GET on https://graph.microsoft.com/v1.0/me/drive/root:/test.txt:/, does that work?


mgmt/mcumgr/grp/img: Cherry-pick MCUboot direct XIP support

Cherry-pick MCUboot direct XIP support.

Note that MCUmgr MCUboot info may significantly change.

What do you mean @de-nordic? Do you think we should desist from cherry-picking it at this point?
@philips77 please confirm if you want to test with the MCUmgr MCUboot info in the current version.

Note that MCUmgr MCUboot info may significantly change.

What do you mean @de-nordic? Do you think we should desist from cherry-picking it at this point? @philips77 please confirm if you want to test with the MCUmgr MCUboot info in the current version.

@nordicjm  Do you agree with the proposed command specification as done in https://github.com/zephyrproject-rtos/zephyr/pull/57797/files?

Note that MCUmgr MCUboot info may significantly change.

What do you mean @de-nordic? Do you think we should desist from cherry-picking it at this point? @philips77 please confirm if you want to test with the MCUmgr MCUboot info in the current version.

@nordicjm Do you agree with the proposed command specification as done in https://github.com/zephyrproject-rtos/zephyr/pull/57797/files?

Yes, at present it has the code in the file to do it but in future I suggest we replace it and just use it to directly query the blinfo group of settings once someone stops moaning over https://github.com/zephyrproject-rtos/zephyr/pull/59025

please confirm if you want to test with the MCUmgr MCUboot info in the current version.

It depends on what is inside the info and how is it will be released. If you plan to release these features separately, so d-xip goes in 2.5, but info later, than I need to test d-xip only and together with info later. Or if they can be enabled separately, so one does not depend on the other.

This PR should be closed as the support for Direct-XIP in this PR  is outdated. The support will come as nrf fromtree commits from a different PR set.


fix(autoware_tensorrt_yolox): fix unreadVariable

Description
This is a fix based on cppcheck unreadVariable warnings.
perception/autoware_tensorrt_yolox/src/tensorrt_yolox.cpp:189:27: style: Variable 'calibName' is assigned a value that is never used. [unreadVariable]
    std::string calibName = "";
                          ^

Related links
Parent Issue:

Link

How was this PR tested?
Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

Currently the warning is suppressed with a comment, but if the variable is not going to be used in the future, it can be removed.

This variable was removed because it was clearly not being used.


Review handling account name on hover card

Seems we've got bug on nft item detail and whenever we are using hover card and throws 400 on magick endpoint

on it!


GEODE-4606: Add an example that demonstrates continuous queries.

Add an example that demonstrates continuous queries.

Closing and will reopen with latest build changes.


microchip: mec: zephyr spi image generation

Added mchp mec zephyr image generator python script. It takes zephyr.bin as input and produces zephyr.mchp.bin.
The default behavior is to not pad to SPI flash size.
(Enable through CONFIG_MCHP_MEC_HEADER=y and CONFIG_MCHP_MEC_HEADER_FLASH_SIZE_256K=y)
zephyr.mchp.bin is composed of:

First 4KB contains TAG at offset 0 and header at offset 0x100
Offset 0x1000 is the start of zephyr.bin which has been padded to a multiple of 128 bytes.
Boot-ROM EC Info Block (128 bytes)
Boot-ROM Co-Signature Block (96 bytes)
Boot-ROM trailer (160 bytes) contains the SHA-384 digest of 2-4.

Signed-off-by: Jay Vasanth<EMAIL_ADDRESS>

Please look at hooking this functionality into west sign

Please look at hooking this functionality into west sign

This feature is required only for google chrome build.

@jvasanth1 I assume overall this is orthogonal to using /usr/local/bin/everglades_spi_gen_RomE  whenever west build is run for mec172x board, correct?

@jvasanth1 I assume overall this is orthogonal to using /usr/local/bin/everglades_spi_gen_RomE whenever west build is run for mec172x board, correct?

Yes, it runs separately taking zephyr.bin as input.

@fabiobaltieri fixed the review comments, could you help to approve?

@fabiobaltieri could you approve this PR?

@fabiobaltieri can you help to approve? Thanks

Sorry I'm out on holiday, @jackrosenthal would you have time to take a look? I'll be back next week otherwise.

@keith-zephyr can you help to approve?


Fix flaky test.

Maps are randomly reordered.
But there is only one order for one thing.
Fixes #3378

Thanks for the quick fix.

LGTM


gestaltv7 compability for NUI 2.0

Contains

some changes cherry picked from v1.0.0 ( Colorc, RectUtitlity#map)
For Terasology engine compability
moving package from org.terasology.input to org,terasology.nui.input
Cleaning org.terasology package
Compability for  gestaltv7's package module
moving package from org.terasology.reflection to org.terasology.nui.reflection
Cleaning org.terasology package
Compability for  gestaltv7's package module

This is from September's gestalt-v7 proposal. I expect it's still relevant, is it still mostly up-to-date?

This is from September's gestalt-v7 proposal. I expect it's still relevant, is it still mostly up-to-date?

I'd hope @DarkWeird can answer that?

This is from September's gestalt-v7 proposal. I expect it's still relevant, is it still mostly up-to-date?

I'd hope @DarkWeird can answer that?

@keturn
Yeah. It is up to date.
Needs another engine's pr for update imports.
(Together with gestaltv7 pr)

Is this porting over everything that is needed, or only some partial list?
For reference, this is how the two branches are diverging...
* 6a27464 feat(flexibleconfig): UI for editing arbitrary types and AutoConfigs (#36)
* 4488cf0 chore: prepare snapshot builds for 1.5.0
* 25ba115 (tag: v1.4.0) release: version 1.4.0
* bac6a5a chore: use newly released joml-ext v0.1.0 (#40)
* 0b65cf1 chore: trigger build with new joml-ext SNAPSHOT
* 5429dad feat(JOML): migrate joml to 1.10.0 and 1.0.0-SNAPSHOT for geometry (#39)
* 5762bbd chore: prepare next snapshot for 1.4.0
* 4b9733d (tag: v1.3.1) release: version 1.3.1
* ee8af75 fix: moving while typing in console or chat (TS) (#35)
* 8fa207a chore: prepare next snapshot for 1.4.0
* 55f074e (tag: v1.3.0) release: version 1.3.0
*   7f66723 Merge pull request #24 from MovingBlocks/topic/lwjgl3
|\
| *   356aae2 Merge pull request #32 from MovingBlocks/topic/lwjgl3-compile-errors
| |\
| | * a1034de correct compile errors for LibGDXKeyboard
| |/
| *   21a2d82 Merge branch 'release/v1.x' into topic/lwjgl3
| |\
| |/
|/|
* | 82556b6 feat: add new prop "overrideChildEnabledProp" to AbstractWidget (#29)
* | 8bfd1db fiy(miglayout): `setRowConstraints` uses col constraints (#25)
| * 22e7b69 chore(lwjgl3): Fix nui versioning.
| * ab32b35 Bump up version
| * e410156 feat(lwjgl3): split keyboard input to raw input and text input. Returns MouseDevice#getPosition
|/
* 0642317 chore: version bump
* 41b80fe release: version 1.2.0
* be9da9d fix: restore type parity from when NUI was in the Terasology engine (int then, byte now)
* 86aa22f fix Color(float,float,float,float) (#21)
* c797577 chore: bump next version scope to minor, tiny Gradle cleanup
* 03abcde tweaked canvas render
* 0b33510 remove new Color for operations
* 81c157a update imports
* 250a0e3 add rectangle test
* 596f6ad feature add map to RectUtility and readonly color
* 5eabc56 chore: prepare next snapshot for 1.1.1
* 4c9ea44 release: version 1.1.0
* 2445166 add missing clamp to Color#set*
* 85128bb test: test both set and alter methods for Color
* 2e6026a test: Add FontColorTest (from MovingBlocks/Terasology)
* 7be7f4c test: Add more ColorTests (from MovingBlocks/Terasology)
* 27fce2d test: Add LineTest (from MovingBlocks/Terasology)
* 58f4f67 fix: Explicitly compute rect from min and size in Line
* 47a3874 test: Add BorderTest; remove JOML conversions, fix assertions
* 77fc889 docs: Add JavaDoc for `createFromMinAndMax`
* 35b38ab fix: `createFromMinAndSize` clamps and validates result
* 9c88213 chore: Add math utility `addClampAtMax` for float
* 6abc996 feat: deep copy of EntityRef.copy (MovingBlocks/Terasology#4099)
* 24902bc chore: add info how to get TeraNUI for local testting
* 179c810 chore: prepare next snapshot for 1.1.0-SNAPSHOT
* b4c243a (tag: v1.0.0) release: version 1.0.0
| * 7e9c5d5 (origin/master, master) fiy(miglayout): `setRowConstraints` uses col constraints (#26)
| * e1f7918 docs: Add JavaDoc for `createFromMinAndMax`
| * a4a74e3 fix: `createFromMinAndSize` clamps and validates result
| * b228db2 chore: Add math utility `addClampAtMax` for float
| * 40b4a18 chore: add info how to get TeraNUI for local testting
| * 456edae chore: prepare next snapshot for 2.1.0-SNAPSHOT
| * 4f78131 (tag: v2.0.0) release: version 2.0.0
| * 926d327 Updated NUI to use gestalt 7 (#4)
|/
* 2af3a7d chore: prepare multi releases (#11)

which two branches diverged? this vs the v2.0 branch, or the https://github.com/MovingBlocks/TeraNUI/commits/release/v1.x branch?

Now that #47 is merged as v3, where does that leave this?
Here you said:

I think use BSA's PR firsts, then provide support in nui-gestaltv7 module is better then synthetic module

Now that #47 is merged as v3, where does that leave this?
Here you said:

I think use BSA's PR firsts, then provide support in nui-gestaltv7 module is better then synthetic module

Next steps:

Close no related PR at TeraNUI(bug fixes from v1 to v2)
Rebase  related prs.
Integrate nui v3 to terasology (develop)
Switch nui-gestalt at gestaltv7 pr.

(Or skip 3)
Profits:

No repeating bugfixes
Switch should be easier
NuiV3 not syntetic module at TS and DestSol

Obsolete after https://github.com/MovingBlocks/TeraNUI/pull/47


Is there a way to report coverage for non-stories files?

Hi! I've successfully managed to eject my configuration and configured test-runner to execute my normal *.test.ts files. It works as expected, but these custom test files do not show up in coverage reports. Am I missing something?
// .storybook/main.cjs

module.exports = {
	async viteFinal(config) {
		return {
			...config,
			resolve: {
				...config.resolve,
				alias: {
					...config.resolve.alias,
					"~": "/src",
				},
			},
		};
	},
	stories: ["../src/**/*.stories.mdx", "../src/**/*.stories.@(js|jsx|ts|tsx)"],
	addons: [
		"@storybook/addon-links",
		"@storybook/addon-essentials",
		"@storybook/addon-interactions",
		"@storybook/addon-a11y",
		{
			name: "@storybook/addon-coverage",
		},
		"storybook-addon-themes",
		"storybook-addon-react-router-v6",
	],
	framework: "@storybook/react",
	core: {
		builder: "@storybook/builder-vite",
	},
	features: {
		storyStoreV7: true,
		interactionsDebugger: true, // 👈 Enable playback controls
	},
};

// test-runner-jest.config.js

import { getJestConfig } from "@storybook/test-runner";

const config = getJestConfig();

/**
 * @type {import('@jest/types').Config.InitialOptions}
 */
export default {
	// The default configuration comes from @storybook/test-runner
	...config,
	/** Add your own overrides below
	 * @see https://jestjs.io/docs/configuration
	 */
	transform: {
		"^.+\\.scss$": "jest-scss-transform",
		...config.transform,
	},
	modulePaths: ["src", "node_modules"],
	moduleNameMapper: {
		"\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$":
			"<rootDir>/__mocks__/fileMock.js",
	},
	// reporters: ["jest-silent-reporter"],
	testMatch: ["**/*.test.ts", ...config.testMatch],
	setupFiles: ["./setupJest.js"],
	snapshotResolver: "./snapshot-resolver.cjs",
	collectCoverageFrom: ["src/**/*.ts"],
};

I get the following output when running npx test-storybook --coverage:
npx test-storybook --coverage

 PASS   browser: chromium  src/core/utils/network.test.ts
 PASS   browser: chromium  src/core/components/sample-component/sample-component.stories.tsx (5.059 s)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   1 passed, 1 total
Time:        7.172 s
Ran all test suites.
Coverage file (1971 bytes) written to .nyc_output\coverage.json
----------------------|---------|----------|---------|---------|-------------------
File                  | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------------------|---------|----------|---------|---------|-------------------
All files             |     100 |      100 |     100 |     100 |
 sample-component.tsx |     100 |      100 |     100 |     100 |
----------------------|---------|----------|---------|---------|-------------------

Hi, Nabil! @storybook/test-runner is only ever intended to test (and therefore, provide coverage for) Storybook stories.
However, you can combine coverage from the test runner and other tools. You can find guidance in the test runner README: https://github.com/storybookjs/test-runner#3---merging-code-coverage-with-coverage-from-other-tools
If you wish to run all tests with a single command, you could set up your package scripts something like this:
"scripts": {
  "test": "jest",
  "test-storybook": "test-storybook",
  "test:all": "yarn test && yarn test-storybook"
}

The guidance linked above includes an example for doing something similar for generating coverage reports.

Hey @kylegach , this doesn't solve the problem of having Jest report all my snapshots as obsolete. Is there a way around this?

@KL13NT @yannbf Yes, I merged them like this!
https://github.com/kasperpeulen/storybook-remix/blob/main/jest-storybook.config.ts


Content Not properly visible in pet news tab page

Hi @akshitagupta15june I am Naman Jain a GSSOC'24 contributor
Recently I visited your website and noticed that at the bottom of the page the content is not clearly visible as the color of the content as the color of the text is not changed in the code so i would like to change the color of the text there so that it is clearly visible to the users.
Please assign this task to me and please label it with gssoc level 1 issue.
looking forward for your reply
thank u

I would love to work on this issue, can you please assign this to me

I would love to work on this issue as I have the required skill set to fix this bug, can you please assign this to me


[BUG] Cannot perform runtime binding on a null reference

The following error gets logged for some users, preventing them from applying all of their customizations.
Reinstalling the editor seems to be fix the issue but should still investigate.
2024-07-14 00:06:41,863 | INFO | Set "font" to "0".
2024-07-14 00:06:41,865 | ERROR | Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: Cannot perform runtime binding on a null reference
   at CallSite.Target(Closure, CallSite, Object)
   at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
   at HUDEditor.Classes.Utilities.Merge(Dictionary2 object1, Dictionary2 object2) in C:\Users\nik_1\OneDrive\Documents\GitHub\TF2HUD.Editor\src\TF2HUD.Editor\Classes\Utilities.cs:line 292
2024-07-14 00:06:41,887 | ERROR | Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: Cannot perform runtime binding on a null reference
   at CallSite.Target(Closure, CallSite, Object)
   at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
   at HUDEditor.Classes.Utilities.Merge(Dictionary2 object1, Dictionary2 object2) in C:\Users\nik_1\OneDrive\Documents\GitHub\TF2HUD.Editor\src\TF2HUD.Editor\Classes\Utilities.cs:line 292
   at HUDEditor.Classes.Utilities.Merge(Dictionary2 object1, Dictionary2 object2) in C:\Users\nik_1\OneDrive\Documents\GitHub\TF2HUD.Editor\src\TF2HUD.Editor\Classes\Utilities.cs:line 295
2024-07-14 00:06:41,887 | ERROR | Cannot perform runtime binding on a null reference
2024-07-14 00:06:41,887 | INFO | Applying: fh_centered_item_meters

Upon further investigation this may be related to stale AppData content that refers to customizations that are no longer exist. A robust clear cache option needs to be implemented to avoid these issues in the future see #

This may have been resolved in 3.3 RC1 release - monitoring for users feedback.

Fixed in the 3.3 release


stop requesting x64 for mac to work on arm

I had issues with PyQt6 (for the documentation build with sphinx for unknown reasons), so I went back to PyQt5, but without specifying the exact version 5.15.6 that we pinned before. This older version is not available on all runners. I do not know why that version was explicitly requested.


problem with mark position of checkbox in android L

hi. CheckBox work fine in some android L but in LG G3 i got a wrong position for Checkmark.

The problem is in the below code

Rect src = new Rect(40 * step, 0, (40 * step) + 40, 40);

Rect dst = new Rect(0, 0, this.getWidth() - 2, this.getHeight());

wrong size and wrong position.
how can i solve this?

Same here. Need help ;)

no solution???????

This library uses drawable to provide this type of checkBox. This problem happens because the resolution of G3 is too big and the file at resource can't handle this resolution.

I had the same problem in a LG G4. Simple workaround (not the best temporary helps):
int slice = sprite.getWidth() / 12;
int height = sprite.getHeight();
Rect src = new Rect(slice * step, 0, (slice * step) + slice, height);
Rect dst = new Rect(0, 0, this.getWidth() - 2, this.getHeight());


update?

this is actually really good and I'm willing to pay for it

pay for what? What kind of update do you want? there is nothing good or unique about it :rofl:

pay for what? What kind of update do you want? there is nothing good or unique about it 🤣

well I'm using iniuria and when I try to use NezuLoader.dll it freezes csgo 90% of the time. but when it works, it's amazing. the features are pretty good so yeah

like after i inject iniuria with it's client and then inject nezu with csghost the menu for nezu stays open and pressing the 'home' key doesn't hide it. and the game freezes when I inject nezu first

ok, so you're asking to add compatibility with iniuria? If you buy me an iniuria sub and maybe a little extra I can probably add that. add me on discord nezu.cc if you're interested


line thickness

hi, how to set line in chart  thickness??
i can not find any option!!!
pls help me.

hollow: {
margin: 15,
size: '40%'
},
Adjust this with size


feat(doc): update csharp support for @flattenProperty

A follow-up of #633 and #635

No changes needing a change description found.

You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/807/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/807/


支持esm build

package.json 增加module字段用于支持esm构建
antd构建后使用的是es
alist使用 antd/lib
导致配置不能共享

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


EVA/ClinVar - include other clinical significant variant

Include other clinical significance variants: we’will score them as 0 but present the information

There is no action in our side, EVA need to add this to their pipeline. I'll make sure that Kirill has a ticket for this.

Better said, the action on our side is to adapt the JSON schema so that it accepts all the clinical significance values used by ClinVar. The ones currently accepted are below:
"clinical_significance": {
                  "type": "string",
                  "enum": [
                    "Pathogenic",
                    "Likely pathogenic",
                    "protective",
                    "association",
                    "risk_factor",
                    "Affects",
                    "drug response"
                  ]
                }

Extracted from the JSON schema.

This table in the ClinVar documentation suggests that the list above may be incomplete:

Kirill has agreed to report all variants (work can be tracked on EBIvariation/eva-opentargets#122 and he will provide a list of the possible clinical significance values soon.

@DSuveges @AsierGonzalez (also copying @tcezard @d0choa @iandunham)
Here is the distribution of all possible clinical significance levels in ClinVar:

Under the current criteria, only 188,518 out of 1,114,689 (17%) records contain clinical significance levels which are processed by our pipeline. The ones which are not processed fall into two categories:

Simple, where only one value is associated with a given record;
Complex, where there are multiple values, separated using , or /.

To start processing the types which are currently not processed, we need to do several things:

The new types must be supported by the Open Targets JSON schema, as mentioned by Asier in the comment above.
Specifically, we need to sort out the issue with spellings. I'm not certain about it, but it looks like we're currently not processing two types simply because they are spelled differently between ClinVar, our pipeline, and the JSON schema: risk_factor / risk factor and affects/Affects. To resolve this, I suggest specifying all values in the JSON schema in lowercase and using spaces, e.g.: risk factor, affects, likely pathogenic, etc. Where ClinVar spells them differently, we'll handle the conversion in our pipeline.
To include the new clinical significance levels, we need to know which activity identifiers to map them to. For example, currently likely pathogenic is mapped to http://identifiers.org/cttv.activity/predicted_damaging. We need to have such mappings for all clinical significance types.
It's unclear what to do with types which are either non-specific (not provided; Conflicting interpretations of pathogenicity; other) or combine multiple values (Pathogenic, Affects; Benign/Likely benign).

Please let me know how you would like to proceed here.

Thank you very much for doing all these extensive comparisons @tskir! It's really helpful in making the decisions. Let me go through all the points you have raised.

Yes, to accommodate the decisions here and on other tickets #1137, #1140 we'll need to update the json schema.
Your suggestion regarding the spelling of the clinical significance terms is good: let's use only lowercase terms with spaces instead underscores.
It seems we don't really use the .target.activity value anywhere so just omit that. We'll make that value in the json schema optional.
To accommodate multiple clinical significance values, we'll change the json schema to handle list instead of a string like:

"clinical_significance": [
   "pathogenic",
   "risk factor"
],

@DSuveges (copying @tcezard)
I agree with all the points you raised. I will proceed to implement the changes on our side in an experimental branch.

@DSuveges I'm currently working on this issue and I have a follow-up question about the ['evidence']['gene2variant']['is_associated'] and ['evidence']['variant2disease']['is_associated'] attributes. In the existing approach, we always set them to True, because only (likely) pathogenic and other related variants are processed. Should I continue to always set them both to True, even for variants which are benign etc.?

Or rather, to be precise, there is currently a calculation of both of those attributes which looks like this:
self.association = clinvar_record.clinical_significance not in ('likely benign', 'benign')

However, under the current approach, it always sets them both to True since "benign" and "likely benign" variants are being filtered out even before going into the evidence string generation phase.
Should I keep the calculation in exactly this way? Should I add more clinical significance levels which should not be considered an "association"? Or should I just always set them to True regardless?

Hi Kiril,
We have discussed this question with the team. There's a bit of history behind this value: it supposed to distinguish between positive and negative evidence hence the true/false binary. In this interpretation, this value should remain to be set true even for benign and likely benign evidences.
Thank you so much and please just ask if you have any other questions.

@AsierGonzalez @DSuveges This is done, currently undergoing our internal review. Changes are described in depth in our PR https://github.com/EBIvariation/eva-opentargets/pull/146. Summary:

Remove all filtering by clinical significance
Process and format the clinical significance levels: 'Benign/Likely benign, risk_factor' → ['benign', 'likely benign', 'risk factor']
Always set the evidence.gene2variant.is_associated and evidence.variant2disease.is_associated fields to True
Get rid of the the obsolete target.activity attribute
Adjust the schema: https://github.com/opentargets/json_schema/pull/95

I also ran the evidence string comparison protocol, and, as expected, their number rose significantly: from 116023 (batch 2020-09, standard pipeline) to 499174 (batch 2020-09, updated pipeline), an increase of 4.3×

That sounds fantastic, thanks @tskir

Since there were no corrections raised for this issue, and since it already supports both types of evidence strings, it's been reviewed and merged on our side. To be compatible with the JSON schema, it will require opentargets/json_schema#95 to be merged by the time of the next release.

PR has been merged

The test file provided by @tskir on 28/09/20 contained all clinical significance levels so the same is expected for the final 20.11 file. @DSuveges is now working on the new scoring (#1138)

These are the clinical significance counts in the 20.11 submission (based on ClinVar 2020/08):

Clinical significance array
Counts

["uncertain significance"]
413,652

["likely benign"]
126,194

["pathogenic"]
103,961

["benign"]
84,477

["likely pathogenic"]
41,726

["not provided"]
8,864

["conflicting interpretations of pathogenicity"]
8,240

["benign","likely benign"]
3,445

["likely pathogenic","pathogenic"]
3,004

["other"]
2,098

["risk factor"]
481

["drug response"]
197

["association"]
170

["affects"]
133

["protective"]
29

["pathogenic","risk factor"]
11

["benign","other"]
8

["risk factor","uncertain significance"]
6

["drug response","pathogenic"]
6

["affects","pathogenic"]
4

["conflicting interpretations of pathogenicity","risk factor"]
3

["benign","likely benign","other"]
3

["association not found"]
3

["other","uncertain significance"]
2

["likely pathogenic","risk factor"]
2

["likely benign","risk factor"]
2

["likely benign","other"]
2

["benign","risk factor"]
2

["association","pathogenic"]
2

["likely pathogenic","pathogenic","risk factor"]
1

["likely pathogenic","other","pathogenic"]
1

["affects","likely pathogenic"]
1


net/udp: Fix the bug of overwriting when the udp recv buffer is full

Summary
Impact
Testing

Please include the Summary and the commit message explaining the issue


Calling Reset with data remaining to be read hangs

Not sure if you guys are still maintaining this pkg (libchan seems on hold/dead).
In any case, calling Reset with data remaining to be read hangs. This PR introduces a test that shows the issue, and a (pretty crappy) workaround. See commit msg:
This commit introduces a `shutdownChan` to Streams
that works around the bug described below. I opted
for this approach because `closeChan` is ambiguous
(i believe it means the remote side closed, but not
sure), and the logic of Stream's sync is hard
to follow/modify (i suggest moving to a world
where everything calls one of three close functions
closeOutgoing, closeIncoming, closeBoth).

Reset-with-data-remaining Bug: if a client calls
Reset() on a stream with data remaining to be read,
a goroutine's stuck in `stream.dataChan <- frame.Data`
and also holds `stream.dataLock`, which means caller
of Reset will hang forever on s.dataLock.Lock().
Try running "TestStreamResetWithDataRemaining" in
the previous commit. This commit fixes the deadlock.

Note: my inspection also revealed several race
conditions, in particular when reading many variables
which are protected by locks only sometimes. For
example: (s *Stream).IsFinished() does not lock
s.finishLock.

Thanks for the contribution. This library is indeed being maintained still, just has received less attention because of some of the libchan use cases are still being developed (targeted for plugins).  If/When libchan moves over to the HTTP/2.0 spec, this library may no longer be maintained, but until then I appreciate the attention. As for the contribution guidelines, I would only ask that you add a sign line to the commits.
The code looks good, I am going to spend some more time investigating the deadlock in relation to the close chan, then should be able to get an LGTM when the sign-off is added.

I think the original closeChan logic was wrong to tie it the dataChan closer. There does not seem to be a reason to check closeChan after finish is set, meaning closeChan should just be able to  be closed.  This would allow the data frame handler to just rely on closeChan and not require an additional shutdown chan, which seems to have the same purpose.
Take a look at https://github.com/dmcgowan/spdystream/commit/8239520e2d16d25a398eab5eca5fe8157347c55f to see what I am talking about, it passes your tests.

The problem here was fixed by the alternate implementation in #41


Fix Chrome svg rendering

Currently nothing renders in chrome. Instead everything should render.

Magically fixed by elm 0.19.0 upgrade


Avoid putting remote objects in the store

When getState is called from the renderer, what it's actually doing is creating an object in the main process. When we iterate that object for cloneDeep, each property look-up translates to an ipc.sendSync (this is similar to the situation in https://github.com/electron/electron/issues/3856). We can avoid this whole rigmarole if we just use a primitive type, so instead, we'll stringify it.
This does add the requirement that everything you put in the store must be serializable (reasonable IMO). If you stored something like an Error or a RegExp this would break down.

Lgtm!

Though I'm not sure about the "everything you put in the store must be serializable", as theres currently actually an issue regarding that https://github.com/samiskin/redux-electron-store/issues/32

I'm not sure if there's a way around that though, and I think thats currently a problem anyway

@samiskin yeah I'm OK with it as it doesn't regress existing behavior, just makes it more explicit.


fix: misleading number on stats page

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR type

[x] Bugfix
[ ] Feature
[ ] Refactoring

What's new?

[x] PR closes #3643
[ ] Requires deployment <rubick/magick_issue>
[ ] <brief_description_of_what_I've_added>

Before submitting Pull Request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[x] I've posted a screenshot of demonstrated change in this PR

Optional

[ ] I've tested it at </rmrk/collection/26902bc2f7c20c546a-1FVG7>
[ ] I've tested PR on mobile and everything seems works
[ ] I found edge cases
[ ] I've written some unit tests 🧪

Had issue bounty label?

[x] Fill up your KSM address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot

[x] My fix has changed something on UI; a screenshot is best to understand changes for others.

BSX:

RMRK:

pay 50 usd

😍 Perfect, I’ve sent the payout
💵 $50 @ 61.85 USD/KSM ~ 0.808 $KSM
🧗 Caiv9TbPz68q5dC8EcHu5xKYPRnremimGzqmEejDFNpWWLG
🔗 0xe4cdfe6b299aafd00a1df14b0a456b20ea458c682e12afa9afc67d2730d8794b
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


Fixes #565 Analyse lint errors

Description
This PR aims at solving linting errors.
Related issues and discussion
#565

@samagra14 Can you rebase it on latest trunk ? There's this error from previous trunk that makes it fail (the serbian folder)

@teolemon I have rebased the branch.

@policorn @ross-holloway94 @Karljoones up for review

small conflict to solve before merging

Conflicts resolved and merged :)


"Connectivity" plugin libraries are using deprecated methods

Note: C:\Users\km\AppData\Local\Flutter\.pub-cache\hosted\pub.dartlang.org\connectivity-0.4.4\android\src\main\java\io\flutter\plugins\connectivity\ConnectivityPlugin.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

     *********************************************************

WARNING: This version of connectivity will break your Android build if it or its dependencies aren't compatible with AndroidX.
See https://goo.gl/CP92wY for more information on the problem and how to fix it.
This warning prints for all Android build failures. The real root cause of the error may be unrelated.
*********************************************************

Same problem

If anyone wants to submit a PR suppressing this deprecation warning I would approve it.

Closing as connectivity is deprecated in favor of connectivity_plus.


[move-cli] Only print differences in changed resources during verbose execution

🚀 Feature Request
During verbose execution of the Move CLI sandbox commands, changes to resources are shown by printing the old version of the resource followed by the new version of the resource. As discussed in #8527, it may be more useful to print out just the parts of the resource that changed rather than printing the entire old and new versions.
Motivation
The Move CLI sandbox run command prints changes to a resource by showing the old and new version of the resource. For example, here the value of a counter changes from 3 to 4:
Changed 1 resource(s) under address<PHONE_NUMBER>000000000000000A550C18:
    Changed type 0x1::DiemAccount::AccountOperationsCapability: [0, 4, 0, 0, 0, 0, 0, 0, 0, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 85, 12, 24] (wrote 92 bytes)
      Previous:
        key 0x1::DiemAccount::AccountOperationsCapability {
            limits_cap: store 0x1::AccountLimits::AccountLimitMutationCapability {
                dummy_field: false
            }
            creation_events: store 0x1::Event::EventHandle<0x1::DiemAccount::CreateAccountEvent> {
                counter: 3
                guid:<PHONE_NUMBER>0000000000000000000000000000000a550c18
            }
        }
      New:
        key 0x1::DiemAccount::AccountOperationsCapability {
            limits_cap: store 0x1::AccountLimits::AccountLimitMutationCapability {
                dummy_field: false
            }
            creation_events: store 0x1::Event::EventHandle<0x1::DiemAccount::CreateAccountEvent> {
                counter: 4
                guid:<PHONE_NUMBER>0000000000000000000000000000000a550c18
            }
        }

As pointed out by @metajack, this representation has a lot of redundant information because the entire old and new versions of the resource struct get printed out, rather than just the parts that changed.
Pitch
Describe the solution you'd like
This situation can be improved by printing the resource change in the style of a diff:
Changed 1 resource(s) under address<PHONE_NUMBER>000000000000000A550C18:
    Changed type 0x1::DiemAccount::AccountOperationsCapability: [0, 4, 0, 0, 0, 0, 0, 0, 0, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 85, 12, 24] (wrote 92 bytes)
        key 0x1::DiemAccount::AccountOperationsCapability {
            limits_cap: store 0x1::AccountLimits::AccountLimitMutationCapability {
                dummy_field: false
            }
            creation_events: store 0x1::Event::EventHandle<0x1::DiemAccount::CreateAccountEvent> {
-                counter: 3
+                counter: 4
                guid:<PHONE_NUMBER>0000000000000000000000000000000a550c18
            }
        }

The entire resource is still printed, but now it is only printed once and the difference between its old and new versions is clearly marked.
Describe alternatives you've considered

To make this even more compact, parts of the resource that did not change can be hidden.

Changed 1 resource(s) under address<PHONE_NUMBER>000000000000000A550C18:
    Changed type 0x1::DiemAccount::AccountOperationsCapability: [0, 4, 0, 0, 0, 0, 0, 0, 0, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 85, 12, 24] (wrote 92 bytes)
        key 0x1::DiemAccount::AccountOperationsCapability {
        ...
-                counter: 3
+                counter: 4
        ...
        }

This approach may have the downside of losing some context unless the entire path to the change is printed, which could be difficult to do with just a textual diff.

As suggested by @mengxu-fb, the change to the resource can be printed like a traditional diff. This would also apply to resource creation and deletion (see the discussion in #8527 for examples):

  Changed 1 resource(s) under address<PHONE_NUMBER>000000000000000A550C18:
    Changed type 0x1::DiemAccount::AccountOperationsCapability: [0, 4, 0, 0, 0, 0, 0, 0, 0, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 85, 12, 24] (wrote 92 bytes)
=        key 0x1::DiemAccount::AccountOperationsCapability {
=            limits_cap: store 0x1::AccountLimits::AccountLimitMutationCapability {
=                dummy_field: false
=            }
=            creation_events: store 0x1::Event::EventHandle<0x1::DiemAccount::CreateAccountEvent> {
-                counter: 3
+                counter: 4
=                guid:<PHONE_NUMBER>0000000000000000000000000000000a550c18
=            }
=        }

A decision on which format is most suitable will require discussion on the intended consumption of this output.
Are you willing to open a pull request? (See CONTRIBUTING)
Yes
Additional context
N/A

It looks like this was resolved in #9752, so I'll close this issue. Nice work! 👍


provide ability to package a gem that includes test files

Related to #1855.

As noted in #1855, this branch and PR are not necessary, and so I'm closing this PR. Will delete the branch in a week or so unless there are objections here or in #1855.


[PE-D][Tester C] Duplicate names is allowed for add function

Duplicate company names are allowed during input, but not stated in UG. Should indicate on UG how it handles duplicate values as User might accidentally insert multiple times for different files.

Labels: severity.High type.FeatureFlaw
original: WeideTeo/ped#3

Already written in user guide how we handle duplicates

Fix by #187


Fix environment priority colors on Environments Page

https://github.com/freiheit-com/kuberpult/issues/442


update img url in design doc

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
Fixes #1590
Checklist:

[ ] Docs included if any changes are user facing

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.03%) to 37.419%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1/mpi/mpijob_controller.go
2
77.62%

Totals

Change from base Build<PHONE_NUMBER>:
0.03%

Covered Lines:
2317

Relevant Lines:
6192

💛  - Coveralls