Header responsive

Responsive navigation bar.
We need to apply submenus to responsive design.
This should be independent issue because its not just home


Base annotations and code for working with schemas

Add a @GeneratesSchema annotation that can be used to annotate a type for which a schema should be generated, and a GeneratesSchema util class that can be used to find all classes with the annotation on the module or class path.

Coverage increased (+0.04%) to 99.329% when pulling b9c5a3bfb826552d3d898e2c12a6cb73d5307fa8 on schema into 9523e40049749c68ede8dd93dfbdf990f88f11fd on main.


Remove Quickstart installation doc

Remove Quickstart installation doc in 1.7 and 1.8
Remove related references throughout all docs in 1.7 and 1.8
Update menu accordingly

closes #2824


Crucible | Update possible responses received from KVM Force Power On System

Test-Hints: assisted-abi
While testing https://github.com/redhatci/ansible-collection-redhatci-ocp/pull/92 in a disconnected environment, we observed we needed to retrieve more successful responses for this task, according to the Redfish API.

CC @tkrishtop

I don't get the point of the failure in the Pull Request / Ansible-lint Check (pull_request), since it's complaining about code that is not being changed in this PR. I suppose that, after a green job, it should be fine to merge this.

@ramperher if you want to move the commits from one PR to another, it's better to use git cherry-pick comment_hash to avoid merge conflicts and to keep the author. Thanks.

Wow, I was not aware of this, thanks for the recommendation. I've applied that and now your commit from the other PR is in this one, then I've corrected what was required, regarding the URL.

@ramperher if you want to move the commits from one PR to another, it's better to use git cherry-pick comment_hash to avoid merge conflicts and to keep the author. Thanks.

Wow, I was not aware of this, thanks for the recommendation. I've applied that and now your commit from the other PR is in this one, then I've corrected what was required, regarding the URL.

Let's do git revert fd97ce740ebea5b49d425b7c64aacffc67fd1cba as well. Currently, this commit is modifying the same line in priority and may produce a merge conflict: https://github.com/redhatci/ansible-collection-redhatci-ocp/pull/115/commits/fd97ce740ebea5b49d425b7c64aacffc67fd1cba

@ramperher if you want to move the commits from one PR to another, it's better to use git cherry-pick comment_hash to avoid merge conflicts and to keep the author. Thanks.

Wow, I was not aware of this, thanks for the recommendation. I've applied that and now your commit from the other PR is in this one, then I've corrected what was required, regarding the URL.

Let's do git revert fd97ce740ebea5b49d425b7c64aacffc67fd1cba as well. Currently, this commit is modifying the same line in priority and may produce a merge conflict: fd97ce7

Done

Change is working and it's ready for review, CC @tkrishtop and @nocturnalastro


Ability to Set Proxied for the DNS Records

I have changed the Register DNS function to take into account the proxied value as in the API Docs for Cloudflare V4: https://api.cloudflare.com/#dns-records-for-a-zone-create-dns-record
The default value is false
This allows the user to set this option: https://www.evernote.com/l/ACG89DKViupBHrVANIEUOdpateaKQj8lKb4

Coverage decreased (-10.1%) to 89.864% when pulling d49fec25714e9e290392bd03e6591674401d8160 on joinmonday:master into 057f798d4bb29aa3f4a4d2566d8fdf6b436c88d2 on peertransfer:master.

Coverage decreased (-10.1%) to 89.864% when pulling d49fec25714e9e290392bd03e6591674401d8160 on joinmonday:master into 057f798d4bb29aa3f4a4d2566d8fdf6b436c88d2 on peertransfer:master.

Are you planning to add a unit or integration test?

Oh! Sorry, I finally managed to do it directly with the API. Thanks!


Add more normalisation methods

Include more methods of normalisation

[ ] Change name of normalisation procedures
[ ] Change 'norm' argument in renormalise_sum
[ ] robust scaling (uses IQR instead of range from min-max scaling)
[ ] log transformation

Not sure anymore what is actually wanted here.
Most likely that we want to convert normalisation into preprocessing layers like Keras: https://keras.io/api/layers/preprocessing_layers/

Resizing Layer
Rescaling Layer
Normalisation Layer
Logarithmic Layer
Discretisation Layer

In the current form, we would need a layer for each dimensionality.
It'd be best if we just converted these ones into using rank 2 data (num_features, batch_size) and then, for get_output and get_gradient, we passed the rank that was assumed. It is meant to be a preprocessing layer, after all, so could just assume rank 2 and have it always feed into input1d_layer_type.
As other layers no longer take in assumed shapes, we should be able to handle this fine with mismatched ranks.


[Hold for design/marketing approval] Moderation Help Article

@jliexpensify and @shawnborton please review for visuals and content!
Details

Adds info about moderation to our help docs
Fixed Issues

$ https://github.com/Expensify/Expensify/issues/281503
Tests

None

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

Offline tests

QA Steps

No QA

[ ] Verify that no errors appear in the JS console

PR Author Checklist

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@jliexpensify I modified the screenshots slightly but I think this works. I also added one sentence to clarify that you get a whisper when you flag a piece of comment as well as if you are flagged.
Let me know what you think  (screenshots in description)
Also @shawnborton lemme know if you see anything that you'd like to fix. Thanks!

I think it looks good @dangrous - the only thing I noticed was the border around the phone:

@shawnborton might have some thoughts, but I personally think it's a little jarring - I think removing the shadow around the phone would look better.
Also, it looks like these corners are sharp, compared to the 4th which is rounded: does that need to be fixed?

Ha yes those are my poor image combining skills - maybe @shawnborton would have a moment to fix them? The rounded vs. straight corners is simply because that one rounded one is an app edge, and the others are me cropping the screenshot.
There's probably a nicer way to do this

Yeah, it will be nice to standardize on how we mock up phone + chat room content. So perhaps I just need to get you a better mockup for this one and we can go from there?

That would be lovely @shawnborton! Let me know if I can help at all.
Also to note - right now there isn't a super clean version to put two images on the same line in the help docs, so that's why (you can see in the PR) I combined them into one. Another consideration for the mockups!

Cool, I can come up with a way to display both at the same time.

Hey @shawnborton I know you're busy with a lot of other projects (and this is pretty lo pri) but lemme know when you've got the new assets and I can update!

My bad, I should be able to get this to you today!

Could something clean like this work?

Looks great Shawn!

That looks lovely!

How do you feel about the other two images? One is a full screenshot (probably fine unless we want to crop or restyle?) and the other's another kinda bad double image.

I think for consistency's sake, they should mirror what @shawnborton has done with the other images

Agree, happy to add the border to them so they look similar. Can you provide the raw screenshots and I can resize/adjust from there?

Here are the two whisper screenshots:

And here's the Flag Comment page one, just in case:

Let me know if these work:

Top one is lovely! For the bottom two, we're only really interested in the chat portion, or even - if we drill down more - the Concierge message itself. Would it make sense to crop those in even more?

Ah fair, something like this then?

ah, perfect! I'll use these ones (unless GH downrezzes them but I don't think so?)
Thanks for the assist!

Updated to use new images!
I also found a bug where in Firefox these images display way too large (cut off on the right) so I fixed that here and in the other page that uses large screenshots like this.

Bump for review when you have a moment, @eVoloshchak!

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

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

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

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

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

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

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

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

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

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

Are the images supposed to be visible on GitHub? Here's how it looks in browser and vscode preview

@dangrous, are the images supposed to be visible on GitHub? Here's how it looks in browser and vscode preview

Yes sorry to test it you'll have to change it to http://localhost:4000/assets/images/moderation-context-menu.png or whatever your local version is hosted at. It can't pull the images from the real links yet because they don't exist!

Yes sorry to test it you'll have to change it to http://localhost:4000/assets/images/moderation-context-menu.png or whatever your local version is hosted at. It can't pull the images from the real links yet because they don't exist!

@dangrous, they do open in browser, looks like they exist

t can't pull the images from the real links yet because they don't exist!

Ah, I see now, thank you!

Let me know if you're still having trouble @eVoloshchak !

@dangrous, the GitHub preview is still displaying the width tag

Same for the preview in Vscode
What should I be using to test this?

Yeah I don't think the markdown previews on their own will show correctly - you'll need to follow the instructions here to set it up locally - https://github.com/Expensify/App/blob/main/docs/README.md - (and then change those image URLS to http://localhost:4000). Let me know if that works!

@dangrous, thank you, all working and looking good now
Apologies for the delay, Jekyll turned out to be interesting to set up

Hmm, the screenshots aren't super visible on mobile but I guess since the user can probably open up the image in a new tab, it should be fine? What do you think, @shawnborton?

I also don't mind just getting this out and optimizing at a later date.

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

🚀 Deployed to staging by https://github.com/MariaHCD in version: 1.3.54-0 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/MariaHCD in version: 1.3.54-0 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/yuwenmemon in version: 1.3.54-13 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Puppeteer 3.3.0 and Firefox Nightly 79: response.text() never completes

Steps to reproduce
Tell us about your environment:

Puppeteer version: 3.3.0
Platform / OS version: Windows 10
Node.js version: 14.4.0

What steps will reproduce the problem?
Navigate to a page and try to extract the response text.
Please include code that reproduces the issue.
const browser = await puppeteer.launch({
                product: 'firefox',
                headless: false,
                devtools: false,
                ignoreHTTPSErrors: true,
                args: ['-wait-for-browser'],
                dumpio: true,
                extraPrefs: {
                    'remote.log.level': 'Trace',
                },
            });

const page = await browser.newPage();
const response = await page.goto('https://www.google.com/');
const text = await response .text();

What is the expected result?
Get the response text.
What happens instead?
response.text never completes, hanging the browser.

Connection never receives (hence never fires) the Network.loadingFinished (or, for that matter, requestFinished) event, so the NetworkManager never resolves the Response content

I traced it back to the Firefox code;
the NetworkObserver fires the events, is passed to the Network Domain through a Session, but the Network Domain only listens to the "request" and "response" events, hence only forwards those

In Addition, the Network Domain doesn't seem to be set up to handle the Network.getResponseBody event

CC @mjzffr @whimboo in case this is useful to dig into.

Thanks for the report. Some of the relevant work in Mozilla's protocol implementation is tracked at:

https://bugzilla.mozilla.org/show_bug.cgi?id=1590201
https://bugzilla.mozilla.org/show_bug.cgi?id=1549510

The Network domain is high on our priority list.

It seems to hang as well when using functions like
await page.goto(this.url, {waitUntil: 'networkidle2'})

Yes, we do not support networkidle2 nor networkidle0 yet.

Closing issue for now given that the underlying network events as necessary to fulfill the request on this isse will most likely not be implemented in our partial CDP protocol in Firefox.


rez-build breaks if "|" in a required package's version on Windows

The | "or" feature in https://github.com/nerdvegas/rez/wiki/Basic-Concepts#package-requests does not work on Windows 10, Rez 2.26.1. Specifically, this syntax resolves a context correctly but raises an error whenever I try to rez-build a package:
requires = [
    'package_a==|>=0.1',
]

If I have two rez packages, package_a and package_b
And their files look like this:
package_a/package.py
name = 'package_a'

version = '0.1.0'

build_command = 'python {root}/rezbuild.py {install}'

def commands():
    pass

package_b/package.py
name = 'package_b'

version = '0.1.0'

build_command = 'python {root}/rezbuild.py {install}'

requires = [
    'package_a==|>=0.1',
]

def commands():
    pass

And both packages have a rezbuild.py file that looks like this:
#!/usr/bin/env python
# -*- coding: utf-8 -*-

# IMPORT STANDARD LIBRARIES
import sys
import os

def build(source_path, build_path, install_path, targets):
    pass

if __name__ == '__main__':
    build(
        source_path=os.environ['REZ_BUILD_SOURCE_PATH'],
        build_path=os.environ['REZ_BUILD_PATH'],
        install_path=os.environ['REZ_BUILD_INSTALL_PATH'],
        targets=sys.argv[1:],
    )

If I run rez-build while cd'ed into package_b on Linux, it builds correctly with no issue. This same setup fails on Windows with the error '0.1+' is not recognized as an internal or external command, operable program or batch file. I've tried a few variations and they all seem to have the same issue. The package is resolved correctly but breaks once it tries to run the build system. It looks like rez-build is interpreting the | as a separator for a command and 0.1 as a literal Windows command.
Here is a .zip of the two Rez packages which can be used to reproduce the error and the full output log of the rez-build command I ran:
rez_release_test.zip
rez_build_windows_command_error.txt

I changed escape_string so that it accounts for | with double quotes and I am now able to use rez-env and rez-release again as normal.

Just ran into this myself, what did you change it to @ColinKennedy?
Here's the current version, my regular expression-fu is too weak.
https://github.com/nerdvegas/rez/blob/3a5afd86dbf88801a44d2fc4f828140ef1be6b34/src/rezplugins/shell/cmd.py#L27-L28

Hey @mottosso
My solution was hacky so I don't recommend it for production code. It was a temp fix. That said, I haven't needed to use Rez on Windows for a while so this may not still work.
https://github.com/ColinKennedy/rez/commit/f0e0556e0bfe2728be7db943f5b9516c3f813019

Thanks @ColinKennedy, that does work, but yes it's unfortunate it's a second parsing step rather than part of the regular expression itself. I managed to find a regular expression for it and made a PR here: #558


Set default codepage UTF-8

I'm playing with Windows Nano Servers and it seems that Nano only supports codepage UTF-8.
After changing the codepage from 437 to 65001 I can use this command to communicate with such a Nano Server.
Equivalent change for Ruby https://github.com/WinRb/WinRM/pull/130
More details about Nano Server and having a packer template can be found in this blog post: http://www.hurryupandwait.io/blog/a-packer-template-for-windows-nano-server-weighing-300mb

@masterzen I have rebased the PR.

Hi,
Many thanks for your submission which apparently I completely forgot to review (sorry!) when you sent it.
It looks good, but would you mind adding a small explanation in the commit message about why we need this change (I know it's in the PR, but when looking at git history later it would be easier to understand why we needed this change).
Thanks!
Brice

No problem! I've updated the commit message.

Looks perfect, merging. Thanks!


[Feature Request] Specify custom keyword arguments for eval environments

🚀 Feature
Add the --eval-env-kwargs parameter to the train.py script in order to specify keyword arguments to pass to the env constructor for evaluation.
Motivation
Actually, we cannot specify different keyword arguments between training and evaluation environments. It can be usefull if we want  the evaluation environment to behave differently from the training one.
Pitch
No response
Alternatives
No response
Additional context
You can see the usage in this commit.
Checklist

[X] I have checked that there is no similar issue in the repo

Hello,
Sounds like a good to have feature, i would be happy to receive a PR for it =) (the default should remain the same though)

Hello,
OK thanks :ok_hand: ! Here is the PR : https://github.com/DLR-RM/rl-baselines3-zoo/pull/405


Repo sync for protected CLA branch

The pull request is created from master637332079343803033 to master to fix git push error for protected CLA branch

@tfosmark : Thanks for your contribution! The author(s) have been notified to review your proposed change.


[Feature Request]: Replace the utls library refraction-networking/utls

Describe the feature / enhancement and how it would improve things
Hi,
I can see the reasoning why you maintain your own utls library but as time changes since you started this excellent project refraction-networking/utls project is also grown and become a very solid library, it is actively maintained and used by many other great projects. Wouldn't it be better to use this library instead of carrying the burden of yours? So you can have more time to focus the client part.
Describe how your proposal will work, with code and/or pseudo-code
Since they are both derived from tls libary it can be used as a drop-in replacement.

@3ldar the main reason for forking the utls package and maintaining it was to be able to pass client profiles from the outside into the utls package in addition with a few other changes.
i get your point but i think it is better for us that i try to regullary sync my utls fork with the originals utls package to have all the latest changes in addition to my custom adjustments.


Shaman and Paladin buffing issues

Shaman will only buff champion.  Will not buff Focus.
Paladin will not buff Brell's Stalwart Shield.

pushed an update for shaman buff lines.
i don't see any issues with the shm proc buffs with my toons.
my pally seems to cast brells too.

I'm not sure what to say.  It's very frustrating.

Still only casted Champion.

under console flags turn on ability validation. its gonna spam a lot. but it likely has some info about if its at least going into trying to cast it.

And then it spams this:

So a group check needs to be in place to cast or consider buffing panther.

Paladin is looking for

So they both are not memming the spells needed.

hm strange. for me it looks like

i did run into something else on my shaman though where when it mem'd talisman of wunshi to buff itself (not buff beg), it just kept casting it in a loop. think i fixed that.. maybe get lucky and it happens to relate to your issue too.

So on my beastlord the loop is not being able to mem spells it wants to cast.  I will download the latest and give it a try.
Not sure why it's broken for me and not for you, will test and confirm the results here.

Ok so it did not correct it, I still get the spam of not being able to mem the spell.  To work around it I just use BYOS and make sure the buffs needed are always memmed.
That being said, I am using the RG mq2 emu build.  Are there any plugins I possibly need that aren't loaded?  I can get a list of the plugins i have for you to look at to see if any are missing that are needed.

I have this being spit out by shaman, I clicked off sloth on monk, shaman buffed monk then spits out this Enter and Exit spam in the console.

you got any weird custom ui that wouldn't report properly that spell window is opening or anything else that might throw it off like that?


Force new users to confirm their emails

Reviewing the user accounts, it appears that many accounts use fictitious email addresses (e.g. example@example.com). In order to reduce (or possibly eliminate) the number of fictitious email addresses specified, we should have new users confirm their addresses before activating their accounts.
I believe that the best way to do this would be to use Devise's confirmable module.

😢 it's for the best


Fix typo in Dockerfile

:tada: This PR is included in version 1.2.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Added note for user to create local project

Added note for user to install npm package dotenv when having local project.
Checklist:

[x ] I have read freeCodeCamp's contribution guidelines.
[x ] My pull request has a descriptive title (not a vague title like Update index.md)
[x ] My pull request targets the master branch of freeCodeCamp.
[x ] All the files I changed are in the same world language, for example: only English changes, or only Chinese changes, etc.

Closes #39765

@Ventuscoder We are still discussing the issue you have referenced here and have not come to a consensus on what the final wording should be.  Once we do, you may need to update your PR to incorporate those changes.

Okay. Thanks!

@Ventuscoder Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it.
Reason: We have concluded a different change is needed.  You can review the original issue and see the last comments for the changes needed.
We would welcome future pull requests from you.
Thank you and happy coding.

@Ventuscoder Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it.
Reason: We have concluded a different change is needed.  You can review the original issue and see the last comments for the changes needed.
We would welcome future pull requests from you.
Thank you and happy coding.


Inpainting not using prompt

Inpainting seems to completely ignore the prompt and instead do img2img for the mask. Anybody else have the same problem?
It might have something to do with the updated comfyui, but I am not sure. I also read in a previous issue that inpainting only worked for base 1:1 (I tried it on 9:16), but the issue was resolved.

I have the same issue .... Prompt gets completly ignored


group by pod

Hey is there any chance to group the report so i dont get a bunch of messages to slack, like summery group by image
or do it on the ui to group by image ?

Grouping via Slack is not really possible. To see a grouped view, I would suggest using the UI, but grouping by resource is not currently available, but I could add it there.

thank you for the response, any chance to send alert to slack when new report is scan only with a link to the ui maybe ?

thank you for your help, i will appreciate if you add it to your tickets

As feature for the upcomming major release I am started working the general support for targets and a first implementation for Slack.
Any feedback is welcome.


Wrong request will lead to empty technical messages types

Fixed. There will be a validation error in this case.


[SPARK-5205][Streaming]:Inconsistent behaviour between Streaming job and others, when click kill link in WebUI

The "kill" link is used to kill a stage in job. It works in any kinds of Spark job but Spark Streaming. To be specific, we can only kill the stage which is used to run "Receiver", but not kill the "Receivers". Well, the stage can be killed and cleaned from the ui, but the receivers are still alive and receiving data. I think it dose not fit with the common sense. IMHO, killing the "receiver" stage means kill the "receivers" and stopping receiving data.

Test build #25882 has started for   PR 4135 at commit c90a288.

This patch merges cleanly.

Test build #25882 has finished for   PR 4135 at commit c90a288.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait TaskKilledListener extends EventListener
class TaskKilledListenerException(errorMessages: Seq[String]) extends Exception

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/25882/
Test FAILed.

Test build #25884 has started for   PR 4135 at commit fc3be2c.

This patch merges cleanly.

Test build #25884 has finished for   PR 4135 at commit fc3be2c.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/25884/
Test FAILed.

Test build #25886 has started for   PR 4135 at commit d85dede.

This patch merges cleanly.

Test build #25886 has finished for   PR 4135 at commit d85dede.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait TaskKilledListener extends EventListener
class TaskKilledListenerException(errorMessages: Seq[String]) extends Exception

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/25886/
Test PASSed.

@pwendell This should be a good addition to TaskContext, take a look.

Test build #26585 has started for   PR 4135 at commit f316261.

This patch merges cleanly.

Test build #26585 has finished for   PR 4135 at commit f316261.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/26585/
Test PASSed.

@JoshRosen Could you please take a look again, thank you.

Test build #28156 has started for   PR 4135 at commit 047931c.

This patch merges cleanly.

@JoshRosen Could you please take a look again, thank you!

Test build #28156 has finished for   PR 4135 at commit 047931c.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait TaskKilledListener extends EventListener
class TaskKilledListenerException(errorMessages: Seq[String]) extends Exception

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28156/
Test PASSed.

@pwendell Could you please take a look again, thank you!

Jenkins, retest this please.

Test build #28374 has started for   PR 4135 at commit 047931c.

This patch merges cleanly.

I think we discussed this on the first PR, but it would be good to add an explicit note here summarizing why we're not using TaskCompletionListener, since its documentation says that it's called on all task completion events, including success, failure, or cancellation.

  If this works, then this patch becomes a two-line change to ReceiverTracker.scala:
context.addTaskCompletionListener { context =>
  if (context.isInterrupted()) {
    supervisor.stop("Receiver was killed.", None)
  }
}

Can you try using the existing addTaskCompletionListener with context.isInterrupted(), roll back the other changes / listener interfaces, and add a streaming unit test for this receiver cancellation behavior?

Test build #28374 has finished for   PR 4135 at commit 047931c.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait TaskKilledListener extends EventListener
class TaskKilledListenerException(errorMessages: Seq[String]) extends Exception

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28374/
Test PASSed.

Test build #28421 has started for   PR 4135 at commit 963556d.

This patch merges cleanly.

Test build #28422 has started for   PR 4135 at commit f997698.

This patch merges cleanly.

Test build #28421 has finished for   PR 4135 at commit 963556d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28421/
Test FAILed.

Test build #28422 timed out     for PR 4135 at commit f997698     after a configured wait of 120m.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28422/
Test FAILed.

retest this please

Test build #28423 has started for   PR 4135 at commit f997698.

This patch merges cleanly.

Test build #28423 timed out     for PR 4135 at commit f997698     after a configured wait of 120m.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28423/
Test FAILed.

Some timeout errors happened. Could you please take a time to check and review it again?

Test build #28426 has started for   PR 4135 at commit 7051184.

This patch merges cleanly.

Test build #28426 has finished for   PR 4135 at commit 7051184.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28426/
Test FAILed.

retest this please

Test build #28459 has started for   PR 4135 at commit 7051184.

This patch merges cleanly.

Test build #28459 timed out     for PR 4135 at commit 7051184     after a configured wait of 120m.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28459/
Test FAILed.

Test build #28510 has started for   PR 4135 at commit 92fb864.

This patch merges cleanly.

Test build #28510 has finished for   PR 4135 at commit 92fb864.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28510/
Test FAILed.

Test build #28511 has started for   PR 4135 at commit fe3e5d5.

This patch merges cleanly.

Test build #28512 has started for   PR 4135 at commit fb9716d.

This patch merges cleanly.

Test build #28511 has finished for   PR 4135 at commit fe3e5d5.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28511/
Test FAILed.

@JoshRosen, thanks for your patience. It occurred to me that we may check when to terminate the receiver in ReceiverSupervisor. Then the condition to stop the receiver is satisfied when TaskContext.isInterrupted() or isReceiverStopped. So I removed the stopLatch lock and just checkTermination() once per 500ms.
Now, we may just mark the task for interruption and trigger callback processing inside of markTaskCompleted.

Test build #28513 has started for   PR 4135 at commit 02bf9a9.

This patch merges cleanly.

Test build #28512 has finished for   PR 4135 at commit fb9716d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28512/
Test FAILed.

Test build #28513 has finished for   PR 4135 at commit 02bf9a9.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28513/
Test FAILed.

Test build #28514 has started for   PR 4135 at commit 2bac656.

This patch merges cleanly.

Test build #28514 has finished for   PR 4135 at commit 2bac656.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28514/
Test PASSed.

I chatted with @tdas about this and I think we've arrived at a better understanding of this problem:

The onTaskCompletion approach that I suggested will not work because that callback will only be invoked after the task has finished running, but the task will not be able to finish until we stop the receiver.
We could modify the receiver to respond to TaskContext.isInterrupted(), but the current implementation here isn't ideal since it involves busy-looping.

It sounds like your original approach of adding a new callback on interruption is the right fix, since that callback can just call Receiver.stop() and we can continue to use the countdown latch to avoid polling / busy-waiting.  However, I think that the original name for the callback was misleading / confusing, which led me onto this derail: the name addTaskKilledListener is confusing because it sounds like it would be subsumed by onCompleteCallback.  Besides this naming confusion, though, I think the original approach is actually fine.
Therefore, my suggestion is to keep the unit tests that you've added (which look good to me) and revert back to the onKilledCallback approach, but change the name to be addTaskInterruptionListener.  Because the existing methods / naming was confusing, it might also be nice to add a state transition diagram somewhere which explains the order in which the callbacks are invoked (or some much more explicit comments).
Sorry for the derail and thanks for being patient with me!

@JoshRosen OK, I will roll back to the original approach and do some impromvements :)

close and resolve the merge conflict.

Test build #28723 has started for   PR 4135 at commit b5237d8.

This patch merges cleanly.

Test build #28723 has finished for   PR 4135 at commit b5237d8.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait TaskInterruptionListener extends EventListener
class TaskInterruptionListenerException(errorMessages: Seq[String]) extends Exception

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28723/
Test FAILed.

Test build #28765 has started for   PR 4135 at commit 96f2182.

This patch merges cleanly.

Test build #28765 has finished for   PR 4135 at commit 96f2182.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait TaskInterruptionListener extends EventListener
class TaskInterruptionListenerException(errorMessages: Seq[String]) extends Exception

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28765/
Test PASSed.

@JoshRosen Could you please take a look again, thank you!

Test build #28788 has started for   PR 4135 at commit b2916fb.

This patch merges cleanly.

Test build #28788 has finished for   PR 4135 at commit b2916fb.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait TaskInterruptionListener extends EventListener
class TaskInterruptionListenerException(errorMessages: Seq[String]) extends Exception

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28788/
Test PASSed.

I left a pass of comments, mostly about naming / documentation things.  The overall approach looks good, but I'm not sure if this is the right / best unit test for this logic because the test harness seems to duplicate most of the logic being tested.  I'll let @tdas chime in regarding tests.

Any update on this?  This patch looked good to me overall; the main thrust of my feedback was that the tests here didn't seem sufficient to actually exercise the code added in this patch, but I think that shouldn't be too hard to fix.

@JoshRosen Sorry for my laziness. I will update it as soon as possible

@uncleGen No worries; I'm not in a huge rush, but just wanted to check in to see if you planned to update this.  Sorry that the review process has been so slow; thanks for your patience!

Test build #29461 has started for   PR 4135 at commit e6724ec.

Test build #29461 has finished for   PR 4135 at commit e6724ec.

This patch fails MiMa tests.

This patch merges cleanly.

This patch adds the following public classes (experimental):

trait TaskInterruptionListener extends EventListener

class TaskInterruptionListenerException(errorMessages: Seq[String]) extends Exception

class UDFRegistration(object):

This patch does not change any dependencies.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/29461/
Test FAILed.

@JoshRosen Your comments are reasonable, and I have improved related code just as what you pointed. For the test suite, I just check if the state of Receiver and ReceiverSupervisor are correct. In the previous way, killing task could not stop Receiver and ReceiverSupervisor properly. I think it is enough. @tdas, what is your opinion?

Test build #29469 has started for   PR 4135 at commit e26a207.

Test build #29469 has finished for   PR 4135 at commit e26a207.

This patch fails MiMa tests.

This patch merges cleanly.

This patch adds the following public classes (experimental):

trait TaskInterruptionListener extends EventListener

class TaskInterruptionListenerException(errorMessages: Seq[String]) extends Exception

This patch does not change any dependencies.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/29469/
Test FAILed.

wait for a moment

Test build #29478 has started for   PR 4135 at commit 3a68742.

Test build #29478 has finished for   PR 4135 at commit 3a68742.

This patch passes all tests.

This patch merges cleanly.

This patch adds the following public classes (experimental):

trait TaskInterruptionListener extends EventListener

class TaskInterruptionListenerException(errorMessages: Seq[String]) extends Exception

This patch does not change any dependencies.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/29478/
Test PASSed.

@JoshRosen Your comments are reasonable, and I have improved the relevant codes just what you pointed. And more, I add some unit tests about the  behavior about TaskInterruptionListener. In the same time, I left some unit test in ReceiverSuite to test the behavior about Receiver and ReceiverSupervisor. Maybe, @tdas has some suggestions.

Test build #29784 has started for   PR 4135 at commit debfbac.

Test build #29784 has finished for   PR 4135 at commit debfbac.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/29784/
Test PASSed.

Ha~llo~, @JoshRosen

On closer inspection, my previous comment about testing still stands

I notice that this test harness the logic from the real receiver tracker. Is this test suite actually covering the changes made to ReceiverTracker? In other words, if I were to go in and delete the callback registration code that you added to the real tracker, would that cause any tests to fail? If not, then I think we need to do additional work to test this, since the test isn't really testing anything if it can't expose bugs in the real code.

It seems like we'd like to test against a real ReceiverTracker using mock implementations of ReceiverSupervisor and Receiver. I'm not super-familiar with this corner of the streaming code, though, so maybe @tdas can chime in with suggestions on how to test this?

Since the changes in this patch modify ReceiverTracker, it makes sense to test the actual ReceiverTracker while mocking other components.  The updated test still doesn't exercise the real receiver tracker and thus isn't actually covering the streaming changes in this patch.
I understand that properly testing ReceiverTracker might not be the easiest test to write, so perhaps this would require refactoring of ReceiverTracker to make the individual components more testable.  I'll let @tdas chime in to decide on the importance of writing a real test for this.  Sorry to be pedantic, but I'm a bit of a stickler for the importance of writing tests that actually exercise the code being modified, since I think it's very rare that it's truly impossible to test changes like this.

@JoshRosen Thanks for your careful and responsible review. I will hold this PR and wait for @tdas 's suggestions

@tdas @uncleGen any updates? If not, I would recommend that we close this PR for now and reopen it later if there is more activity.


img crop + rotate

do you have any support for image rotation (e.g. rotate 90 deg left/right) ? It seems to me adding css for rotation will ruin the codes for cropping.

@alexk111 : do you have any support for auto-rotation? Right now I can crop the image but don't see it getting rotated on its own? Is there any alternative for same?

This codepen gave me help needed :
https://codepen.io/HugeHugh/pen/NRgmWm
for future


Media queries don't work on react-native-web components

Hi I'm developing an app and website in the same project and sharing almost a 100% code. I'd like to use styled components for style, but it doesn't allow me to use media queries on react native components on web why is that?
I'm developing mobile first so I don't actually need de queries for the react native app. And since react-native-web converts a View into a Div I see no reasons why my media queries don't apply.
Example:
const Content = styled.View`
  background: papayawhip;
  height: 3em;
  width: 3em;

  @media (min-width: 700px) {
    background: palevioletred;
  }
`;

In react native i expect this to just ignore the media query but on web it should put the media query on the div.
Is this possible?

React Native has no concept of media queries and we use the RN version of styled-components in this case, so yeah it just wouldn't work. Other stylesheet targets have been proposed though to improve the situation if you're interested in joining the conversation: https://github.com/styled-components/styled-components/issues/1874

@tychovbh media queries don't make sense in React Native's strict component model. Instead, you can essentially do "element queries" by using the onLayout prop to respond to changes in your component's dimensions, or listen to window size changes using the Dimensions API. This is how all the responsive design is accomplished in Twitter's PWA

@necolas is this still the case? Are you still relying on onLayout and Dimensions to get responsiveness in both mobile and web platforms? Thanks.


Remove assignment to variable as the value is never used

Breaking change

Proposed change

Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New integration (thank you!)
[ ] New feature (which adds functionality to an existing integration)
[ ] Deprecation (breaking change to happen in the future)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:

Checklist

[ ] The code change is tested and works locally.
[ ] Local tests pass. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.
[ ] I have followed the development checklist
[ ] I have followed the perfect PR recommendations
[ ] The code has been formatted using Black (black --fast homeassistant tests)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
[ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
[ ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

[ ] I have reviewed two other open pull requests in this repository.

Description:
Code Smell:Remove assignment to variable as the value is never used.
Motivation:Code with unused variables creates confusion and difficult to maintain. They serve no use and may cause confusion in other readers of our code. We should remove these unused local variables in order to simplify your code and reduce errors.I removed unused local variable old_ids in the code and it makes easy to read and maintain the code.

looks good


[Levelup] Roles description "del" is Assign a role to a level

A small text alteration request, though not exactly a bug >_>
add Assign a role to a level
autoremove Automatic removal of previous level roles
del Assign a role to a level <----
initialize Initialize level roles
I assume "del" should be something like deleting a role from a level

This typo has been fixed, thank you for reporting it


Release 0.6.3

Making a new release - last one is 3 weeks ago.

Codecov Report

Merging #2705 (2ea5388) into main (fec10eb) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2705      +/-   ##
==========================================
+ Coverage   81.15%   81.18%   +0.02%
==========================================
  Files          51       52       +1
  Lines        5493     5500       +7
==========================================
+ Hits         4458     4465       +7
  Misses       1035     1035

Impacted Files
Coverage Δ

flax/version.py
100.00% <100.00%> (ø)

flax/__init__.py
100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Trouble using optim and mcmc in same project

I run into problems when I try to include optim.h and mcmc.h in the same cpp file.  I think it's happening because the #include guards in BaseMatrixOps.hpp prevent the inclusion of that code into the mcmc namespace isn mcmc_options.h.  Is there a way to fix this, short of refactoring a bunch of the library code?

This sounds like poor design on my part :) I'll come up with a fix. Thanks for flagging

Just pushed updates to all packages. Let me know if that doesn't fix it...


Expirable RCountDownLatch

Is there a reason that RCountDownLatch doesn't implement RExpirable? I'd like to be able to create a CountDownLatch that goes to 0 or is deleted if countDown isn't called the desired number of times before a timeout.

Then CountDownLatch reaches the 0 it publish a zeroCountMessage via pub\sub. During expiration same message should be published too. There is no way in Redis to schedule a publish operation.

I have the same question,
RCountDownLatch countDownLatch = redissonClient.getCountDownLatch(key);
        try {
            countDownLatch.trySetCount(1);
            // todo: I want to set the expiration time of the key here
            Thread.sleep(10000);
            boolean await = countDownLatch.await(10L, TimeUnit.SECONDS);
            return await + "";
        } catch (InterruptedException e) {
            e.printStackTrace();
        }


getting an Error: Could not extract signature deciphering actions

Here's a recent issue that I assume is about a breaking API change in YouTube's API which has impacted your core node-ytdl-core
https://github.com/fent/node-ytdl-core/issues/287

Oh sorry, you just fixed it! 🎉


Update component versions

LGTM, although we will need to figure out a way to update the docs automatically :(


Ruby SDK

Ruby SDK for the Minds API, providing similar functionality to the existing Python SDK:
This repo:  https://github.com/tungnt1203/minds_ruby_sdk

Issue https://github.com/mindsdb/minds_python_sdk/issues/22

Client class for API authentication and requests
Classes for managing Datasources and Minds
CRUD operations for resources
Mind completion support
Error handling

@quest-bot loot #22

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

I have read the CLA Document and I hereby sign the CLA

You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

I have read the CLA Document and I hereby sign the CLA

@ea-rus  can you please review this PR?

@ZoranPandovski updated


Cranelift: develop a generic lazy analysis framework using ISLE transfer/meet functions

As part of #4128, we should develop a lazy analysis framework that permits us to easily compute properties of CLIF values, operators, or program points between operators (depending on the analysis). This framework should accept pluggable lattice types, lattice meet functions, and transfer functions, ideally permitting these to be written in ISLE.
We should look into the following ideas:

Perhaps it is possible to avoid an iterative dataflow-analysis fixpoint by not supporting cyclic analysis at all. Many analyses can't say something meaningful about cycles anyway, at least when the cycle exists due to a non-redundant blockparam (i.e., actually multiple reaching definitions). If we stop at cycles (and immediately shortcut to the lattice "bottom" value), we can lazily go up the DAG of operators, memoizing analysis results per Value as we come back down.

Note that supporting fixpoint analysis of forward-dataflow properties is difficult with CLIF in any case because we don't have use-lists per Value, so we can't propagate forward unless we build that information on the side.

Perhaps it is possible to co-mingle the analysis with mutations performed by a mid-end optimization framework by either reasoning about invalidations, or else constraining rewrites in a pass of the appropriate direction (e.g., an analysis that "looks upward" and stops at cycles is always safe to lazily complete while doing a downward pass, as long as one sees defs before uses).

Yes, but it runs into the same problem with cycles whether we do it lazily (reaching backward on request) or eagerly (walking forward and evaluating for each new def): when we hit a blockparam, what do we do? Walking backward, we might recurse over the edge and find a cycle; we need a way to take some initial value, but remember to "come back" later (hence side-info). Walking forward, we have to plug in some initial value but again we need to record the loop and come back to it.
In other words I think that the supporting-cycles-with-fixpoint feature and the lazy-backward-or-eager-forward decision are orthogonal; the former requires additional info (esssentially, for us to reify the graph somehow so we can iterate over it) whether or not we do the latter.

I've done some initial prototyping work in this direction over the past week or so in this branch (somewhat misnamed isle-memoization as it's really an eager approach now):

Initially I tried to work out the scheme described here in more complete detail. I had wanted to build a fully lazy scheme to allow for "sparse facts": analyses that only need to look at a subset of values, rather than eagerly fill a table for every value, program point, or instruction.
The main difficulty I ran into was in avoiding unbounded (input-controlled) recursion while not completely rewriting the ISLE compiler. The straightforward way do to lazy memoized evaluation in ISLE is to add a bit to the start of a generated function body that checks a table and returns if memoized, and a bit at each return point to record the result. But if we recurse "up the function body" to compute a property down a dataflow chain, (i) this is not tail recursion, because we have to store the tuples on the way back down, and so (ii) we have unbounded stack growth, and the fuzzers will eat this for breakfast (i.e.: we can't do that).
One could in principle solve that by compiling to a form with an explicit stack instead. Basically, turn the ISLE code into a state machine with a stack. (Sound familiar @fitzgen? :-) ) But (i) I don't really think it's prudent to rewrite the ISLE compiler at this stage for dubious benefits and (ii) indeed I think there would be dubious benefits: the performance characteristics of an explicit "interpreter loop over FSM states" are much different than the 1-to-1 compilation strategy to Rust that we have today.

So then I began to work out an eager approach (roughly, Datalog-like rather than Prolog-like, for anyone familiar with both): scan the function top to bottom and evaluate an ISLE constructor at each {value, instruction, program point} (depending on analysis), filling a table in. That's what the branch linked above is.
The two major issues with this are:

There are relations/properties that really do want to be sparse. In developing alias analysis and redundant-loads (see branch), one ideally wants to build a map from (memory alias state, address SSA value, type) keys to known-value-stored-at-that-address values. We definitely do not want to scan that whole key-space eagerly.
There are possibly some ways around this by playing with the key and value definitions, but I started to realize I wanted tuple types in ISLE, and that is a whole other rabbithole I'd prefer to avoid...
And in general, I realized the following basic reality: ISLE is (so far, in today's state) not a general-enough language for analysis, together with: the kinds of optimizations we want to do in analyses to be efficient are a bit too general-purpose for a rigid term-rewriting worldview.

Said another way, I was pushing the design above in the direction of Prolog/Datalog because I know that these can be used for general and powerful program analysis (I've done it!) but there are additional tricks one does there that ISLE can't express.
In addition to that, on a more subjective level, I was starting to approach and slightly exceed my complexity-budget comfort level in that branch ("is this really better than hand-coding X...?").
So I think I want to conclude now, given the few weeks' experimentation here, that the analyses should not (yet) be in ISLE, though the mid-end rewrites can probably still be, as the language is explicitly a pattern-rewriting language now. In the fullness of time, we might be able to revisit this, and get the benefits (chiefly: fusing with lowering, and ability to formally verify analyses); but let's not force it before its time.
(I'll leave this issue open as an "enhancement" in the tracker to keep these ideas around for that future time!)

I think we can close this? We have a (Rust, not ISLE) framework with the recent e-graphs stuff.

Yes, I think so; we've found that the best balance of design concerns here lands at in-Rust analyses, but we have a general forward-direction analysis framework now, so I'll close this.


Compiled files do not work in webpack (problem with default exports)

Typescript compiles following
import React from "react";
const dom = React.DOM;

into following
var react_1 = require("react");
var dom = react_1.default.DOM;

Yet, this fails as "react_1.default" is undfined and DOM is directly part of "react_1". As a result it should be:
var react_1 = require("react");
var dom = react_1.DOM;

How can I make typescript work with reacts default exports? Thanks!
[EDIT] Doing import * as React from "react"; seems to resolve the issue, but it's a bit messy IMHO

`import * as React from "React" is actually the correct way to import React. The problem is that React's documentation only assumes that you are using Babel, and Babel performs a trick to load the default export if the module object has a certain flag on it (see #6296).
If you're piping through Babel (or SystemJS which I've heard also does this), you can use our --allowSyntheticDefaultImports flag so that TypeScript understands what the module loader is going to do.


use MOV immed instructions to load parameters

This enhances the mov-to-stack changes by adding optimizations to use the MOV immed instructions.

This is a significant performance optimization. Please pull sooner, not later, so it gets more time in the barrel before release.


query running indicator please

Issue Type: Feature Request
Whenever a query is running, please put a spinner across the top of the results window. If there is no results window open yet, please open the window before the result is sent to the server so there is somewhere to put the spinner.
There should always be some indication that a query is running when I am looking at the tab for that query.
Since I am always connected to Azure SQL server, my queries always take 3- 5 seconds. While that is happening, I need to know that the system took my click to run the query. Without this feedback, I am tempted to click run again, but I know that I won't get any feedback the second time so I end up waiting with baited breathe to see if I get a result back or if I missed the run button when I clicked.
Azure Data Studio version: azuredatastudio 1.15.1 (83544eba2504f564d785534cc780d2073feec2cc, 2020-02-15T05:03:16.545Z)
OS version: Windows_NT x64 10.0.18363

any idea if this will ever get done? I run into this every single time I use the product. I click on run query and get no feedback that it is running until the query is done. That is really bad UX.


doc(kfp): update multi-user isolation doc title and supported platforms

/assign @joeliedtke @8bitmp3

@8bitmp3 Thank you for the suggestions! It does sound better.

(Additionally, I'd keep each line at 80 characters max)

I don't really want to enforce this, because editing existing paragraphs will incur non-trivial edits to keep the rule.
Do you find it difficult to read in some situations? So far, I've been using VS Code with wrapping enable to edit markdown files and not manually wrapping lines make the whole editing a lot easier.

/approve

(Additionally, I'd keep each line at 80 characters max)
I don't really want to enforce this, because editing existing paragraphs will incur non-trivial edits to keep the rule.
Do you find it difficult to read in some situations? So far, I've been using VS Code with wrapping enabled to edit markdown files. Not manually wrapping lines make the whole editing a lot easier.

@Bobgy Ok! Whatever makes it easier to review for you.
I think some open-source projects, including at Google, have a linter in docs tests that sort of checks for the 80 chart limit, many don't have it so it's not enforced.
Certain IDEs may not have the default setting set to auto-wrap (do the less modern ones with less GUI have them?). So if a user forks the repo and starts working via the CLI, their view may not be the same as ours. the GitHub web UI, VSCode, IDEA and Xcode have done an excellent job at this.
Check this out - https://about.gitlab.com/blog/2016/10/11/wrapping-text/ - to wrap or not to wrap dos and don'ts 🙂

/lgtm


Add DGCarsDataset()

Add a ChipDataset() daughter class for DG Cars. Includes tests.
Since this is a "showroom" dataset, car_id, cam_id, and time are all None. The chip_id is the full path to the file, as we have done with other classes.

Current coverage is 95.00% (diff: 100%)

Merging #39 into master will increase coverage by 0.53%

@@             master        #39   diff @@
==========================================
  Files            16         18     +2
  Lines          1049       1161   +112
  Methods           0          0
  Messages          0          0
  Branches        156        170    +14
==========================================
+ Hits            991       1103   +112
  Misses           42         42
  Partials         16         16

Powered by Codecov. Last update 5783ceb...dc9900f


Interesting API page

Add a page for interesting APIS.
First is US debt
https://api.fiscaldata.treasury.gov/services/api/fiscal_service/v2/accounting/od/debt_to_penny?filter=record_date:eq:2024-05-16

close with pr #8

#8


PATH-routing: url was not escaped correctly

If PATH routing was defined, the uri was not escaped correctly so the
mapping rules will not work as expected.
Reported by: Carlo Palmiari<EMAIL_ADDRESS>Fix: THREESCALE-3468
Related-to:112fdfa502483983b462fb82a5e789003ab9f750
Signed-off-by: Eloy Coto<EMAIL_ADDRESS>

This actually fixes THREESCALE-4152


Not working in FF44 Nightly

FF nightly has push notifications available, but Caturday Post doesn't work.
It seems to be a Polymer problem, but I haven't figured it out yet. It may be as simple as wrapping a 'WebComponentsReady' event handler around the setup code in the HTML.

Same for Safari.

@Haroenv Service Worker (and Push Notifications) aren't supported in Safari, so it's not expected to work :)

Ah, I haven't worked with them before, I didn't realise they used a proprietary notification method until now @notwaldorf

FF44 has released support for push notifications now. I'll take a look into updating this. :cat: :smile_cat: :smirk_cat: for everyone!

OMG that would be amaze! Everyone send @philnash some 🍰🍰🍰


Patch spell

Allow updating spells using PATCH against /spells/{name}
Might need to handle versions and auth or something to prevent people overwriting other people's stuff.

Might want it to be PUT instead of PATCH and require users to provide the full definition of the spell with any updates rather than just the diff. Possibly support both.


Build failure for v1.3.0 on macos & linux, but building from latest main (1699a7d1fc7ede) works

I just tried to compile the latest version with cargo, and maybe I'm doing something wrong but I can only get v1.2.0 to build. Here's what I tried.
Note, if i either cargo install jaq --version "1.2.0" or I clone from git (1699a7d1fc7ede as of now) I can build either of those. So IDK..? I am pretty new to rust so maybe I'm missing a step?
$ uname -a
Darwin NUSLANYKC904450 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:19:22 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8112 arm64
$ curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh
$ rustc --version
rustc 1.77.2 (25ef9e3d8 2024-04-09)
$ cargo --version
cargo 1.77.2 (e52e36006 2024-03-26)
$ cargo install jaq
    Updating crates.io index
    Installing jaq v1.3.0
    Updating crates.io index
  Downloaded cc v1.0.96
  Downloaded 1 crate (76.6 KB) in 1.02s
   Compiling proc-macro2 v1.0.81
   ...
   Compiling jaq v1.3.0
error[E0599]: no variant or associated item named `Unset` found for enum `ariadne::Color` in the current scope
   --> /Users/a0761532/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jaq-1.3.0/src/main.rs:476:17
    |
476 |         (Color::Unset, Color::Unset)
    |                 ^^^^^ variant or associated item not found in `Color`

error[E0599]: no variant or associated item named `Unset` found for enum `ariadne::Color` in the current scope
   --> /Users/a0761532/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jaq-1.3.0/src/main.rs:476:31
    |
476 |         (Color::Unset, Color::Unset)
    |                               ^^^^^ variant or associated item not found in `Color`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `jaq` (bin "jaq") due to 2 previous errors
error: failed to compile `jaq v1.3.0`, intermediate artifacts can be found at `/var/folders/vf/9dvlj94d7d990822xvnpbqn40000gn/T/cargo-installa6qIVu`.

I get the same thing on my linux machine.
$ uname -a
Linux m1n3 6.8.7-402.asahi.fc39.aarch64+16k #1 SMP PREEMPT_DYNAMIC Wed Apr 24 00:11:34 UTC 2024 aarch64 GNU/Linux

I'm on LInux and getting the same error installing via either cargo install jaq or cargo install --git https://github.com/01mf02/jaq, but the line reference I see is jaq/src/main.rs:498 not 476.
Color::Unset is indeed invalid, according to the Color enum:
enum Color {
    Always,
    Auto,
    Never,
}

How was this even able to publish to crates.io?

ariadne::Color is really yansi::Color...
jaq depends on ariadne 0.4.0 (released 2024-01-01; 0.4.1 was just released 2024-04-25 but last commit to jaq was 2024-04-19)...
But this is weird: ariadne 0.4.0 depends on yansi 0.5.0 (released 2018-11-30; but latest is 1.0.1 on 2024-03-13)... so... ?
Also: yansi 0.5.0 Color::Unset is valid (?)
Side note relating to my previous comment: jaq/src/main.rs has a different Color enum, hence the use ariadne::{Color, Fmt, Label, Report, ReportKind}; on line 490.

yansi::Color::Unset was removed on 2023-07-06: https://github.com/SergioBenitez/yansi/commit/b186eb5bfb9023969e78a958a7589d3860058ae8#diff-12d1cf56d5d03c679a5f8f1c48cfe969a5c4276a1bee8647cc548de13f18e465L9

@qtfkwk when you do cargo install --git https://github.com/aretrosen/jaq.git, the Cargo.lock file is not used. See https://github.com/rust-lang/cargo/issues/7169. Use cargo install --git https://github.com/aretrosen/jaq.git --locked.

This issue is due to a release of the ariadne package that does not respect semantic versioning.
In the meantime, you can use cargo install --locked jaq.


examples don't build; perhaps out of sync with crates.io versions?

examples don't build; perhaps out of sync with crates.io versions?
I checked out the examples repository locally, assuming that I would be able to just run cargo build and go from there.
However, there are some clear API mismatches that break the build of the examples; it seems like they may have been recently updated to use versions of the rust gtk bindings that do not return Result anymore?
% git log -1
commit 75d11d8c6c6881c131dfbee803e670fcd28b8c35
Merge: 8958480 a88d4fa
Author: Guillaume Gomez<EMAIL_ADDRESS>Date:   Sun Jul 5 00:40:44 2015 +0200

    Merge pull request #22 from simias/master

    Use correct name for "set_homogeneous" following upstream change
% cargo build
src/basic.rs:13:17: 13:72 error: type `()` does not implement any method in scope named `unwrap_or_else`
src/basic.rs:13     gtk::init().unwrap_or_else(|_| panic!("Failed to initialize GTK."));
                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/cairotest.rs:15:17: 15:72 error: type `()` does not implement any method in scope named `unwrap_or_else`
src/cairotest.rs:15     gtk::init().unwrap_or_else(|_| panic!("Failed to initialize GTK."));
                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
error: aborting due to previous error
src/gtktest.rs:53:17: 53:72 error: type `()` does not implement any method in scope named `unwrap_or_else`
src/gtktest.rs:53     gtk::init().unwrap_or_else(|_| panic!("Failed to initialize GTK."));
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/notebook.rs:54:17: 54:72 error: type `()` does not implement any method in scope named `unwrap_or_else`
src/notebook.rs:54     gtk::init().unwrap_or_else(|_| panic!("Failed to initialize GTK."));
                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
error: aborting due to previous error
src/sync_widgets.rs:11:17: 11:72 error: type `()` does not implement any method in scope named `unwrap_or_else`
src/sync_widgets.rs:11     gtk::init().unwrap_or_else(|_| panic!("Failed to initialize GTK."));
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/text_viewer.rs:15:17: 15:72 error: type `()` does not implement any method in scope named `unwrap_or_else`
src/text_viewer.rs:15     gtk::init().unwrap_or_else(|_| panic!("Failed to initialize GTK."));
                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/sync_widgets.rs:24:10: 24:31 error: type `gtk::widgets::_box::Box` does not implement any method in scope named `set_homogeneous`
src/sync_widgets.rs:24     hbox.set_homogeneous(true);
                                ^~~~~~~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors
error: aborting due to previous error
   Compiling rgtk-examples v0.0.1 (file:///home/pnkfelix/Dev/Rust/examples)
Build failed, waiting for other jobs to finish...
src/treeview.rs:21:17: 21:72 error: type `()` does not implement any method in scope named `unwrap_or_else`
src/treeview.rs:21     gtk::init().unwrap_or_else(|_| panic!("Failed to initialize GTK."));
                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
Could not compile `rgtk-examples`.

To learn more, run the command again with --verbose.

I'm checking it. It's weird since travis build without problem...

It builds just fine on my computer. So question: what gtk version have you ?

@GuillaumeGomez looks like we forgot to apply our 'crates workaround' to examples. The master branch uses dependencies from crates.io but we've treated it like it depends on git (and travis checks compatibility with git, it overrides the crates ones).

@pnkfelix before we fix this properly, you could either

checkout an earlier commit closer to the date the crates were published or
invoke ./git_deps.sh cairo glib gdk gtk pango to build with git dependencies.

@gkoz: I create the crate branch then. It remains weird that it works fine for me...

@gkoz I tried checking out an earlier commit, speciically the one from back in May that  updated the Cargo.toml by removing the git paths for the {gtk,gdk,glib,cairo} dependencies; that build still fails, this time due to API mismatches between what cairo provides versus what src/cairotest.rs wants in the examples.  (See transcript below.)
I'll try the git_deps.sh script next.
13-43-36 Rust/rust-gnome % rustc --version
rustc 1.0.0 (a59de37e9 2015-05-13) (built 2015-05-14)
13-43-50 Rust/rust-gnome % cargo --version
cargo 0.2.0-nightly (efb482d 2015-04-30) (built 2015-04-30)
13-43-53 Rust/rust-gnome % git clone git@github.com:rust-gnome/examples.git
Cloning into 'examples'...
Enter passphrase for key '/home/pnkfelix/.ssh/id_rsa':
remote: Counting objects: 165, done.
remote: Total 165 (delta 0), reused 0 (delta 0), pack-reused 165
Receiving objects: 100% (165/165), 32.66 KiB | 0 bytes/s, done.
Resolving deltas: 100% (85/85), done.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at a476196... Update Cargo.toml
13-44-59 rust-gnome/examples (git:(HEAD detached at a476196)) % cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading gtk v0.0.2
 Downloading libc v0.1.8
 Downloading gdk-sys v0.1.1
 Downloading gdk v0.1.1
 Downloading gcc v0.3.9
 Downloading pkg-config v0.3.5
 Downloading cairo-sys-rs v0.1.2
 Downloading glib-sys v0.1.1
 Downloading cairo-rs v0.0.3
 Downloading gtk-sys v0.1.1
 Downloading bitflags v0.1.1
 Downloading glib v0.0.2
 Downloading c_vec v1.0.12
 Downloading pango-sys v0.1.1
 Downloading pango v0.0.2
   Compiling gcc v0.3.9
   Compiling pkg-config v0.3.5
   Compiling bitflags v0.1.1
   Compiling libc v0.1.8
   Compiling c_vec v1.0.12
   Compiling gdk-sys v0.1.1
   Compiling pango-sys v0.1.1
   Compiling glib-sys v0.1.1
   Compiling cairo-sys-rs v0.1.2
   Compiling gtk-sys v0.1.1
   Compiling glib v0.0.2
   Compiling pango v0.0.2
   Compiling cairo-rs v0.0.3
   Compiling gdk v0.1.1
   Compiling gtk v0.0.2
src/cairotest.rs:11:5: 11:45 error: unresolved import `cairo::enums::FontSlant::FontSlantNormal`. There is no `FontSlantNormal` in `cairo::enums::FontSlant`
src/cairotest.rs:11 use cairo::enums::FontSlant::FontSlantNormal;
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/cairotest.rs:12:5: 12:47 error: unresolved import `cairo::enums::FontWeight::FontWeightNormal`. There is no `FontWeightNormal` in `cairo::enums::FontWeight`
src/cairotest.rs:12 use cairo::enums::FontWeight::FontWeightNormal;
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors
   Compiling rgtk-examples v0.0.1 (file:///home/pnkfelix/Dev/Rust/rust-gnome/examples)
Build failed, waiting for other jobs to finish...
Could not compile `rgtk-examples`.

To learn more, run the command again with --verbose.

@pnkfelix: I update the repo as soon as possible.

@pnkfelix: It's done. Update the repo and try again please.

@GuillaumeGomez I don't see new commits anywhere.

Oups, I open/merge a PR.

I updated crates @pnkfelix.

@gkoz: I created a non-crate branch which build with other rust-gnome repos master branch.

@GuillaumeGomez hmm, mind giving that branch a non-negative name, like git or pending or candidate?

Euh... Pick one.

Let's go with pending.

Done.

Thanks

You're welcome. Is it good for you too @pnkfelix ?

@pnkfelix: Can we close this ?

Package gtk v0.0.4 does not have these features: gtk_3_10, gtk_3_14
getting a response like this, on projects without a cargo.lock

@dallyshalla thanks for the heads up. The master branch has been updated now. Some tips for migrating your own projects can be found in the recent blog post

@GuillaumeGomez works for me now, thanks.

@pnkfelix: Perfect, thanks for confirming ! :)

Everything working just right here, thanks you all for the great work


MM-34407 Use Avatars for Sidebar DMs

Summary
Use DM's Avatars in Sidebar & channel info
Ticket Link
https://mattermost.atlassian.net/browse/MM-34407

Building app in separate branch.

Artifact links:
https://15213-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.apk
https://15212-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.ipa

@matthewbirtch I get you.. but I those require way more changes than expected as it should consider the avatars on the main channel and thread view as well as the profile screen, etc..
If you want all that done, I would argue that this should be done either as a large help wanted ticket or a feature team.

Alternatively I can look for some time to do this, but not anytime soon :)

@matthewbirtch I get you. but those require way more changes than expected as it should consider the avatars on the main channel and thread view as well as the profile screen, etc..
If you want all that done, I would argue that this should be done either as a large help wanted ticket or a feature team.

I thought these would be pretty minor UI tweaks. I agree we should be consistent between the channel and sidebar avatars, but the avatars in the channel aren't so glaring because the outline around the status is the same as the background color and the avatars are larger in the channel.
If we can't make these changes on the sidebar, I don't think we should do this at all since the status icons don't work well and things are misaligned.

@matthewbirtch I get you. but those require way more changes than expected as it should consider the avatars on the main channel and thread view as well as the profile screen, etc..
If you want all that done, I would argue that this should be done either as a large help wanted ticket or a feature team.

I thought these would be pretty minor UI tweaks. I agree we should be consistent between the channel and sidebar avatars, but the avatars in the channel aren't so glaring because the outline around the status is the same as the background color and the avatars are larger in the channel.
If we can't make these changes on the sidebar, I don't think we should do this at all since the status icons don't work well and things are misaligned.

If we can't make these changes on the sidebar, I don't think we should do this at all since the status icons don't work well and things are misaligned.

@matthewbirtch can you look at this from a large picture and not just the sidebar? What I mean is that if we make the changes we need to make sure those changes are not affecting other places unless we want those changes to apply there as well.
If this changes apply only to the sidebar it is going to mean that I'll be adding code to handle specifically the sidebar while keeping the rest intact. This could get the code messy (not necessarily but).. is that what we want ?

If we can't make these changes on the sidebar, I don't think we should do this at all since the status icons don't work well and things are misaligned.

@matthewbirtch can you look at this from a large picture and not just the sidebar? What I mean is that if we make the changes we need to make sure those changes are not affecting other places unless we want those changes to apply there as well.
If this changes apply only to the sidebar it is going to mean that I'll be adding code to handle specifically the sidebar while keeping the rest intact. This could get the code messy (not necessarily but).. is that what we want ?

So really, all we're talking about is the avatar and status changes I'm proposing.

The 2px outline suggested above would be good to apply to the channel as well
The size of the status icon in the channel is fine as-is since it appears a bit larger in this context

The 2px outline suggested above would be good to apply to the channel as well
today this is done in one component UserStatus.. with the change we'll need to pass a prop down 4 components

The size of the status icon in the channel is fine as-is since it appears a bit larger in this context
OK, we already have a prop for this size.. just need to change it

I'll make the changes you are asking for.. but I'll do it at some point, thought this was going to be a quick thing, not as detailed.. so I'm moving to something else and at some point I'll come back to this.

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/15213
https://circleci.com/gh/mattermost/mattermost-mobile/15212

Artifact links:
https://15213-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.apk
https://15212-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.ipa

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/15213
https://circleci.com/gh/mattermost/mattermost-mobile/15212

Artifact links:
https://15213-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.apk
https://15212-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.ipa

@matthewbirtch I don't think we considered shared channels conflicting with #5241

@matthewbirtch I don't think we considered shared channels conflicting with #5241

@enahum I don't think there is a conflict, actually. Shared channels simply replace the channel icon with the shared channel icon, while DMs from shared organizations won't show a change to the sidebar item.

I can see the avatars in the Sidebar and they look pretty good! I do see this TypeError though - unfortunately the stack trace isn't leading me anywhere:

This branch is based on a previous master branch, so to test locally you need to either merge the lastest master or clean everything, fetch deps & recompile.. the TypeError is cause you attempted to run the branch with a different version of MMkV on your local env.

Cherry pick is scheduled.


Bot getting stuck in Water fix

Fixes issue #54
The Bot tries to jump up inside the water block to place a Block below it.
This is not possible with standard Minecraft physics as the player cannot jump high enough out of the water block to place a block below itself.

This move is possible with minecraft physics. The issue is in mineflayer's physic implementation. There is an open issue about it: https://github.com/PrismarineJS/prismarine-physics/issues/28

After some testing, it seems that placing a block while jumping in water only works in 1.13+. I'll merge it for now, we'll add the functionality for 1.13+ when we fix p-physics.

After some testing, it seems that placing a block while jumping in water only works in 1.13+. I'll merge it for now, we'll add the functionality for 1.13+ when we fix p-physics.