Allow withTheme to take an argument for a fall-back theme

Currently, when trying to test or use a component wrapped with withTheme when no ThemeProvider is found in the context, it will throw an error in componentWillMount.
[withTheme] Please use ThemeProvider to be able to use withTheme

As a result, if we want to mount a component wrapped with "withTheme" for testing - we have to wrap it manually with <ThemeProvider theme={{}}> <Component /> </ThemeProvider> to test it properly.
Was it a design decision to always require ThemeProvider to be in the tree to use withTheme? It seems odd to have such a strict requirement on this, since the styled components don't
If not, I see two different solutions to this, either:

Simply set the theme to be an empty object, when not found
Allow specifying a default theme to use in the absence of a ThemeProvider when using withTheme (which could just default to an empty object, handling the previous solution by default). I'm not sure how much of a need this is

I'd be interested to hear your thoughts either way, and I'd be happy to lend a hand making any changes if you think this is something worth pursuing

Hmm, that's an interesting point. I know that when you use react-redux's connect() you can't test that component either, since it requires the theme to exist.
This warning is there to make sure people don't get confused when no theme is passed in because they forgot that that specific component doesn't have a ThemeProvider around it. I'd be hesitant to remove it, but I see where you're coming from.
Hmm, hmm...

I'd agree with your hesitation, I'm not too sure what the right response here is. I think having that safeguard in place could stop a bunch of accidental mistakes (rather than silently saying everything's okay)
I think the main concern I have, is there a incompatibility with how other similar concepts work. i.e.
The existing styled components syntax allows me to access props.theme, even when there may not be a theme available.
e.g. from the examples
// Button.js
import styled from 'styled-components';

const Button = styled.button`
  /* Color the background and border with theme.main */
  background: ${props => props.theme.main};
  border: 2px solid ${props => props.theme.main};
`;

Button.defaultProps = {
  theme: {
    main: 'palevioletred',
  },
};

I guess we need to decide whether withTheme should offer the same flexibility? Or is there an implicit assumption, that components wrapped using withTheme are "theme only" components.

Can't you just do the same thing with your wrapped component?
class ThemedComp extends React.Component { /* ... */ }

ThemedComp.defaultProps = {
  theme: {
    main: 'palevioletred',
  },
};

export default withTheme(ThemedComp);

withTheme is looking for the StyledComponents key in the context, see:
  componentWillMount() {     if (!this.context[CHANNEL]) {       throw new Error('[withTheme] Please use ThemeProvider to be able to use withTheme')     }     ....   }
as a result, that code snippet would fail when not used inside of a ThemeProvider.
See the codepen for a comparison: http://codepen.io/5idpen/pen/XMdzEr

I am facing the same issue. Every component exported using withTheme now depend of a ThemeProvider parent.
I rather if it could be implement by default by just taking the default props theme using const defaultProps = { theme };

ThewithTheme HoC is highly attached to ThemeProvider because it doesn't make sense to use withTheme without it.
@5id @kopax can't you just wrap <ThemeProvider> in your tests?
That's the way you application code is, so that's the way you should be testing it.

I think this isn't an issue with testing, but with inconsistency:

Was it a design decision to always require ThemeProvider to be in the tree to use withTheme? It seems odd to have such a strict requirement on this, since the styled components don't

I agree that this is weird, and would appreciate a PR adding the behaviour from the styled components to withTheme so it's consistent!

Wrapping with ThemeProvider in test will also meet some issue with enzyme:
export const mountWithTheme = (children, options) => {
  const wrapper = mount(<ThemeProvider theme={injectTheme}>{children}</ThemeProvider>, options);
  const instance = wrapper.root.instance();
  return wrapper.mount({ context: instance.getChildContext() });
};

const wrapper = mountWithTheme(<DataContainer
        configuration={testConfig}
        authClient={authClient}
      />);

expect(wrapper.state().dataSummaries).to.deep.equal([]);

as you can have a try, the state() method from enzyme is only work for root wrapper, so that we can't get the state of the component who is wrapped by ThemeProvider.
Any idea or walkaround.

@JimmyLv I think you're confusing this issue with another one. Please continue your question at https://github.com/styled-components/styled-components/issues/624. :wink: It might even have a solution for your problem

@kitten Thanks for the answer :)

@DefoyPhilip no worries! Let me know if this turns out to be an issue still, or open a new issue if you find anything else :)

@kitten I had a version prior to the fix so I'll update my dependencies. I'll let you know if the warning still happen.

@kitten So the warning is still being logged with version 3.1.6
From what I understand, not using a themeProvider as well as not providing a theme via props will always result with a warning even if defining a defaultProps on the component wrapped with withTheme.
This seem to happen because var themeProp = determineTheme(this.props, undefined, defaultProps); will be undefined since determineTheme
var determineTheme = (function (props, fallbackTheme, defaultProps) {
  // Props should take precedence over ThemeProvider, which should take precedence over
  // defaultProps, but React automatically puts defaultProps on props.

  /* eslint-disable react/prop-types */
  var isDefaultTheme = defaultProps && props.theme === defaultProps.theme;
  var theme = props.theme && !isDefaultTheme ? props.theme : fallbackTheme;
  /* eslint-enable */

  return theme;
});

will return the fallbackTheme when props.theme === defaultProps.theme.
So when themeProp is undefined and that styledContext is undefined by not using a themeProvider
if (
        styledContext === undefined &&
        themeProp === undefined &&
        process.env.NODE_ENV !== 'production'
      ) {
        // eslint-disable-next-line no-console
        console.warn(
          '[withTheme] You are not using a ThemeProvider nor passing a theme prop or a theme in defaultProps'
        )
      }

the warning will fire.
Is this right or am I missing something?
Here's the important part of my component reproducing the bug
import React from 'react';
import PropTypes from 'prop-types';
import styled, { withTheme } from 'styled-components';
import RippleEffect from '../ripple/RippleEffect';
import { DEFAULT_SECONDARY } from '../defaultTheme';

class FlatButton extends React.Component {
    constructor(props) {
        super(props);
    }

    render() {
        const { style, rippleColor, disabled, theme, ...rest } = this.props;
        let ripColor = DEFAULT_SECONDARY;
        if (rippleColor !== '') {
            ripColor = rippleColor;
        } else if (theme.secondary) {
            ripColor = theme.secondary;
        }
        return (
            <Flat
                style={style}
                disabled={disabled}
                {...rest}
            >
                <RippleEffect rippleColor={ripColor} disabled={disabled} />
                {this.props.children}
            </Flat>
        );
    }
}

FlatButton.defaultProps = {
    style: {},
    disabled: false,
    rippleColor: '',
    theme: {},
};

FlatButton.propTypes = {
    style: PropTypes.objectOf(PropTypes.oneOfType([
        PropTypes.string,
        PropTypes.number,
    ])),
    children: PropTypes.node.isRequired,
    rippleColor: PropTypes.string,
    disabled: PropTypes.bool,
    theme: PropTypes.shape({
        secondary: PropTypes.string,
    }),
};

export default withTheme(FlatButton);

//in a render with no themeProvider
<FlatButton
    disabled={boolean('Disabled', false)}
    style={object('Style', { marginLeft: '20px' })}
    rippleColor={text('Ripple Color', '')}
>
        {name}
</FlatButton>

@DefoyPhilip We probably just need to replace determineTheme's undefined with the theme prop, i.e.: https://github.com/styled-components/styled-components/blob/master/src/models/StyledComponent.js#L155
Care to send us a PR 😄
cc @mxstbr: does this make sense in your opinion?

Might not be that simple since I'm having the same problem mentioned by johnnyBira

I did do some digging in withTheme.js and found that const { defaultProps } = this.constructor (at least in my case) is undefined regardless if defaultProps are provided. Haven't look into why that is yet though.

@kitten I'm almost done with the pr but I have a question.
This line  { defaultProps } = this.constructor force the component wrapped with withTheme to be coded this way to work and respect eslint rules
class FlatButton extends React.Component {
...
}
FlatButton.defaultProps = {
    style: {},
    disabled: false,
    rippleColor: '',
    theme: {
        secondary: 'blue',
    },
};

FlatButton.propTypes = {
    style: PropTypes.objectOf(PropTypes.oneOfType([
        PropTypes.string,
        PropTypes.number,
    ])),
    children: PropTypes.node.isRequired,
    rippleColor: PropTypes.string,
    disabled: PropTypes.bool,
    theme: PropTypes.shape({
        secondary: PropTypes.string,
    }),
};

const WrappedButton = withTheme(FlatButton);

WrappedButton.defaultProps = {
    style: {},
    disabled: false,
    rippleColor: '',
    theme: {
        secondary: 'blue',
    },
};

WrappedButton.propTypes = {
    style: PropTypes.objectOf(PropTypes.oneOfType([
        PropTypes.string,
        PropTypes.number,
    ])),
    children: PropTypes.node.isRequired,
    rippleColor: PropTypes.string,
    disabled: PropTypes.bool,
    theme: PropTypes.shape({
        secondary: PropTypes.string,
    }),
};

export default WrappedButton;

But by using the component parameter of const wrapWithTheme = (Component: ReactClass<any>)
and coding it this way { defaultProps } = Component
The component wrapped with withTheme could have defaultProps on the original component only
instead of both the original component and the wrapped component.
I've tested it and it work on my test components and also pass your jest tests.
Any thought on this?

@DefoyPhilip You won't have to use defaultProps, but due to its behaviour you can just use this.props.theme and ditch the determineProps altogether actually (as it would just use the default which is the same. So hence we'd only show the warning when the prop in general is undefined.

@kitten It would work but that would force user of withTheme with eslint rules to duplicate propTypes and defaultProps like I've shown on my last comment.

@DefoyPhilip however, that is our current standpoint on defaultProps either way. We can’t make it work by defining them below the withTheme component. We technically shouldn’t repy on that as it’s in “its own domain”. I don’t think it’s a good idea to just check components inside the HOC relying on this.
Optimally the defaultProps on withTheme should only contain the theme in the case you’ve posted

@kitten Fair enough. I'll send a pr soon.

Sorry for dropping the ball on this one guys. Glad you picked this up again @DefoyPhilip, intersting to follow yours and @kitten reasoning behind the problem.
Looking forward to your PR as I'm still seeing this warning.

In a typical jest testing setup it appears that this warning shows up no matter which component is providing the theme prop in defaultProps:
https://codesandbox.io/s/wnyx858rr8

@DefoyPhilip Feel free to send in what you have and we'll figure it out :+1:

@kitten Here's the pr: https://github.com/styled-components/styled-components/pull/1573
Even though it fixes the warning error, it causes an error in my project using styled component. The bug is that using defaultProp on a wrapped component with withTheme at the same time as using a themeProvider is causing the defaultProp to be returned instead of the one from the theme provider.
I've recreated that scenario in a jest test and it passes so I guess it must be an error in my project.

@DefoyPhilip not quite sure what you're referring to? Can you add this description of the situation to the PR please, so I can think about what's going on? Left some comments there as well btw.
So let's move this discussion there :wink:

So is this already merged? I'm still experiencing this issue.


Fix toml-test scripts

Update tests/decoding_test.py to use the format used by the current version of toml-test. I also removed Python 2 support (my distro doesn't ship it, so I can't test it).
Also add tests/encoding_test.py for encoder tests
Still quite a few failures, mostly because it looks like it hasn't been updated to use 1.0 yet:
% toml-test ./decoding_test.py | tail -n2
  valid tests: 139 passed, 18 failed
invalid tests: 230 passed, 53 failed

% toml-test ./encoding_test.py -encoder | tail -n1
encoder tests: 146 passed, 11 failed

Merged. Thanks!


Soundcloud client ID request rate limit reached

Following on from https://github.com/CookPete/react-player/issues/170, this library has become popular enough to be consistently hitting the request rate limit using the built-in Soundcloud client ID, meaning Soundcloud tracks will not work on any players that have not been configured with their own ID.
Perhaps in v1.0.0 the library should force users to pass in their own client IDs.

Fixed by https://github.com/CookPete/react-player/pull/199


Live

I looked over it, it's fine. have to change it back in a few weeks though. Hope this PR goes into the right direction. @hodyroff

it doesnt. i close


Remove TimeLimit and TimeUnit on @Complete

@Complete is optional and thus it makes more sense that developer specifies timeout on @Compensate.
It also makes more sense When timeLimit is reached, the @Compensate is called (so they have defined the time limit on the method which get called) which is not the case when defined on @Complete because the @Compensate will be called in that case.

+1 good catch

The timeLimit on @Complete indicates how long the participant can guarantee completion.
The timeLimit on @Compensate indicates how long the participant can guarantee compensation.
Therefore the two time limits are distinct and both make sense (they convey important/useful and distinct behaviour) - but if either limit is breached the LRA must cancel.
The time limit does contain semantically meaningful information - suppose the participant can always compensate but clean up actions are time bound. In this case, putting an artificial time limit on compensate is then misleading.
[Aside: having distinct attributes on the compensate and complete endpoints also makes sense if the endpoints are handled by different services - I think we did support this in an early version of the client API]

I can see the reasoning behind it but find it too complicated with too many possibilities which can be simplified.
A timeout for the LRA and a time out for the participant (through @Compensate which is required to be a participant).
And if needed for client API (which would complicate the situation again since a participant can join an LRA without the need for any @Compensate method which we now declare as required) we can always add it at that moment without breaking compatibility.

I was thinking about this and I think we can remove time limits from Complete and Compensate altogether because when there is @Compensate method in the class there must also be an @LRA annotation on different method which can define the participant timeout. In fact, the JavaDoc states:
* If the annotated method runs with an LRA context then this element determines
* the period for which the LRA will remain valid. When this period has
* elapsed the LRA becomes eligible for cancellation.

which I believe is precisely what Complete/Compensate timeouts are doing right now. So the user doesn't need to define timeouts in different places and he/she just needs to choose the lower of value from different Complete/Compensate periods and include it in the @LRA annotation.
So if @LRA starts a new LRA then the time limit is for the duration of the LRA. If @LRA defines join LRA operation, the time limit is still for the duration of the LRA but from the perspective of the participant.

I was thinking about this and I think we can remove time limits from Complete and Compensate altogether because when there is @Compensate method in the class there must also be an @LRA annotation on different method which can define the participant timeout.

This seems reasonable for the annotation based approach (though not for the future client API). We will loose the semantic information I referred to above but your proposal simplifies the spec so I am in favour of your suggestion.


ARROW-5361: [R] Follow DictionaryType/DictionaryArray changes from ARROW-3144

At the moment however, all the DictionaryMemo use is internal, it should probably be promoted to arguments (with defaults) to the R functions.
I'll do this here or on another PR if this one is merged first so that r/ builds again on travis.
This now needs the C++ lib up to date, e.g. on my setup I get it through brew install apache-arrow --HEAD, and there is no conditional compiling so that it still works with previous versions. Let me know if that's ok.
follow up from #4316

This failed on Travis: https://travis-ci.org/apache/arrow/jobs/539085011#L3842-L3854
So,

Looks like that may be fixed by running devtools::document() since you did update the inline docs
Please remove the allow_failures from .travis.yml since R is now expected to pass: https://github.com/apache/arrow/blob/master/.travis.yml#L50-L51

Otherwise, once Travis is truly green again, LGTM.

@romainfrancois can you remove R from the allow_failures section of Travis CI?
https://github.com/apache/arrow/blob/master/.travis.yml#L50

I'm currently getting errors on travis that don't seem related to r/ I guess the R job needs some attention.

It's not you, it's https://issues.apache.org/jira/browse/ARROW-5470. I'm poking at a few things now to see if I can resolve it.

Ok @romainfrancois https://github.com/apache/arrow/pull/4443 is in master now so if you merge/rebase, this should pass 🤞

Codecov Report

Merging #4413 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4413      +/-   ##
==========================================
- Coverage   88.41%   88.41%   -0.01%
==========================================
  Files         793      792       -1
  Lines      101335   101217     -118
  Branches     1253     1251       -2
==========================================
- Hits        89598    89486     -112
+ Misses      11490    11483       -7
- Partials      247      248       +1

Impacted Files
Coverage Δ

cpp/src/parquet/properties.h
94.95% <0%> (-1.48%)
:arrow_down:

go/arrow/ipc/writer.go
76.56% <0%> (-1.4%)
:arrow_down:

cpp/src/arrow/util/io-util.cc
74.82% <0%> (-1.35%)
:arrow_down:

js/src/ipc/metadata/message.ts
92.99% <0%> (-1.28%)
:arrow_down:

go/arrow/ipc/file_reader.go
59.64% <0%> (-1.08%)
:arrow_down:

js/src/schema.ts
88.77% <0%> (-1.03%)
:arrow_down:

cpp/src/arrow/flight/test-util.cc
88.72% <0%> (-0.84%)
:arrow_down:

cpp/src/arrow/python/flight.cc
87.69% <0%> (-0.77%)
:arrow_down:

cpp/src/arrow/flight/server.cc
90.06% <0%> (-0.54%)
:arrow_down:

cpp/src/parquet/arrow/writer.cc
96.44% <0%> (-0.5%)
:arrow_down:

... and 70 more

Continue to review full report at Codecov.

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


fix(versions): update Activiti/example-runtime-bundle versions into master

UpdateBot pushed helm dependency: common to: 1.1.15

UpdateBot commands:
updatebot push-version --kind helm common 1.1.15


Option to set a shell for skhd to use

Is there a way to set a shell for skhd to use, or for it to ignore the $SHELL environment variable and default to /bin/bash? My default shell (fish) is rather sluggish to start up (takes ~2 seconds) due to the various addons I have configured and results in slow performance for skhd, but when I switch my default shell to bash and restart skhd, it performs snappily again.
Maybe there's a way to pass the $SHELL environment variable into brew services? Or failing that, I believe that the relevant code to modify is in src/hotkey.c (snippet below), but I'm not exactly sure how as I'm not well versed in C, or what behaviour to change it to as there's probably a reason why skhd defaults to the user's shell instead of bash to execute commands?
void init_shell(void)
{
    if (!shell) {
        char *env_shell = getenv("SHELL");
        shell = env_shell ? env_shell : "/bin/bash";
    }
}

My default shell (fish) is rather sluggish to start up (takes ~2 seconds) due to the various addons I have configured and results in slow performance for skhd, but when I switch my default shell to bash and restart skhd, it performs snappily again.

skhd spawns a non-interactive shell—if you want to fix this properly, separate your fish env files for interactive and non-interactive shells.
You can also run brew edit skhd and edit the shell manually. I suggest searching for "shell" or "fish" or "brew edit" on this issue board, since this has been asked many times before.

Hey, thanks for taking the time to leave a comment. I searched and it has indeed come up many times before - somehow it didn't occur to me to search through the closed issues and only look through the open ones. Guarding my fish configs behind some interactive shell if statements did the trick for me!


Office 365 SMTP Connection Issue

Issue Description
After logging into the server via the client, I set the SMTP server settings in accordance to what Microsoft has listed on the email settings for using Office 365 email as an SMTP relay (smtp.office365.com:587 since I am using SSL). After correctly configuring the message settings I attempted to send the message but received an authentication error. I confirmed that both that my username and password were correct by copying and pasting the input I originally used into the Office 365 login page and successfully logged in. I also attempted to connect to the Office 365 SMTP server on ports 465, 2525, and 25 (both with SSL on and off for each). This also resulted in failure
I also tried to send a message via Gmail's SMTP relay service on port 465 since I have successfully sent messages through Gmail in the past. After configuring the SMTP server using the Gmail settings I was able to successfully send messages on the first attempt.
Next I checked the MX records to ensure that my email was being detected correctly as Office 365. MX records confirmed that Office 365 is the mail provider for the domain.
Reproduction Steps

Start King Phisher
Set SMTP settings as follows per Microsoft:
SMTP Server: smtp.office365.com:587
SMTP Username: Microsoft Office 365 email address
Connect With SSL: On
I receive a Connection Failed: Failed to connect to the SMTP Server. I attempted to reset the SMTP server settings to use Gmail's SMTP relay service and successfully sent email messages on the first attempt.

Environment Details
Host OS: Kali 2016.2
Error Details / Stack Trace
I am just receiving a failed to connect to the SMTP server error as follows:
Checking the target URL... success, done.
Skipped checking the SPF policy because the SMTP server address could not be detected.
Message mode is: Email
Connecting to SMTP server... failed.

This seems easy enough for us to look into. Can you please also post the version of King Phisher you're using.

The client side version I'm using is Version: 1.5.2-beta (rev: d09ca949) and the server side version I'm using is Version: 1.5.1. Let me know if you need any additional information. Thanks for the help.

These docs are a bit misleading. The connection to smtp.office365.com:587 actually requires STARTTLS which King Phisher does not support right now. It only supports plaintext and full TLS / SSL connections.
As it is right now you won't be able to use Office 365's SMTP server.

Thanks for the quick response! I appreciate the help!

This issue has now been fixed in the dev branch. To obtain the changes, you can either wait for them to be merged into the master branch (which will likely take a few weeks) or you can obtain them immediately by opting into beta testing.
Added this feature into the dev branch (see commit 0d31a49cbad675ac9e413deb476e6150130f09bc). When it's available do not enable SSL when connecting to the server. You need to use a plaintext connection and King Phisher will automatically identify that the remote server support STARTTLS and negotiate it for you.


Workflows for binary releases

Changes introduced with this PR
This PR adds workflows for creating binary releases for Arcaflow.

By contributing to this repository, I agree to the contribution guidelines.

@HubertStefanski I don't really care, @sandrobonazzola likes them. :D For Go we use whatever gofmt spits out.

Indeed, please add EOF newlines :-)


Feature/add codeclimate ci

Coverage remained the same at 77.343% when pulling eec1a5c772134e2be067effb28c86c9db42f1bc9 on feature/Add-codeclimate-ci into 4928edc31972695a48294319f7aaae90b12831d1 on master.

Coverage remained the same at 77.343% when pulling 2745be1775d295b77d2a69caa6d15d9c82ae434c on feature/Add-codeclimate-ci into 4928edc31972695a48294319f7aaae90b12831d1 on master.


libremines: init at 1.9.1

Description of changes
https://github.com/Bollos00/LibreMines
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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

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

1 package built:

libremines


[Joy] Force parts of app to use dark mode while others adhere to system preferences

Duplicates

[X] I have searched the existing issues

Related page
https://mui.com/joy-ui/customization/dark-mode/
Kind of issue
Missing information
Issue description
I was looking for a way to have one specific part of my app in dark mode, and another in system mode (which implies following the system mode when it changes) and it appears that I can't find any info related to this.
Context 🔦
My current implementation which nests CssVarsProviders does not work, as whenever the page that follows system mode is opened, and the system is in light mode, the mode changes on the forced dark mode page too.
This is an issue because the page that I want to always display in dark mode, independently from the system's, really looks terrible in light mode due to some images not being transparent.

@BSoDium In this case, you can apply data-joy-color-scheme="dark" to the element that you want to force dark.
<CssVarsProvider defaultMode="system">
  <App>
    …
    <div data-joy-color-scheme="dark">
      // all of the component in this div will use the dark tokens
    </div>
    …
  </App>
</CssVarsProvider>

I will add this to the docs.

Great, that sounds like a clean solution. Thank you very much!


Incorrect Market values (Value is 0)

Upon calling Market API (market.last, market.status etc), I am getting value as 0. I have placed many limit and market orders some of which got executed and some are still in orderbook yet the response I am getting is as follows:
{
"error": null,
"result": "0",
"id": 1
}
What looks wrong here? The result is 0 in all market calls. Any marketprice config change I need to make?

What are your config.json for marketprice and matchengine?
If you query redis, what do you get? Example "get k:ETHBTC:last" ?
Do you see the executed orders stored in the database tables?
Any errors in the log files?
These are the things you can check.

Hi,
So I queried Redis and I am getting "0". For non-existent markets I am getting "nil". So basically value is still 0 there. Also I am able to see executed orders in the database.
As I'm using the docker setup, here are the config files:
Matchengine
{     "debug": true,     "process": {         "file_limit": 1000000,         "core_limit":<PHONE_NUMBER>     },     "log": {         "path": "/var/log/trade/matchengine",         "flag": "fatal,error,warn,info,debug,trace",         "num": 10     },     "alert": {         "host": "matchengine",         "addr": "<IP_ADDRESS>:4444"     },     "svr": {         "bind": [             "tcp@<IP_ADDRESS>:7316",             "udp@<IP_ADDRESS>:7316"         ],         "buf_limit": 100,         "max_pkg_size": 10240,         "heartbeat_check": false     },     "cli": "tcp@<IP_ADDRESS>:7317",     "db_log": {         "host": "db",         "user": "root",         "pass": "root",         "name": "trade_log"     },     "db_history": {         "host": "db",         "user": "root",         "pass": "root",         "name": "trade_history"     },     "assets": [         {             "name": "BTC",             "prec_save": 12,             "prec_show": 8         }, {             "name": "ETH",             "prec_save": 12,             "prec_show": 8         }, {             "name": "LTC",             "prec_save": 12,             "prec_show": 8         }, {             "name": "XRP",             "prec_save": 12,             "prec_show": 8         }, {             "name": "BCH",             "prec_save": 12,             "prec_show": 8         }, {             "name": "AED",             "prec_save": 20,             "prec_show": 8         }     ],     "markets": [         {             "name": "BTCAED",             "stock": {                 "name": "BTC",                 "prec": 8             },             "money": {                 "name": "AED",                 "prec": 0             },             "min_amount": "0.0001"         }, {             "name": "ETHAED",             "stock": {                 "name": "ETH",                 "prec": 8             },             "money": {                 "name": "AED",                 "prec": 0             },             "min_amount": "0.0001"         }, {             "name": "LTCAED",             "stock": {                 "name": "LTC",                 "prec": 8             },             "money": {                 "name": "AED",                 "prec": 8             },             "min_amount": "0.0001"         }, {             "name": "XRPAED",             "stock": {                 "name": "XRP",                 "prec": 8             },             "money": {                 "name": "AED",                 "prec": 8             },             "min_amount": "0.0001"         }, {             "name": "BCHAED",             "stock": {                 "name": "BCH",                 "prec": 8             },             "money": {                 "name": "AED",                 "prec": 8             },             "min_amount": "0.0001"         }     ],     "brokers": "mq:9092",     "slice_interval": 3600,     "slice_keeptime": 259200 }
MarketPrice config:
{   "debug": true,   "process": {     "file_limit": 1000000,     "core_limit":<PHONE_NUMBER>   },   "log": {     "path": "/var/log/trade/marketprice",     "flag": "fatal,error,warn,info,debug,trace",     "num": 10   },   "alert": {     "host": "marketprice",     "addr": "<IP_ADDRESS>:4444"   },   "svr": {     "bind": [       "tcp@<IP_ADDRESS>:7416",       "udp@<IP_ADDRESS>:7416"     ],     "buf_limit": 100,     "max_pkg_size": 1000000,     "heartbeat_check": false   },   "deals": {     "brokers": "mq:9092",     "topic": "deals",     "partition": 0   },   "redis": {     "name": "mymaster",     "addr": [       "redis_sentinel:26379"     ]   },   "accesshttp": "http://<IP_ADDRESS>:8080" }
Unable to see any errors but one thing I notice is that when I call market.last http call, there's not trace_log on the terminal. Usually there is with matchengine requests!

Any update?

I met the same problem too,have you solved it yet?

Nope! No solution yet

oh i met the same problem, why this problem.

I find this problem. in marketprice <config.json>
26-- the author write mq:9092, should be kafaka:9092


Fix plot column order on plot output

Purpose
This fixes a bug reported here. https://mattermost.sig-gis.com/sig/pl/m9656pcdstyuzn33zyadwzp34h

It looks like you changed the column order but not the types of the column. I'm not sure if this was intentional or not.

It looks like you changed the column order but not the types of the columns you switched. I'm not sure if this was intentional or not.

It was.  Only the names were wrong.  The types still match whats returned below.


Save and load vocabulary from text file

@tejaswini Changed base branch from master to develop, please resolve the conflicts.


Replace the icon with the terminal icon of the new UI

The old icon felt a bit disjointed on the toolbar, so I replaced the plugin's icon with a terminal icon from the official Jetbrains icon library: https://jetbrains.design/intellij/resources/icons_list/
It still looks very nice. Icons for light and dark themes are also included!

@HanHan666666 , thank you!


Add Naming functionality to the Omni Protocol

The issue of adding some form of Naming support to the Omni Protocol has been around for over a year, but some of us have been discussing it lately. This is a new issue to track that discussion.
Previous issues include:

Issue #216 Name Resolution System
Issue #222 Property names, identificators and metadata in general
Issue #250 Capturing and distributing application-level data off of the blockchain

Perhaps one or more of these issues should be closed as duplicates.

Perhaps one or more of these issues should be closed as duplicates.

There are probably a few duplicates here. Many issues are not error descriptions, but feature discussions. It would be a start to categorize them in my opinion.


fix CloneCollection

I think it's the same bug as #38, In some cases, values were not added correctly when executing ObvervableList.AddRange.
static IEnumerable<int> Range(int count)
{
    foreach (var x in Enumerable.Range(0, count))
    {
        yield return x;
    }
}

var list = new ObservableList<int>();
list.AddRange(Range(20));

The cause is that when CloneCollection<T>.TryEnsureCapacity is executed, the items from the old array are not copied to the new array.
Therefore, I have modified the old array items to be copied to the new array as well.

thanks!


minimal lazy cube

Enough to load from a file + realise the data

Relevant code sections
(from https://github.com/SciTools/iris/issues/2302#issuecomment-273061295)
cube
    Cube.__init__ : (isinstance) Array
    Cube.lazy_data() : (isinstance) Array, NumpyArrayAdapter
    Cube.has_lazy_data() : (isinstance) Array
    Cube.__getitem__ : (isinstance) Array

Already covered really, under #2307 / #2308


Confusing UX in Speaker button

Describe the bug
The UX of the speaker button is confusing and misleading. When audio is playing out of the headphones, the speaker button is toggled "on", and when it is playing out of the speaker, it is toggled "off".
Expected Behaviour
Either the speaker button icon is changed to a have a "strikethrough" and the behavior stays the same, or the speaker button is toggled "on" when audio is playing out of the speaker, and toggled "off" otherwise.
Steps to Reproduce the Problem
See the minimalistic code example below.
Minimalistic code (recommended)
This repo (branch no-hud-video-bug) demonstrates the issue: https://github.com/mattyg/voxeet-cordova-example
Both devices used were on Android.
Follow the steps below to reproduce:
Device A: connect to voxeet
Device B: connect to voxeet
Device B: plug in headphones
Device A: create conference
Device A: invite user on device B
Device B: click "Accept" on incoming call notice
Audio is playing out of headphones. Speaker button is toggled "on."
Device B: remove headphones
Audio is playing out of speaker. Speaker button is toggled "off."
Specifications
Device: Android
OS: Android 8 & 9
Version: latest cordova-plugin-voxeet

I moved this issue to the voxeet-uxkit-android as it is related to the UXKit itself (not cordova)

Hi @mattyg I created a branch in my own repo for this request, the Pull Request is pending.
Feel free to use this branch for your project - https://github.com/FabienLavocat/voxeet-uxkit-android/tree/barbuttons

Hi @mattyg I created a branch in my own repo for this request, the Pull Request is pending.
Feel free to use this branch for your project - https://github.com/FabienLavocat/voxeet-uxkit-android/tree/barbuttons


How to modify cn=config?

Is your feature request related to a problem? Please describe.
I want to disable anonymous binds and unauthenticated binds without needing to run ldapmodify myself.
Ideally, i supply the LDIF files to the chart and it does it for me.
I tried to supply these via customAcls and customLdifFiles, none work though.
dn: cn=config
changetype: modify
add: olcDisallows
olcDisallows: bind_anon

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcRequires
olcRequires: authc

From reading docs in this repo, modifying cn=config is not possible yet? What are the blockers? https://github.com/jp-gouin/helm-openldap/blob/78f801c07f6f6477e48fd3716bdbe105607d2ee9/README.md?plain=1#L284C1-L284C97
Describe the solution you'd like
The LDIF above can be added somewhere on values.yaml and are configured in the OpenLDAP cluster without manual effort (such as running ldapmodify).
Describe alternatives you've considered
n/a
Additional context
n/a

Reading bitnami openldap docs and it seems that they have an env var for anon binds: LDAP_ALLOW_ANON_BINDING. Will check it out.

I will create a separate issue to allow setting this env var via values.yaml

Hi @davidfrickert ,
some old statement remaining in the doc I’m afraid.
You absolutely can using customSchemaFiles which allows you to update cn=config

thanks @jp-gouin


Improving block parts traced data

Tracing stale block parts, i.e., those belonging to block heights older than the current round state of the receiving peer, can provide valuable insights. This process helps in understanding how well peers are updated about each other's states and the extent of unnecessary stale block part exchanges. Improving the exchange of state updates between peers could potentially minimize these redundant transmissions, hence the bandwidth utilization hence potentially the throughput.
To achieve the above goal, the tracing data pertaining to block parts may require updates in terms of the height and round of each traced block part. This would facilitate easier comparison against the receiving peer's state, enabling the identification of stale parts. Moreover, the current tracing data fails to differentiate between block parts exchanged during block synchronization (when a peer is attempting to catch up) and those propagated in real-time under normal conditions. Recording this distinction as part of the traced data is also necessary.

this is partially addressed in https://github.com/celestiaorg/celestia-core/pull/1292, where we distinguish between block parts for catchup and block parts gossiped during block prop.

the tracing data pertaining to block parts may require updates in terms of the height and round of each traced block part

I'm guessing this means adding more data to the block part trace with the receiving node's current height/round? If so, in general I think it would be more ideal to piece this information together using the existing data instead of duplicating data collection.
I'm assigning myself to this as I think this falls under the network trace, where we can clearly see irrelevant or outdated block parts.

Can you please elucidate on the parts of the current issue that are addressed in #1292, making it easier to track what are not covered yet.

Tracing stale block parts, i.e., those belonging to block heights older than the current round state of the receiving peer, can provide valuable insights

this part I think should be done after data has been collected instead of holding the mutex to read and then record the current step of consensus, since that's already being recorded

differentiate between block parts exchanged during block synchronization (when a peer is attempting to catch up)

this is done in #1292 and the backports


⚠ Bofrost.de has degraded performance

In 5a4d105, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1044 ms

Resolved: Bofrost.de performance has improved in 24018ee after 23 minutes.


Android: Invalid argument: No OpKernel was registered to support Op 'PaddingFIFOQueue' with these attrs

I encountered a problem when using a multibox model to make inference on android platform (using c++ api, just like the android demo). The error says something like this:
tensorflow_jni.cc:361 Error during inference: Invalid argument: No OpKernel was registered to support Op 'PaddingFIFOQueue' with these attrs
[[Node: prefetch_queue = PaddingFIFOQueuecapacity=500, component_types=[DT_FLOAT, DT_FLOAT, DT_BOOL, DT_UINT8, DT_STRING, DT_INT64], container="", shapes=[[-1], [-1,4], [-1], [-1,-1,3], [], [-1]], shared_name=""]]

Thanks for reaching out. We try to keep this issue tracker limited to bugs and feature requests. We recommend posting on StackOverflow for community-driven support. We also ask that people fill out the requested information in the issue template.

@zgq91 If you build with -D__ANDROID_TYPES_FULL__ does this solve your problem? By default int64 is not supported on mobile to reduce binary size.
I'd also try updating to the latest TF, as it sounds like you're an older version (we switched from the C++ API to the Java api a few months ago).


Feature Request: Change "New messages" line color

Why
The current color (black) is hard to see

I mean that "50+ new messages"
In normal discord, its blurple. Maybe it could be the accent color in softx?

Same could be said for the "You are viewing older messages" bar

Hard to see

Changed.


use mkDerivation instead of runCommand for depSpecs

I had trouble building a nixos configuration that included a package built with buildGradleApplication within the gitlab ci. This fixes that.
I assume this has something to do with sandboxing being disabled? I dont really know why runCommand causes issues here, but using mkDerivation doesnt have those issues even though it is less pretty.
I tried just setting src on runCommand and also did the exact same the thing buildPhase and installPhase are doing now but that didnt seem to help either

Hey, thanks for your PR! I appreciate the effort, but I don't understand why this is necessary - this sounds more like an Issue of the specific Gitlab?


The experimental results are inconsistent.

Using the skiplayer provided by the project to run CodeLlama2-13B and LLaMA2-13B-Chat, the speculated decode time in evaluate_sum and evaluate_code is significantly longer than the base model. Could you please explain why this might be the case?

Can you elaborate on what system you are doing this? As I can see matchness is quite high, so this problem shouldn't occur

Yes, the acceptance rate is normal and should be accelerated. Can you rule out whether it is a problem with the sss mode and try essg? In addition, you can update the environment and re-search the skipped layers.


Typos in the Guide to sun.misc.Unsafe

The tutorial is located at https://www.baeldung.com/java-unsafe.
There are the following small issues. To quote the otherwise great article:

In this article, we'll have a look at a fascinating class provided by the JDK – Unsafe from the sun.misc package

To be exact, the class is actually from JRE, not from JDK. I know the terms are often used interchangeably, but I think using JDK may cause confusion in this context.

In this article, we were looking at the Unsafe class and its most useful construct.

One "s" is missing in the last word... ;)

@pbodnar thanks - we'll deal with that ASAP :)


Moved IDrawingContextImpl to Avalonia.Platform.

So it can be alongside its impl brethren.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #917   +/-   ##
=======================================
  Coverage   61.65%   61.65%
=======================================
  Files         533      533
  Lines       20234    20234
  Branches     2883     2883
=======================================
  Hits        12476    12476
  Misses       6929     6929
  Partials      829      829

Impacted Files
Coverage Δ

src/Skia/Avalonia.Skia/DrawingContextImpl.cs
80.31% <ø> (ø)
:white_check_mark:

...Windows/Avalonia.Direct2D1/Media/DrawingContext.cs
64.67% <ø> (ø)
:white_check_mark:

src/Gtk/Avalonia.Cairo/Media/DrawingContext.cs
72.56% <ø> (ø)
:white_check_mark:

src/Avalonia.Visuals/Media/DrawingContext.cs
93.67% <ø> (ø)
:white_check_mark:

Continue to review full report at Codecov.

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


About Modal > 'X': Moves around while user is scrolling

On iPhone 6, the popup-header.close element lags behind the user's scrolling actions. This is more pronounced on the Chrome browser, but also occurs on Safari. On iPhone 4 (iOS 7.0) > Safari, however, the issue is pronounced.
iPhone 6 > Chrome:

iPhone 4 > Safari:

Expected Results:

The X should remain fixed, regardless of a user's scrolling action and speed

Tested on:

iPhone 4S, iOS 7.0.4
iPhone 6, iOS 8.1
iPhone 6 Plus, iOS 8.1.3

iOS seems to currently have a bug where fixed positioned elements within scrolling (overflow: auto) elements that have the setting -webkit-overflow-scrolling: touch; do not work correctly. I have removed the smooth iOS scrolling in the modal to address this issue.
@irfanpirbhai can you please re-test to confirm that the X stays fixed to the top right corner now?

The X is fixed at the top, now, though at the expense of smooth scrolling.
Marking as resolved.
Tested on:

iPhone 6, iOS 8.1, Chrome


Type error Elevenlabs

Hi there. I have a problem, when I add TTS with elevenlabs plugin, I get this error:
Plugin.register_plugin(ElevenLabsPlugin())
TypeError: Can't instantiate abstract class ElevenLabsPlugin with abstract method download_files
livekit version: 0.15.2 but the error still has in version 0.12.0

I don't believe that line is necessary. Also, what is version 0.15.2?  The latest release of agent framework is 0.8.12


Inconsistency with wait.PollImmediate and WaitForEndpointState

/area test-and-release
/kind bug
Expected Behavior
wait.PollImmediate should keep on polling if I pass response checkers through WaitForEndpointState https://github.com/knative/pkg/blob/main/test/request.go#L78 until the state is reached or timeout happens.
Actual Behavior
Since the response checkers for example: https://github.com/knative/pkg/blob/main/test/spoof/response_checks.go#L33 returns true or error, it makes wait.PollImmediate stop polling, that is - only the first endpoint state is checked.
Additional Info
Apologies if I am reading the code wrong, but if this really is an inconsistency, I think the return should be changed to false, nil (in the statuscode check function as well), this makes sense according to me because anyway WaitForEndpointState is the only function which is propogating the response checkers to the Poll method, for CheckEndpointState its defaulted to true, nil and it makes sense because this method's scope is to just check once. If this reasoning makes sense, I can create a PR.

cc @julz

/remove-lifecycle stale

/remove-lifecycle stale

/lifecycle frozen


Update README.md

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 89.15%. Comparing base (f9a04b6) to head (636deaa).
Report is 3 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main       #6   +/-   ##
=======================================
  Coverage   89.15%   89.15%
=======================================
  Files           7        7
  Lines         249      249
=======================================
  Hits          222      222
  Misses         23       23
  Partials        4        4

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


olive oil problem solving

making all olive oil generators multiplies of 8 to avoid oddness with refiner. not a big deal but thought it was worth looking at

Why is making these a multiple of 8 a good idea?


feat(dw): renaming instances of workload to dw

Closes: #RHOAIENG-4748
Description
renamed several instances of "workload" to "distributed workload"

How Has This Been Tested?
tests updated where necessary, visually ran through UI
Test Impact
tests update to match ui changes
Request review criteria:

Self checklist (all need to be checked):

[ x] The developer has manually tested the changes and verified that the changes work
[ x] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[ x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ x] The developer has added tests or explained why testing cannot be added (unit or cypress tests for related changes)

If you have UI changes:

[ x] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

Hi @mturley I remembered I left a comment for the naming. But I can't find it. I would repeat the answer that was from Katie, the content designer. She suggested that we could use "Distributed workload metrics" for now. We could use the single form to stay consistent with other areas (specifically "Project metrics"), but if we get any pushback we can revisit it. What do you think?

@xianli123 - your comment is here
and the change is reflected here

@gitdallas Thanks. It looks good.

FYI this will have some conflicts with https://github.com/opendatahub-io/odh-dashboard/pull/2650 because I moved the cypress tests around there, sorry about that. should be simple to resolve


Hierarchy optimized systems and storage

What problem does this solve or what need does it fill?
Several common entity hierarchy based systems have started to crop up in multiple upcoming and current focus areas.

Current: Transform propagation is reliant on a depth-first traversal of the Transform hierarchy.
Current: #3874 - ComputedVisbility should be inherited from parents/ancestors.
Upcoming: Animation bone binding maintenance require querying a path of named descendants. For example, root/hips/chest/shoulder_L is a top-down hierarchy query based on the Name components of each entity.

There are also several existing cases where the current Transform based hierarchy is either buggy, lacks
What solution would you like?
This will require additional design but it'd be best to have a hierarchy structure that is:

Agnostic to the ECS data that is being stored at each Entity, but enables querying for ECS components as well as it's position within a hierarchy.
Performant to traverse: primarily in both a top-down depth first but also linear manner.
Minimize deferred/time based delays between hierarchy updates and the results appearing in the final output.
Constant time updates to local changes in the hierarchy itself, primarily these operations:

Parenting an Entity to a child
Unparenting an Entity to a child.
Re-parenting an Entity between two different parents.
These should not require a secondary maintenance system to keep it correct.

Easy to detect, deduplicate, and propagate dirtying. Think transitive change detection at the hierarchy level.
Optionally: dedicated hierarchy-optimized ECS storage. This may be a huge stretch goal, but it would speed up any hierarchy traversals by cutting out some of the cache misses.

What alternative(s) have you considered?
Using the current Parent and Children components as is.
Possible Ideas
One of the potential options that doesn't rock the boat that hard is using a tree-based linked list approach.
#[derive(Component)]
pub struct HierarchicalRelations {
  first_child: Option<Entity>,
  prev_sibling: Option<Entity>,
  next_sibling: Option<Entity>,
  parent: Option<Entity>,
}

This has a few benefits/drawbacks over the current Parent/Children component approach:

This component exposes an interface that would encapsulate both Parent and Children as well as let users query for the siblings
of a given Entity without a reference to the parent.
This creates a tree/forest of linked entities where each set of children forms a doubly-linked list. This can be used to traverse the tree                                                                              in many different ways.
This could be split into 4 different components if we need the cache locality, though the random access may negate any cache based perf gains seen there.
Custom iterators and SystemParams can be built on top of queries for this component(s) to more easily query for ECS data based on the hierarchy (i.e. HierarchyQuery<T>::iter_all_in_descendants or  HierarchyQuery<T>::iter_all_in_ancestors)
Updating these pointers just requires Query<&mut HierarchicalRelations>. Query::get_multiple or something similar can be used to update multiple relations at the same time to "atomically" update each of them. Removes the reliance on a secondary system to keep Children up to date.
Ignoring change detection, this would actually have a smaller memory footprint as both Children and Parent, assuming we have Option<Entity> niched. SmallVec<[Entity; 8]> is 64 bytes in ECS storage, and more if it overflows, and Parent is 8 bytes. This single component is only 24 bytes.
The main downside to this is that counting the number of children of an entity is O(n), though this could be fixed via caching.
This loses cache locality of child references, becoming a linked list with random lookups. However, since both this component and the current Children solution are both more or less useless without a secondary Query::get to fetch corresponding components, this might not be a big loss.
This loses the ergonomics of using a for loop over the children of a given Entity. Could be handled with a custom iterator though.

This is an approach seen in bitsquid http://bitsquid.blogspot.com/2014/10/building-data-oriented-entity-system.html, where dedicated storage for the hierarchy was also used.
Additional context

This likely requires a lot of design and RFC around this if we decide to go down this route.
Is it possible to handle this with ECS relations?

Related discussion of current limitations, with a focus on bugs and usability: #2572.
This is effectively a more-scoped version of #3742.

Rather than storing Parent and Child components, simply store a Hierarchy resource.

One downsidde to this is that this blocks any concurrent editing of the hierarchy, at least not without a RwLock of some kind. Though that might be desirable for determinism purposes, and arguably Query<&mut HierarhicalRelations> when using Query::get_multiple is in a similar boat.

However, mutation, beyond the local scope is probably not something we should be optimizing for here, since the heaviest operations involve traversing and reading the hierarchy. It's probably best to think of the ways we want to be querying this structure what other non-mutative operations we want on it.

Dirtying. Think of this as hierarchical change detection. A good number of these cases benefit from finding changes to the hierarchy. This should be used in tandem with normal change detection to seed the dirtying.
Value dirtying - This is a change in an ECS component that causes a propagating change in it's children or ancestors. A great example of this is visibility inheritance. If an entity is no longer visible, it's children aren't visible either. This may require a form of deduplication to prevent an exponential number of tree traverals.
Structural dirtying - This is a result of changing the hierarchy itself. Structural dirtying implies value dirtying here.
As suggested by this article, mutating the internals of a hierarchy structure can optimize these use cases.
Path queries. These utilize some criteria (i.e. Name components), to find one or more descendants of a ancestor.
Blanket traversals. These could be breadth-first or depth first depending on the use case. Needed for the dirtying use cases.

Some additional observations:

Unless we have dedicated hierarchical ECS storage for component data, fragmented Query::get calls are unavoidable. Even then the question of hierarchy maintenance requires quite a bit of swapping and shifting of storage, so the gains here might be quickly negated outside of simple toy examples.
Solutions that aren't in ECS storage (i.e. resources) will require a mapping back to Entity of some sort, be it HashMap, BTreeMap, or SparseSet. All 3 arguably lose out a bit in terms of cache performance, and require a bit more memory. Entity itself cannot contain hierarchical data in it as of now, though some bit-mangled version of it might be able to.
Relations, AFAIK, only solves the issues of representing, updating, and maintaining one level of the hierarchy's relationship with it's immediate neighbors. The resource or hierarchical ECS storage solutions targets the problem globally and might be able to be optimized more aggressively.

One downsidde to this is that this blocks any concurrent editing of the hierarchy, at least not without a RwLock of some kind

I will note that this is currently the case with commands, but this is a limitation.

Unless we have dedicated hierarchical ECS storage for component data, fragmented Query::get calls are unavoidable. Even then the question of hierarchy maintenance requires quite a bit of swapping and shifting of storage, so the gains here might be quickly negated outside of simple toy examples.

Yep: however by storing e.g. a Transform in this hierarchical storage we're losing performance on linear iteration instead (which is also quite common), unless we're duplicating data across both storages.

Relations, AFAIK, only solves the issues of representing, updating, and maintaining one level of the hierarchy's relationship with it's immediate neighbors. The resource or hierarchical ECS storage solutions targets the problem globally and might be able to be optimized more aggressively.

This is correct for some but not all of the potential designs :) The index-backed solutions can be custom-optimized for these situations.

@alice-i-cecile  another big drawback to "hierarchy as a resource" is that it is not particularly scene friendly. It assumes (1) that we support loading resources from scenes and (2) that each time we load a scene's instance of the hierarchy resource, we "merge" that with the global version.
I do think a Hierarchy / left+right pointer based approach is worth considering (note that I read the bitsquid article linked above way back when I was first deciding how hierarchy would work in Bevy). The ability to update the hierarchy "transactionally" is really nice (although this could be accomplished with split components, with the right scoping). I also really like the O(1) entity deparenting.
The main reasons I opted for split components vs "Hierarchy left+right":

it made it easy and cheap to query for "hierarchy roots" (just do Query<Entity, Without<Parent>>), things with parents (With<Parent>), and things with children (With<Children>). Doing a full scan of all Hierarchy components every time a root is needed (ex: propagating transforms, updating UI layouts, etc) isn't ideal.
You can query for Changed<Children> to detect when a child has been added / removed from a specific entity.
you can make "root queries" vs "everything else queries" disjoint (and therefore they can exist at the same time).

However during this early decision making process, I very clearly undervalued "always consistent" hierarchies. Given how central hierarchy can be to game logic, being able to trust it at a given point in time (and not just after the Hierarchy sync) is pretty important. The "consistency problem" must be solved, but I do think we lose a lot of valuable functionality by moving to the "Hierarchy left/right/parent" approach.

Yep: however by storing e.g. a Transform in this hierarchical storage we're losing performance on linear iteration instead (which is also quite common), unless we're duplicating data across both storages.

As suggested by the bitsquid article, which has been referenced several times in this thread already, you can keep what is effectively a Vec<Transform> around. Iteration is still 100% linear, and better yet, it enforces that parents are iterated before their children. The main issue here is that such a storage aggressively swaps the data stored within it upon dirtying any of the components held within: could be a very write-heavy solution for large pieces of data and should generally be used in cases only when mutations are a very small subset of the available entities.

Also for "hierarchy as a resource", it creates a "garbage collection" problem. Every time an entity is despawned, we now need to check if it exists in the hierarchy. You can't know ahead of time, so you need to check every despawned entity.

it made it easy and cheap to query for "hierarchy roots" (just do Query<Entity, Without>), things with parents (With), and things with children (With). Doing a full scan of all Hierarchy components every time a root is needed (ex: propagating transforms, updating UI layouts, etc) isn't ideal.

Is this something we can't deal with using either Resources that wrap HashSet (i.e. Root(HashSet<Entity>) and Leaves(HashSet<Entity>)) or marker ZSTs? Both of which can be enforced in O(1) time and can have linear iteration time.

You can query for Changed to detect when a child has been added / removed from a specific entity.

Wouldn't a inverted filter work here too (i.e. Changed<Parent> where Parent(Option<Entity>) and a corresponding query for the parent's components) also suffice? This is less ergonomic, but IMO this is resolvable with a custom SystemParam.

you can make "root queries" vs "everything else queries" disjoint (and therefore they can exist at the same time).

Can you explain this more? Read-only queries should be easy enough to work with without clashes.

Overall, I don't think the underlying representation here is something we should encourage users to directly query, much like ECS itself, but rather provide solid wrappers and abstractions (i.e. custom SystemParams, dedicated hierarchical query types) that provide the ergonomics needed.

that we support loading resources from scenes

FYI, #3580 does this.

FYI, #3580 does this.

IIRC that PR doesn't support merging resources with one in a scene. We'd likely need a specialized solution that handles merging and unmerging the resource upon scene load and unload. Though admittedly, so would any scene load/unload that directly handles Entity references too.

Also for "hierarchy as a resource", it creates a "garbage collection" problem. Every time an entity is despawned, we now need to check if it exists in the hierarchy. You can't know ahead of time, so you need to check every despawned entity.

We could add a Hierarchy component for this, but then this results in another synchronization problem...

Instead of Parent(Option<Entity>) we could use the following components
#[derive(Component)]
pub struct Parent(Entity);

#[derive(Component)]
pub struct FirstChild(Entity);

#[derive(Component)]
pub struct Siblings {
  pub prev: Option<Entity>,
  pub next: Option<Entity>
}

Pros

This works based on component presence., so it works with filters like Changed<Parent> or Without<FirstChild>.  Root queries still work as expected without any additional resource to maintain it.
This relies on Commands to work properly, but that delays consistency until the next command buffer flush (i.e. stage boundaries, exclusive systems) instead of relying on a singular maintenance system.

Could be a reasonable compromise here given both engine systems and developers being used to the idea of delaying changes to a common synchronization point.

This still guarantees O(1) hierarchy updates.
Addition/removal costs can be eased with SparseSet storage for these links.

Cons

This complicates the code for managing the operations on the hierarchy quite a bit, but can be mitigated via query wrappers and custom SystemParams.
Structural changes are not visible until the next command buffer flush. Any mutative changes will be inconsistent until then. For example: a new child onto a parent will update FirstChild and the Sibling components respectively, but Parent is not going to be there until the command buffer flush). This might not be a good idea if we stack mutliple changes in the same system. This definitely needs to be explored more.
Will cause pretty hefty archetype fragmentation.
This does not address the issues of cache-friendly iteration, just consistency.

The main reasons I opted for split components vs "Hierarchy left+right":

It's easy and cheap to query for "hierarchy roots" (just do Query<Entity, Without<Parent>>), things with parents (With<Parent>), and things with children (With<Children>). Doing a full scan of all Hierarchy components every time a root is needed (ex: propagating transforms, updating UI layouts, etc) isn't ideal.
You can query for Changed to detect when a child has been added / removed from a specific entity.
You can make "root queries" and "everything else queries" disjoint (and therefore they can exist at the same time).

I do think we lose a lot of valuable functionality by moving to the "Hierarchy left/right/parent" approach.

Isn't this something we can deal with by either using Resources that wrap HashSet (i.e. Root(HashSet) and Leaves(HashSet)) or marker ZSTs?

What if we have both the HierarchicalRelations component for general hierarchy traversal and IsParent and IsChild markers for cheap root-finding? AFAIK there's nothing Parent and Children do better except iterate the children faster.
I'd vote against splitting HierarchicalRelations into separate components (Transform all over again).

One more note: edited the description to include the previous attempt to split the hierarchy from bevy_transform. Not sure if it's doable given these new proposals.

The way I interpreted #2789 was that the transform systems are too special since they involves two components (Transform and GlobalTransform). We could add a bevy_hierarchy crate for general hierarchies and have bevy_transform stay the same.
I did like the suggestion in there to parameterize Parent and Children into Parent<T> and Children<T> since it does seem like Parent and Children get (mis)used for things that aren't tranforms. Same could be applied here.
#[derive(Component)]
pub struct Hierarchy<T> {
  parent: Option<Entity>,
  first_child: Option<Entity>, // should there be a `last_child` field as well?
  prev_sibling: Option<Entity>,
  next_sibling: Option<Entity>,
  _phantom: PhantomData<T>,
}

#[derive(Component)]
pub struct IsParent<T> {
   _phantom: PhantomData<T>,
}

#[derive(Component)]
pub struct IsChild<T> {
   _phantom: PhantomData<T>,
}

The way I interpreted #2789 was that the transform systems are too special since they involve two components (Transform and GlobalTransform). We could add a bevy_hierarchy crate for general hierarchies and have bevy_transform stay the same.

Arguably, the same parenting structure for transforms should be used for the others, since it's the logical expectation here. Not too keen on the idea of multiple overlapping and conflicting hierarchies, particularly when it comes to showing it to users in an editor. We could split it out so that the hierarchy exists separately from a "f32-based Transform system operating in Euclidean space" that bevy_transform currently provides. It would allow others to implement their own transform systems like a f64 backed one, a fixed point transform system, a UI-focused rect-based transform system, or internal efforts for a dedicated 2D one too, but also leverage the parent-sibling-child relationships that seem endemic to all of them.

Arguably, the same parenting structure for transforms should be used for the others, since it's the logical expectation here.

I would parameterize the types "just for the heck of it" since it would help clarify how the components are used. That way, coupling other types to the transform hierarchy becomes an intentional choice, instead of users accidentally using the same components.
And there are clearly hierarchies people want to express that have nothing to do with transforms.

Arguably, the same parenting structure for transforms should be used for the others, since it's the logical expectation here

This was @cart's take: we should try to have a single hierarchy that we use for everything (if feasible).
I'm not sure I personally agree, but I'm willing to explore the direction the design takes. However, I think it's critical to support the inheritance of other properties (hopefully even user-defined properties), and to be able to control what is and isn't inherited (translation? scale? visibility?) at an entity-level.

I think I would rather just provide the tools for managing, traversing, and querying the hierarchy. Operations like dirtying, propagation, and inheritance may be too use case specific to make generic systems for.

Getting mixed signals here. Were you trying to generalize or are you focused on stuff that would show up in an editor?
I was just saying that people misuse Parent and Children for non-transform-related things, so we should do something to clarify that all these components are coupled to the transform hierarchy.
A tree of linked nodes would be useful in general (just like ECS relations), but I see no reason to split bevy_transform if the only hierarchy this issue cares about is the transform hierarchy (and properties that inherit from it).

Anyway, I was just saying that people misuse Parent and Children for non-transform-related things, so we should do something to clarify that all these components are coupled to the transform hierarchy.

Agreed: we should either do this, or allow people to opt-out of this coupling.

The only real coupling is "the crate these things live in"

@cart are you okay with me redoing #2789 and splitting the crates apart? Regardless of the rest of the details, I think this is a necessary split and will seriously reduce user and developer confusion about the intended design.

Whipped up a summary of the discussions here as an RFC: bevyengine/rfcs/pull/53. Please take a look!

@cart are you okay with me redoing https://github.com/bevyengine/bevy/pull/2789 and splitting the crates apart? Regardless of the rest of the details, I think this is a necessary split and will seriously reduce user and developer confusion about the intended design.

Yeah I'm cool with this. Thanks for checking.

What I found inconvenient about the current system is that when I store a scene, I have to store Parent and Children in order to restore the hierarchy later. And the same for replication over the network.


Add Mobile Network information

It would be nice to add the information about whether or not the device is connected to a mobile network. Similar to the Wifi-information. Shouldn't be that hard looking at SystemInformation.java and AnalyticsMessages.java

@jnagels I know it's been a long time.. Trying to follow up on this. Why do you think such info is useful? I might be missing something here. But, if a user is not connecting to both of wifi and mobile network, Mixpanel won't receive any data. So, if $wifi is false, you can assume the user is on mobile network.

@yinfeiru When offline, we cache the events and send them when the device is back online. So it's interesting to see which events happen offline vs online.

@jnagels it's legit. will do.


Cannot place or remove tiles on gridmap

Operating system or device - Godot version:
Fedora 26 - Godot 3 master.
Issue description:

I am unable to edit the gridmap tiles.
When I click on the GridMap node, the side menu for the tiles shows up properly and I can select them, but clicking on the world does not place tiles.
Steps to reproduce:
Try to edit the grid cells.
Link to minimal example project:

The platformer 3D demo.

Just a hunch, but it might be related to @kubecz3k's recent changes to improve the usability of selecting spatial objects in the viewport.

Note that this bug is also present on the godot 3 alpha, so it is not related to the recent changes related to @kubecz3k

this should be fixed now, closing


Fix most severe warnings from dependabot

Just because github was nagging me every week about this. The root cause is that the vscode dependency is deprecated and not kept updated since they split it into two parts in 2018.
Reference

What's the correct thing instead of vscode?

@waywardmonkeys the correct thing is to replace the dependency on vscode with @types/vscode which provides the typescript type definitions for all the interfaces that the editor exports. Additionally there is a package vscode-test which contains test stuff - I can't remember if we use them or not. Formerly these two things were rolled together in the same vscode dependency. There are some security issues with the sub-dependencies of vscode and these haven't been updated by MS since it's deprecated.
I will have a proper look, I was just being lazy. It may be trivial just to replace vscode with @types/vscode.

I have done this properly now, it is using the latest @types/vscode dependency.


Correct Render<E> method signature argument order

Closes hotwired/turbo#812
The order of the arguments in the Render signature are incorrect, and were introduced in that incorrect order.
Luckily, the default implementations and the tests that exercise that feature are in the correct order.
The signature's argument order was inspired by
morphdom's, with the latter argument serving as overrides for the prior argument.
Custom rendering isn't yet covered by Turbo's documentation website, so we have an opportunity to document it thoroughly and correctly, starting with TypeScript's understanding of the interface.

@kevinmcconnell would you be able to review and merge this change?


Added missing class to ForgeUploadFile call.

Added try..catch to character portrait upload.

Fixes #558


renewals are not happening

I have a couple of letsencrypt containers running, started in October. I'm now finding that they are not renewing the certs and my question is how to troubleshoot this. What I'm seeing in the container logs is:
Jan  9 09:40:14 idocs idocs_letsencrypt_1[691]: Creating/renewal idocs.example.com certificates... (idocs.example.com)
Jan  9 09:40:14 idocs idocs_letsencrypt_1[691]: Sleep for 3600s

But the certs aren't being renewed and run out in ~2 weeks. I did a docker exec into the container and I see:
/etc/nginx/certs/idocs.example.com:
total 16
     4 -rw-r--r--    1 root     root          3169 Jun 30  2016 account_key.json
     4 -rw-r--r--    1 root     root          2158 Oct 28 19:05 cert.pem
     4 -rw-r--r--    1 root     root          3805 Oct 28 19:05 fullchain.pem
     4 -rw-r--r--    1 root     root          3271 Oct 28 19:05 key.pem

So it looks like nothing has been updated. I don't see any errors anywhere. Where do I need to look to see what's going on?

I now see that in one of the containers I see an error
Unhandled error has happened, traceback is above

Debugging tips: -v improves output verbosity. Help is available under --help.
Sleep for 3600s
Creating/renewal xyz.example.com certificates... (xyz.example.com)
2017-01-09 18:16:28,877:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/simp_le.py", line 1401, in main
    return main_with_exceptions(cli_args)
  File "build/bdist.linux-x86_64/egg/simp_le.py", line 1386, in main_with_exceptions
    persist_new_data(args, existing_data)
  File "build/bdist.linux-x86_64/egg/simp_le.py", line 1282, in persist_new_data
    client = registered_client(args, existing_data.account_key)
  File "build/bdist.linux-x86_64/egg/simp_le.py", line 1224, in registered_client
    client = acme_client.Client(directory=args.server, key=key, net=net)
  File "build/bdist.linux-x86_64/egg/acme/client.py", line 63, in __init__
    self.net.get(directory).json())
  File "build/bdist.linux-x86_64/egg/acme/messages.py", line 169, in from_json
    raise jose.DeserializationError(str(error))
DeserializationError: Deserialization error: Wrong directory fields

FYI, I pulled the latest companion docker image and relaunched the companion container and that did a renewal. I'd still like to know how to tell what was going wrong.

See issue #130


Change shouldBe/shouldEqual error message to a format in which IntelliJ shows the diff

IntelliJ automatically detects any messages of the format
expected: <bla-blah> but was: <blah-blah-blah>
and shows a link to 'see the diff', which opens it in a convenient diff window.
All that is required to support this is to change the error message format to match.
http://stackoverflow.com/a/10945655

I forgot to mention the reason why I think this is needed: Currently it's difficult to see what went wrong when comparing, for example, 2 data classes with lots of fields and possibly other nested data classes. This suggestion should help make it a bit clearer.


[QUERY] Stack trace logging

Query/Question
As per the logging design guideline, logging of stack trace should be done only for  specific log levels, verbose as per general guideline but languages may have different name for this level.
Opening this issue as a question to confirm that we're not logging sensitive stack trace unless user requested it by setting appropriate level.

We are not logging stack trace explicitly in .NET at any level. EventSource has it's own infrastructure to provide stack trace information to consumers that require it.

Thanks, @pakrym so SDK don't deal with it, but delegate to EventSource and ES take care of /controls any security aspect of trace, I assume that's the idiomatic model in the .NET world. Feel free to close this if there is no further action needed in the SDK side.


differencial pins?

Hi,
the digital differential ports for data(TX and RX) and clock are not propagated so with this board is not possible to use it like with the ATREB215-XPRO eval board.
you plan to add this?.

No, but feel free to open a pull request doing so, or to create a fork with this added.

OK, I can try.
any board/connector in mind?.
My idea is to connect a FPGA board compatible with lvds at this frequencies. something cheap and powerfull like the EBAZ4205.


fix docker link on install page (#964)

backport from #964

LGTM

LGTM

Same change should be done in home.tpl I guess


self link rel from GET words has invalid character

self link renders as:
https://beta.taggloo.im/api/v4/words?word=aalin&dictionaryId=17&)offsetIndex=0
Note ( character.

Wasn't able to replicate exact issue but have improved generated URL.


model for street view

i sir , thank you so much for make this project opensource , i use your model but  it cant detection all masks , i think datasets is limited , could you  please send me new model for detection masks in street or drone view , thank you in advance

@zongoalbert We lack the data in street view. Can you provide the street or drone view dataset?

HI @AIZOOTech  unfortunately not yet  ,,,  but i will searching to provide the datasets of drone and street view, i promise you when a get the data i will share it with you.

HI Sir , i found this link Sir please check it and give me your feedback

https://www.kaggle.com/andrewmvd/face-mask-detection

https://www.kaggle.com/andrewmvd/face-mask-detection

this is the result than someone use this data : https://drive.google.com/folderview?id=1-PEfpsP7tEp-y4PaieQ3h8I-bsZrt45r

Could you send me the code of Train data ?


Handle route relations for roads

Highway refs are often indicated by route relations, so we need to support them.
One relation may be part of multiple road route relations, each of which has a ref and network tag. They also might be part of no road route relations and have a ref tag. I don't think we need to handle the third case of a ref tag plus refs from relations any different than the first tag.

Bake the refs of the route relations onto the roads, right?

Yes, we need the line strings to have appropriate properties. The difficult part is handling multiple relations.

Route relations intentionally provide more structure than way refs, so the two mechanisms aren’t quite equivalent – the structure should persist in the tile’s features to some extent, or it would defeat the purpose of route relations. openmaptiles/openmaptiles#1620 adopts a predictable route_#_key format for properties dissolved from route relations, allowing clients to process each value without resorting to any parsing.[^semicolon]
If you need to cap the maximum number of concurrent routes along a given way for performance reasons, here are some statistics to help you arrive at a practical limit: https://github.com/ZeLonewolf/openstreetmap-americana/issues/894#issuecomment-1765395845 https://github.com/ZeLonewolf/openstreetmap-americana/issues/894#issuecomment-1888362411.
[^semicolon]: This would also be a sound server-side solution to the problem of pretty-printing semicolon-delimited value lists.


I can't receive reset password mail

If you have misplaced your password click here<-- submit e-mail adress,then Home come again. I wait long time ago,No mail from Node-RED Alexa Home.

What is your username?

Fixed, I'd messed something up with my mail server when I moved it a couple of days ago.
If you hit the link again it should work

Thank you!  I receive reset password mail.  Then I set new password,and I can login!


Code release

Hi， @ericzzj1989 @LingzheZhao @wangpeng000 @akawincent @bangyan101
I've noticed that the paper has been accepted. When will the code be open-sourced?
Thanks.

Hi @chengwei0427,
Thank you for your interest! We are planning to release the code within this week. Please stay tuned.


Add partial implementation of macro edge expansion.

Things that remain open as of this PR, and mostly have open TODOs:

Some missing validation.
Inserting the macro's AST.
Merging the selections on either side of the macro edge.
Rewriting query arg names, to make using the same macro twice / using a macro when it tries to use the same parameter names as existing user code work.
Handling user-provided type coercions immediately within a vertex field produced by a macro edge.

Fee free to take over this branch, and either merge it or continue building upon it, as you see fit.

Coverage decreased (-1.3%) to 92.172% when pulling 75640a4880dcff824b9430b652466ae0b3e78a1d on expand_macro_start into 304a086ad8ae3bbb8fed8082e0d1f5144dc7783c on macro_system.


Fix: tests weren't actually testing limit 0 cases

Great catch @imrehg! Thanks for the PR, much appreciated! ❤👍


Consolidates timestepping-related fields into struct

This PR consolidates all timestepper-related fields into a struct called AdamsBashforthTimestepper.
This change is also necessary to eventually support multiple time steppers, though this is far in the future.
The Adams-Bashforth parameter can now be set in the model constructor.
cc @jm-c

Looks great!
My only comments would be about the filenames:

kernels.jl sounds a little vague. Would time_stepping_kernels.jl be better?
Not sure what the Julia convention is but I think having underscores between words in filenames improves readability: e.g. time_steppers.jl instead of timesteppers.jl.

Julia used to recommend somewhere in the documentation that one should only use underscores when necessary (and many of the core julia functions reflect this style). I guess I felt that timesteppers is clear and readable. I'm fine if you change it though. It would be more consistent with the rest of the code anyways (for example, the function time_step!.

@jm-c recommends that we shelve this PR by the way until we deal with other stuff. The changes in this PR affect many of the other PRs.

Ah fair enough, we can prioritize the PRs.

Let's close this --- the code will change a lot soon and we can easily rewrite these changes.


FR: All-in-one search mode

Currently you have to choose between multiple commands such as File name search or Recent search. But you have to choose it beforehand. It would be much more practical if you just have a single command where you type your query and change the mode from there via buttons or special query syntax

Hi, @mnaoumov :)

It would be much more practical if you just have a single command where you type your query and change the mode from there via buttons or special query syntax

We can already use it by the "Command prefix" settings. In the case of the below example,

Input :e hoge will search "hoge" as "Recent search" even when the dialog didn't start with "Recent search" command.
https://user-images.githubusercontent.com/9500018/223437652-244ccf97-267e-422c-917b-88f56cba71db.mp4

@tadashi-aikawa thanks for the feedback. This is already super useful. But I have a few UX suggestions.

A single keystroke that switches search modes circularly. Equivalent to Search Everywhere feature in JetBrains products (ReSharper, IntelliJ IDEA, WebStorm, Pycharm etc)
Visible prefix such as :e shown, so you can get used to them
Ability to switch between search modes by clicking in dropdown

@mnaoumov
Thank you for suggestions :)
Right. They would be useful because we may want to switch searches after entering a query. I want more opinions from some users. Then, of course, I'll consider the specification of the feature 👍

Yes I would really really want this feature as it is the only thing I'm missing from while using Quick Switcher++. This would be a great addition to the plugins.
The preview mode and extensive customization of this plugin is too good to miss out on regardless. Thank you very much for such a great plugin!!

I want to add that it would be great to also include Grep mode into this all-in-one search mode as currently it doesn't have a command prefix like other searches


Company ID and Type added to Property

Small PR for additional fields; slowly but surely I'll map em all.

Coverage remained the same at 100.0% when pulling 4b579af56ca7571f1b1404b426f1d7208cde5b80 on property-mapper-changes into d3d7a6afd792d3aaa0e3a0d538023385c6ef8eaa on master.

Coverage remained the same at 100.0% when pulling 4919ebb39428749ba6bdb981ac7d0c37d1369433 on property-mapper-changes into d3d7a6afd792d3aaa0e3a0d538023385c6ef8eaa on master.

Coverage remained the same at 100.0% when pulling 0cb188a9036b5b9dfbdbe8799115bc67cc5befe0 on property-mapper-changes into d3d7a6afd792d3aaa0e3a0d538023385c6ef8eaa on master.

Coverage remained the same at 100.0% when pulling f0ccda0594b7fcec0420dcda5df5f4f2b7c5bcd1 on property-mapper-changes into d3d7a6afd792d3aaa0e3a0d538023385c6ef8eaa on master.

Coverage remained the same at 100.0% when pulling 7c9ee7c42ad3aa563c40134e02aabf2e5d9dd7a7 on property-mapper-changes into d3d7a6afd792d3aaa0e3a0d538023385c6ef8eaa on master.


When initializing from 1D array, behaviour is inconsistent with Pandas

Say we have a 1D numpy array of shape (4,). We initialize SparseFrame and pd.DataFrame with it. Both will have shape (4,1). Underlying numpy array of pandas data frame will also have shape (4,1), but sparsity's toarray() method will give a 1D array of shape (4,).
>>> a2 = np.array([0,1,0,0])
>>> a2.shape
(4,)
>>> pd.DataFrame(a2).shape
(4, 1)
>>> pd.DataFrame(a2).values.shape
(4, 1)
>>> sparsity.SparseFrame(a2).shape
(4, 1)
>>> sparsity.SparseFrame(a2).toarray().shape
(4,)

This leads to problems when multiplying a SparseFrame by another one-column SparseFrame.

Although the inconsistency exists, I can't reproduce errors in multiplication. Maybe I was wrong.


Request: add a --refresh option?

Not sure whether to just implement this myself first, since I'm not sure if it matches your wishes for the tool, but if so let me know and I might just do that.
In many cases I find myself wanting to just refresh a pull request without changing the text, and would be nice to have an easy way to do so without having to edit the description in the editor.

You can add EDITOR=cat in front of the command and create an alias for it.

That would work if I want to just keep the description to the autogenerated one. But sometimes I have a more explanatory pull request description than the commits themselves alone (particularly when I'm convincing someone why something needs to be merged ;))

Sounds fine indeed. It's likely it should detect if the editor is needed or not in the end.


Portfolio , Skills and Connect card are not working responsively

Landing section and name typed section is working responsively and can be scaled as device width however after that cards are not working properly specially portfolio [ about me + image + resume button ] and those cards are not scalable and animation is not stable.
Please assign me the task , I wanna contribute. Maybe unable to make all responsive but I can fix some bugs and make animation stable.

@adithyapaib hello please look this issue and let me know if I'm getting opportunity to contribute.

I would love to contribute on this issue ...plz assign this to me.
I can resolve this issue and also make it responsive.

@adithyapaib hello please look into this issue and let me know if I'm getting opportunity to contribute.

Done

I would love to contribute on this issue ...plz assign this to me. I can resolve this issue and also make it responsive.

Yes send a PR I will merge it


Container log colors

I have ANSI color coded logs in a container and the colors are not showing up. Instead i see the escape codes.
A fix should show the colors, not the escape codes.
Alternatively the escape codes could be hidden, and the text remain its default color.

This problem is something other than "just read the codes" I think.  I have two different containers that output colorized logs, one shows colors in lzd and the other shows mangled escape codes. /shrug


Bugfix/lk 4903 fix crashes

Hello and thank you so much for your contribution!
We are willing to merge this next week.
There is currently a new Major Android SDK release so I think it would be a good way including it as well

Hey there!
I forked your branch and included several modifications. Thank you so much for your help. You contact contact<EMAIL_ADDRESS>to get some goodies :)


Reject migration of VMIs with non-migratable condition

What this PR does / why we need it:
This PR fixes an API validation that should reject migration of VMIs with a non-migratable condition
and adds a functional test to verify this.
Which issue(s) this PR fixes
Fixes #2072
NONE

Is there some subtle change in behavior here that fixes something?

Yeah. I didn't understand this at first, took me a while to debug.  getVMIMigrationCondition was returning a pointer to an element in the vmi.Status.Conditions array that has changed as range progressed, returing only the last element. I've simplified all of that and got rid of the helper functions.
func getVMIMigrationCondition(vmi *v1.VirtualMachineInstance) (cond *v1.VirtualMachineInstanceCondition) {
for _, c := range vmi.Status.Conditions {
		if c.Type == v1.VirtualMachineInstanceIsMigratable {
			cond = &c
		}
	}
	return cond
}

Migration tests are passing and this PR doesn't affect anything else. I'll merge this.


"Does Not Exist" verification/validation rule in a Coded UI test doesn't work as expected

The "Does Not Exist" verification/validation rule in a Coded UI test doesn't work as expected.
For example, there's a commented out validation rule check in .\src\SpecBind.CodedUI.IntegrationTests\Features\ValidationFeatures.feature:
#| Foo          | Does Not Exist |       | --> this may still need some work.

Why is it commented out?
Uncommenting it still makes the test pass.
In either case, I've found two issues:

If the row is set to

| Foo          | Does Not Exist | true  |

Then the test still passes, but setting the row to:
| Foo          | Does Not Exist | false |

Will cause the test to fail.
This behavior isn't documented in the wiki.
What do the different field values (true, false, and empty) for the Does Not Exist validation rule imply?

Changing that row to

| Foo1          | Does Not Exist |       |

Will still cause the test to pass even though the Foo1 property isn't defined in the CreateCoursePage model.
In this case, I expected the following exception:
SpecBind.Pages.ElementExecuteException: Could not locate property 'foo1' on page CreateCoursePage. Available Fields:
Department
Description
Number
Popular
CourseTitle
Foo

Thank you.

Can't speak to why it was initially commented out, my guess is that I was having issues with the wait routine and I never enabled it after resolving the issue.
I never tested Does Not Exist in true/false states because I always assumed the state would be true given that I have an Exists qualifier. However, the logic does treat true/false as a value here and parse it. I would propose removing that evaluation it so it remains blank.
The logic in ValidateItemAction treats DoesNotExist as a special case and ignores the missing property. Based on the way you describe it above, I would agree that it should not treat a missing property as an allowed case.
A friendly general note, this is an open source project so documentation is more of a guide than a complete functional reference.


Stator is inadvertently communicating with defederated domains?

As a member of a visible minority, the first thing I did with my instance was to insert the 400 or so instances on the Oliphant Tier0 list into the users.domain model as Blocked. I consider this SOP for any Fedi instance deployment. (Side note: it'd be nice if I could import block lists on the web interface, or even to pre-emptively add blocked domains without messing with Django scripting.)
Yet I think my instance is still announcing itself to those blocked instances when the stator tries to fetch instance information from it.
$ sudo docker logs -t worker 2>&1 | grep genderheretics
2023-07-06T05:32:58.685628856Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-07T05:33:06.614091697Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-07T05:33:07.195333279Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-08T05:33:17.637618935Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-08T05:33:19.152528304Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-09T05:33:27.694674737Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-09T05:33:28.264756791Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-10T05:33:44.685896184Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-10T05:33:46.373056364Z Attempting transition on users.domain#genderheretics.xyz from state outdated
2023-07-11T05:34:11.901867475Z Attempting transition on users.domain#genderheretics.xyz from state updated
2023-07-11T05:34:12.429001795Z Attempting transition on users.domain#genderheretics.xyz from state outdated

This feels less than ideal: if the admin of that instance trawls through their webserver logs (they do), they're going to find periodic proof that my server exists.
I wonder if there's an argument for not attempting a state transition on users.Domain objects that have blocked = true, or having a dedicated blocked state so that our instance doesn't try to talk to that server.
What does everyone think?

Ah yes, you're totally right, we should not be doing outgoing requests to them at all - I must have overlooked the "is the remote server alive" check when adding the blocking code.
I can fix that and I'll look into it as soon as I can, but we also have the option of entirely blocking even outbound calls to anything under the domain and making it an error - maybe that would be good as a backup. I can't think of anything you'd want to do with a blocked domain that would be stopped by that.

About the blocklist, I was following the discussion this weekend and thought the same. I'll prepare a PR adding the import feature 🙂

Yeah, especially as it seems like there's an effort to have a common block list format, which I'd like to support.

Agree that if I've defederated example.com, this should extend to sub.example.com and sub.sub.example.com and so on automatically, to prevent playing whack-a-mole with bad actors spinning up subdomains, and to prevent fork-bomb DoS attacks like we saw *.misskey-forkbomb.cf do in 2022. This is also how Mastodon does defederation so it should satisfy the principle of least surprise.

I've fixed the immediate bug here which was poking blocked servers periodically as part of the "are they alive" check - I'll go see if I can make blocking function for subdomains too. That's going to be a little harder to do efficiently as "query for right substring" is not something we have an index for, but I suspect I know how to do it.

Alright, recursive blocking of subdomains is also in (for reference, any blocked domain that tries to send Takahē any content will be told it was successful, but it's just thrown away instead).