[23304] Update tasks status color.

Details
Task status used to be a link in the past, but it's not anymore. Updated it's color from a blue link color to a gray color.
Fixed Issues
$ https://github.com/Expensify/App/issues/23304
PROPOSAL: https://github.com/Expensify/App/issues/23304#issuecomment-1644523224
Tests
Same as QA Steps.

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

Offline tests
Same as QA Steps.
QA Steps

Create a task with any title, description and asignee;
Mark it as done -> reopen it -> close it;
Verify that "completed task", "reopened task" & "canceled task" messages are gray.

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

PR Author Checklist

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

The entire system message should use the textSupporting color. The task title should not appear in the regular text color. Can you please update? cc @JmillsExpensify @trjExpensify

Correct. But where it says "Test Title" here, those are in the wrong color:

Hmm, I didn't modify that part. From what I know, it was not discussed in the issue/proposal, but it's very easy to update if needed.

The entire system message ...

"Test Title" is the actual title which I've gave to the task. Should I leave its color as it was, or to update it?

I don't know if any system message uses that style. My understanding is almost the same. The only difference is that I understood that only the task's status is part of the system message, while the task title would not be part of the system message as it's user input and does not come from the system. Comments in the issue also referenced the blue text.
Let me know if I misunderstood and should update.

the entire system message should use the text supporting color. So let's update it to use that.

So, you're saying that the task's title is considered a system message?

Yes, we are showing the title within the system message itself.

this should be a shared component that all system messages use

There's this existing component: InlineSystemMessage, which uses:
https://github.com/Expensify/App/blob/dc3270005e924e49a890028bd4b3ef094a939227/src/styles/styles.js#L3152-L3157
Don't know if the font is a good fit for this, and also don't think that the marginLeft is desired here, but I think we can pass some style props in order to add/override what we need.
I think I have to wait for @ArekChr & @dangrous feedback in order to know if it's ok to implement it like that.

Also, this should be a shared component that all system messages use. Is there a way to dry this up to make sure we're using the same, consistent system message component everywhere?

We can achieve this by combining styles.chatItemMessage and styles.colorMuted into a single style or creating a custom Text component that utilizes both styles. Based on what I see in the codebase, it seems unlikely to create text wrappers everywhere, as it consistently uses styles directly.

I'm not so much talking about styles, I'm also talking about the code here. I would imagine we will use system messages in many other situations, not just tasks.

@JmillsExpensify do you mind chiming in here? Where else do we currently use system messages?

this should be a shared component that all system messages use

There's this existing component: InlineSystemMessage, which uses:
https://github.com/Expensify/App/blob/dc3270005e924e49a890028bd4b3ef094a939227/src/styles/styles.js#L3152-L3157
Don't know if the font is a good fit for this, and also don't think that the marginLeft is desired here, but I think we can pass some style props in order to add/override what we need, or to create a new component: SystemMessage.
I think I have to wait for @ArekChr & @dangrous feedback in order to know if it's ok to implement it like that.

This style is used for inline system errors, has different font size and margins

@ArekChr

This style is used for inline system errors, has different font size and margins

I think we may make it more customizable as to receive and apply only the style(s) received through props(for the parent View & for the Text) , and also to display the icon based on a boolean.
Or, we may create a new component in a similar manner.

Sorry to clarify, this system message is different from the inlineSystemError messages. Let's ignore that as it relates to this particular project.
Here is an example of where we'd use system messages elsewhere, in a different project:

The point being, let's not duplicate the work and have multiple ways in the code to render a system message. It's a shared style that will be used all over the platform, not just for tasks.
But that being said, I can see where that is something we should tackle elsewhere, and this issue should just be about updating the color.
cc @jasperhuangg @thienlnam - can you comment on the idea of drying this up for future use?

@shawnborton, what do you think about adding a ":" as a separator between the message and the task name?
like here:

Web screenshot looks good. No need to add the : - we can leave the message as-is.

@shawnborton
Ok, thank you!
@ArekChr
I will proceed to update the other screenshots soon, and make code changes when & if you require. Thanks!

But that being said, I can see where that is something we should tackle elsewhere, and this issue should just be about updating the color.
cc @jasperhuangg @thienlnam - can you comment on the idea of drying this up for future use?

If refactoring the current component as to make it customizable through props will be desired, I'm available to make that PR for no bounty/payment afterwards.

@shawnborton sorry for the delay! We already use system messages on expense reports. I agree with everything you said above around textSupporting, that's what it's supposed to be, it's just for some reason this isn't the case on Tasks. I'm not sure why. Example on expense reports below.

Also very minor but important point. All system messages begin with a lowercase letter, not a capitalized one.

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

Screenshots look good, thanks!

@dangrous I'm rechecking the changes on all platforms and updating the Screenshots now. Please wait before merging, I want to make sure all is good! Thanks!

Done updating my screenshots too, sorry for the delay!
@dangrous all good now!

: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/dangrous in version: 1.3.49-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/dangrous in version: 1.3.50-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 1.3.49-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.50-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


documentation: Fix typo in dockerAuth example

domains -> registries

Reference: https://github.com/coreos/rkt/blob/9ddb77f0fbc8d5cabbd5a70b7873882341d87ce7/rkt/config/auth.go#L47

Nice catch, thanks!


Return status 33 when ranging is not available between devices.

We should not send ShortMacTwoWaySessionInfoNtf with no measurement back
to host. Instead, send measurement with status 33 when ranging is not
available.

Could you add a small test to validate the change please ? You can copy the ranging_example and modify it for that.


ERR_HTTP2_PROTOCOL_ERROR

v2ray 5.21.0
Chrome reports ERR_HTTP2_PROTOCOL_ERROR when visiting https://www.xda-developers.com

tested under

chrome with SwitchyOmega, windows
nghttp with proxychains, linux

this is a special case as

most sites have a http/1.1 fallback but this site does not
I can actually visit other sites using http/2 (e.g. https://cloudflare-quic.com/ will correctly fallback to http/2 when udp is disabled)

I know it's a v2ray issue because

if connected directly without v2ray, there will be no such error
if connected using sing-box (with a similar minimal config with just a socks inbound and a direct outbound) and everything else remains the same, there will be no such error

I know it's about http/2 because

Chrome reports so
validated by nghttp, (see below)

I found one possibly related issue (https://github.com/v2fly/v2ray-core/discussions/2420) but it seems about the http server. Well this is about the socks server, and it should work.
There are other services and websites having this kind of issues, like the Android YouTube app (not thoroughly tested).
minimal reproduction v2ray config (there is just one machine)
{
  "log": {
    "level": "debug"
  },
  "inbounds": [
    {
      "listen": "<IP_ADDRESS>",
      "port": 1080,
      "protocol": "socks",
      "tag": "socks"
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "freedom"
    }
  ]
}

console logs
V2Ray 5.21.0 (V2Fly, a community-driven edition of V2Ray.) Custom (go1.23.2 linux/amd64)
A unified platform for anti-censorship.
2024/11/10 15:18:41 [Warning] V2Ray 5.21.0 started
2024/11/10 15:18:46 [Warning] [534970841] app/dispatcher: default route for tcp:www.xda-developers.com:443
2024/11/10 15:18:46 tcp:<IP_ADDRESS>:55972 accepted tcp:www.xda-developers.com:443 [freedom]

additional http/2 test using proxychains and nghttp
$ proxychains -q nghttp -v https://www.xda-developers.com
[  0.074] Connected
The negotiated protocol: h2
[  0.240] send SETTINGS frame <length=12, flags=0x00, stream_id=0>
          (niv=2)
          [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
          [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535]
[  0.240] send PRIORITY frame <length=5, flags=0x00, stream_id=3>
          (dep_stream_id=0, weight=201, exclusive=0)
[  0.240] send PRIORITY frame <length=5, flags=0x00, stream_id=5>
          (dep_stream_id=0, weight=101, exclusive=0)
[  0.240] send PRIORITY frame <length=5, flags=0x00, stream_id=7>
          (dep_stream_id=0, weight=1, exclusive=0)
[  0.240] send PRIORITY frame <length=5, flags=0x00, stream_id=9>
          (dep_stream_id=7, weight=1, exclusive=0)
[  0.240] send PRIORITY frame <length=5, flags=0x00, stream_id=11>
          (dep_stream_id=3, weight=1, exclusive=0)
[  0.240] send HEADERS frame <length=45, flags=0x25, stream_id=13>
          ; END_STREAM | END_HEADERS | PRIORITY
          (padlen=0, dep_stream_id=11, weight=16, exclusive=0)
          ; Open new stream
          :method: GET
          :path: /
          :scheme: https
          :authority: www.xda-developers.com
          accept: */*
          accept-encoding: gzip, deflate
          user-agent: nghttp2/1.59.0
[  0.304] recv SETTINGS frame <length=18, flags=0x00, stream_id=0>
          (niv=3)
          [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):128]
          [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65536]
          [SETTINGS_MAX_FRAME_SIZE(0x05):16777215]
[  0.304] recv WINDOW_UPDATE frame <length=4, flags=0x00, stream_id=0>
          (window_size_increment=2147418112)
[  0.304] recv SETTINGS frame <length=0, flags=0x01, stream_id=0>
          ; ACK
          (niv=0)
[  0.305] recv RST_STREAM frame <length=4, flags=0x00, stream_id=13>
          (error_code=PROTOCOL_ERROR(0x01))
[  0.305] send GOAWAY frame <length=8, flags=0x00, stream_id=0>
          (last_stream_id=0, error_code=NO_ERROR(0x00), opaque_data(0)=[])
Some requests were not processed. total=1, processed=0

For comparison, if using sing-box, with everything else exactly the same
$ proxychains -q nghttp -v https://www.xda-developers.com
[  0.009] Connected
The negotiated protocol: h2
[  0.554] send SETTINGS frame <length=12, flags=0x00, stream_id=0>
          (niv=2)
          [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
          [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535]
[  0.554] send PRIORITY frame <length=5, flags=0x00, stream_id=3>
          (dep_stream_id=0, weight=201, exclusive=0)
[  0.554] send PRIORITY frame <length=5, flags=0x00, stream_id=5>
          (dep_stream_id=0, weight=101, exclusive=0)
[  0.554] send PRIORITY frame <length=5, flags=0x00, stream_id=7>
          (dep_stream_id=0, weight=1, exclusive=0)
[  0.554] send PRIORITY frame <length=5, flags=0x00, stream_id=9>
          (dep_stream_id=7, weight=1, exclusive=0)
[  0.554] send PRIORITY frame <length=5, flags=0x00, stream_id=11>
          (dep_stream_id=3, weight=1, exclusive=0)
[  0.554] send HEADERS frame <length=45, flags=0x25, stream_id=13>
          ; END_STREAM | END_HEADERS | PRIORITY
          (padlen=0, dep_stream_id=11, weight=16, exclusive=0)
          ; Open new stream
          :method: GET
          :path: /
          :scheme: https
          :authority: www.xda-developers.com
          accept: */*
          accept-encoding: gzip, deflate
          user-agent: nghttp2/1.64.0
[  0.816] recv SETTINGS frame <length=18, flags=0x00, stream_id=0>
          (niv=3)
          [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):128]
          [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65536]
          [SETTINGS_MAX_FRAME_SIZE(0x05):16777215]
[  0.816] recv WINDOW_UPDATE frame <length=4, flags=0x00, stream_id=0>
          (window_size_increment=2147418112)
[  0.816] recv SETTINGS frame <length=0, flags=0x01, stream_id=0>
          ; ACK
          (niv=0)
[  0.816] send SETTINGS frame <length=0, flags=0x01, stream_id=0>
          ; ACK
          (niv=0)
[  1.086] recv (stream_id=13) :status: 200
...

Sorry I just found out that www.xda-developers.com blocked the ip of the device on which I tested v2ray.
Some of the claim in the original test were wrong (I forgot to control the device I used to test), my apologize.


Update flannel  and move to native flannel wireguard backend

Proposed Changes
This moves the flannel wireguard backend from the flannel extension based implementation to the native flannel wireguard backend
Verification
Run k3s with --flannel-backend=wireguard that should work as expected
User-Facing Change
NONE

How does this handle migrating the existing configuration if the user is already using the current wireguard backend?

How does this handle migrating the existing configuration if the user is already using the current wireguard backend?

I was also curious about this, so I gave it a try to see what happened.
Reality matched my expectation, which was that it would not work because the flannel metadata for the two backends is incompatible, i.e. with the extension we had
"flannel.alpha.coreos.com/backend-data": "\"T+ojWszVHuR3RI5J2B9PHwjzdPYoRwiMToXArtWaikw=\"",
"flannel.alpha.coreos.com/backend-type": "extension",

as a node annotation, and with the wireguard backend, we have:
"flannel.alpha.coreos.com/backend-data": "{\"PublicKey\":\"ompY9jxDRGudcjNvoWoyLrFPdgjeJ28eeD3DX/YCSho=\"}",
"flannel.alpha.coreos.com/backend-type": "wireguard",

The extension expects one format, the builtin wireguard expects another, and nodes using different flannel configurations cannot communicate.
I don't think it's possible to run both flannel backends in parallel, so effectively as you switch nodes over one at a time, pod-to-pod communication will be temporarily broken between old and new nodes.
I also ran into an additional issue: when I updated k3s in-place, it gave me the following error:
k3s[78046]: time="2022-03-31T21:39:16Z" level=fatal msg="flannel exited: failed to set up the route: failed to set interface flannel-wg to UP state: address already in use"

This was because the flannel.1 interface already had wireguard listening on port 51820, and systemctl restart k3s.service didn't cause the interface to go away, resulting in the flannel-wg interface being unable to be put "up".
This can be fixed by restarting the node entirely, since the flannel.1 interface is transient and vanishes on system reboot. Presumably putting that interface down would also fix it.
This still makes it an awkward upgrade.
After updating both the agent and server binaries and rebooting both nodes, things did come up and pod-to-pod communication worked.

Some raw output from testing this
# Installed a 2-node cluster with the existing wireguard backend
$ k3s --version
k3s version v1.22.7+k3s1 (8432d7f2)

$ sudo systemctl cat k3s
....
ExecStart=/usr/local/bin/k3s server --flannel-backend=wireguard

# agent node
$ sudo systemctl cat k3s-agent
....
ExecStart=/usr/local/bin/k3s agent - --flannel-backend=wireguard

# back on the server node
$ k3s kubectl get no -o wide
NAME              STATUS   ROLES                  AGE     VERSION        INTERNAL-IP    EXTERNAL-IP   OS-IMAGE       KERNEL-VERSION    CONTAINER-RUNTIME
ip-172-31-14-34   Ready    <none>                 3m49s   v1.22.7+k3s1   <IP_ADDRESS>   <none>        Ubuntu 21.10   5.13.0-1017-aws   containerd://1.5.9-k3s1
ip-172-31-4-167   Ready    control-plane,master   28m     v1.22.7+k3s1   <IP_ADDRESS>   <none>        Ubuntu 21.10   5.13.0-1017-aws   containerd://1.5.9-k3s1

$ k3s kubectl get no ip-172-31-14-34 -o json | grep "flannel.alpha.coreos"
            "flannel.alpha.coreos.com/backend-data": "\"T+ojWszVHuR3RI5J2B9PHwjzdPYoRwiMToXArtWaikw=\"",
            "flannel.alpha.coreos.com/backend-type": "extension",
            "flannel.alpha.coreos.com/kube-subnet-manager": "true",
            "flannel.alpha.coreos.com/public-ip": "<IP_ADDRESS>",

# Both have their public key stored like this.
# Now, let's upgrade the worker node, then server node, to this PR

# I cherry-picked this change onto v1.22.7+k3s1 so I could minimize the changes being made, built that, and used it

# First: naively using the new k3s binary gives me a fatal error:
k3s[78046]: time="2022-03-31T21:39:16Z" level=fatal msg="flannel exited: failed to set up the route: failed to set interface flannel-wg to UP state: address already in use"

$ sudo wg show
interface: flannel.1
  public key: T+ojWszVHuR3RI5J2B9PHwjzdPYoRwiMToXArtWaikw=
  private key: (hidden)
  listening port: 51820

peer: sakJfZL7E8pDUFd4QabX8P8j5cPzQQc5nm6REz05omk=
  endpoint: <IP_ADDRESS>:51820
  allowed ips: <IP_ADDRESS>/24
  latest handshake: 14 seconds ago
  transfer: 5.85 KiB received, 8.48 KiB sent
  persistent keepalive: every 25 seconds

interface: flannel-wg
  public key: aPG89jwP/6eBmEspNhNb1qs5YIX3bix832xJnGsHDnE=
  private key: (hidden)
  listening port: 51820

# This is because the old flannel.1 interface is already listening on the same port, so it conflicts, and k3s didn't tear it down on exit I guess.
# Let's restart the node to clear out that temporary state
# --
# Okay, after rebooting, we're down to one flannel-wg
# Back to the master node

$ k3s kubectl get no ip-172-31-14-34 -o json | grep -i flannel
            "flannel.alpha.coreos.com/backend-data": "{\"PublicKey\":\"ompY9jxDRGudcjNvoWoyLrFPdgjeJ28eeD3DX/YCSho=\"}",
            "flannel.alpha.coreos.com/backend-type": "wireguard",
            "flannel.alpha.coreos.com/kube-subnet-manager": "true",
            "flannel.alpha.coreos.com/public-ip": "<IP_ADDRESS>",

# Different format
# No traffic between pods.
# After updating and rebooting the master, pod<->pod communication works and everything looks good

I did the same test and as @euank described k3s doesn't start if the nodes aren't rebooted or flannel.1 is not deleted.
A possible fix could be deleting the interface through k3s if the interface exists and wireguard is selected as backend.
I tested it locally and using k3s upgrade plan I was able to update multiple nodes without any issues.

I tested it locally and using k3s upgrade plan I was able to update multiple nodes without any issues.

To repeat some info from my experiment above, there is a "split-network" period there, where for example if the ingress controller is on a "new" node and a pod for a service behind an ingress is on an "old" node, requests to access that ingress will fail until the upgrade is completed.
The nodes will still show as "Ready", so it's an easy error state to miss while experimenting here.
That may or may not be acceptable, depending on the cluster, but I think it definitely needs to be called out in a release note at least.

I'll also offer an opinion on one possible option to move forward here in a less-breaking way.
We could temporarily have two wireguard backends, and use release notes and docs to migrate people to the new one. Specifically, I'm proposing having:
--flannel-backend=wireguard            # uses the extension we use today, no change to it
--flannel-backend=native-wireguard # uses the new flannel `"Type": "wireguard"` backend

If we merge the change like that, update all the docs to tell you to use native-wireguard, and add a release note indicating that wireguard will be replaced with native-wireguard in two major versions (with native-wireguard remaining as an alias), that will hopefully give people time to figure out a migration plan.
This option is primarily inspired by how upstream k8s handles breaking changes.
I do think that the pod-network being broken between old/new nodes is sufficient to take special effort and give people at least one major release where both the old and new options are available.

I tested it locally and using k3s upgrade plan I was able to update multiple nodes without any issues.

To repeat some info from my experiment above, there is a "split-network" period there, where for example if the ingress controller is on a "new" node and a pod for a service behind an ingress is on an "old" node, requests to access that ingress will fail until the upgrade is completed.
The nodes will still show as "Ready", so it's an easy error state to miss while experimenting here. Just deleting the old flannel.1 interface and waiting for the node to be Ready isn't sufficient to work around this issue.
That may or may not be acceptable, depending on the cluster, but I think it definitely needs to be called out in a release note at least.
I'll also offer an opinion on one possible option to move forward here in a less-breaking way.
We could temporarily have two wireguard backends, and use release notes and docs to migrate people to the new one. Specifically, I'm proposing having:
--flannel-backend=wireguard        # uses the extension we use today, no change to it
--flannel-backend=native-wireguard # uses the new flannel `"Type": "wireguard"` backend

If we merge the change like that, update all the docs to tell you to use native-wireguard, and add a release note indicating that wireguard will be replaced with native-wireguard in two major versions (with native-wireguard remaining as an alias), that will hopefully give people time to figure out a migration plan.
This option is primarily inspired by how upstream k8s handles breaking changes.
I do think that the pod-network being broken between old/new nodes is sufficient to take special effort and give people at least one major release where both the old and new options are available.

I agree with this approach. Leave both options available for a few releases setting the old one as deprecated. Then, explain in the docs how to migrate from the old to the new one

Closing this PR in favor of https://github.com/k3s-io/k3s/pull/5391, which will allow both wireguard implementations to coexist.


Add ORCID ID field to Registration page

There should also be some validation to make sure it is using valid orcid structure, but that can be separated out into a separate issue/setp.

Yup, looks like validation was already submitted as a separate issue. Now linked.

This is in

paleobot/pbot-api@b41b403f36846dbcc2a023f9ef50f2cdbe45fafa
paleobot/pbot-api@128a87e8f9a9f920ed99d3444d1d31006e07fc33
paleobot/pbot-client@ef73fdff1fd9e5aad5b8ba555f2ed0f8780768fc


Update Tahoma component's tahoma-api requirement's version

Description:
After reverting the PR for removing Tahoma component, an update to the component's tahoma-api requirement must be done.
Related issue (if applicable): #29744 #29840
Example entry for configuration.yaml (if applicable):
tahoma:
  username: YOUR_USERNAME
  password: YOUR_PASSWORD

Checklist:

[x] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

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

[x] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[x] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
[x] Untested files have been added to .coveragerc.

@fabaff sorry for my error, it's been a newbie one trying to start collaborating here.
I've edited the PR comment and completed it except the one about tox, because I'm having problems with py36, py37, py38 and cov envs. They all have errors. I get this output:
ERROR:   py36: commands failed
ERROR:   py37: commands failed
ERROR:   py38: commands failed
  lint: commands succeeded
  pylint: commands succeeded
  typing: commands succeeded
ERROR:   cov: commands failed

The thing is that after every tox run, I get the errors in different parts, but it's supposed that I have to pass everything 🤔. Could you help me explaining why does this happen to me? Here are 2 different runs with pytest's -x option to stop in the first error: run1 and run2.
Thanks in advance for the help and for contributing into this great project.

works now. Thanks!
Welcome to the Home Assistant community 🐬 🎉

Thanks for picking this up. I really appreciate the tahoma integration being re-added as the open Somfy API is not at all feature complete. Support for most of the Somfy products is missing by Somfy. Having both allows to continue to use the not yet supported devices and functions in the meantime.


Move all (most?) dependency versions out of Common.prod.props?

Since this is a monorepo to support various contributions (providers, hooks, framework-specific integrations) we should try to decentralize dependency management as much as possible (move dependencies into the subfolder belonging to the associated module). This is especially important to make optimal use of both release-please and the component_owners configuration. The OpenFeature SDK dependency as well as any module-specific dependencies should be maintained by each module. Some basic common modules and test modules may be centrally maintained if that's valuable.
See: https://github.com/open-feature/dotnet-sdk-contrib/pull/136#pullrequestreview-1827964995, https://github.com/open-feature/dotnet-sdk-contrib/pull/136#discussion_r1465316395
Originally posted by @austindrenski in https://github.com/open-feature/dotnet-sdk-contrib/issues/136#issuecomment-1908617863

I had a quick look at this and am happy to give it a go. What I can see needs to be done is:

Remove this line and add the reference directly to the individual projects
(Optional) Rework this section to potentially push some test dependencies down to individual projects, and to reference the version directly in the rest, so renovate can do it's work on updating them.


handle_exception implementation

When using the handle_exception example in the repo, how are the other functions like build_client_settings, rebuild_client_settings, update_client_settings, and freeze defined?

@kelseapotter https://t.me/instagrapi/6161


solve the borrow issue with the LRU cache?

I've run into the same error that this person has: http://stackoverflow.com/questions/25190063/rust-borrowing-issues-with-attempted-caching
...when using std::collections::HashMap. Essentially when you get a value from the cache, the returned reference to the value is &mut when you want it to be &. This causes compile errors for code that wants to use multiple immutable references to the containing struct of the cache.

This issue predates the Entry API, which is exactly the solution to their problem, as far as I know.
Can you post some modern code that is causing you trouble?

I am indeed using the Entry API and running into the same problem: https://github.com/andrewrk/genesis/blob/18e9b1db57de8c3c5dd06904c482d274a7048240/src/text.rs#L123

So what's wrong here? To insert an element you need mutable rights. The fact that it returns a mutable ref that you have to coerce to immutable seems minimal.

It ends up using the lifetime from &'a mut self instead of an immutable lifetime. So the cache value that gets returned is a mutable ref when I wanted an immutable ref. This causes a compile error when you try to use another field from the struct that contains the hash map.

Sounds like a bug in Rust, but maybe this is fundamental.

@pcwalton is this intended behaviour? &*(&mut T) prevents future immutable borrows of T?

@Gankro FWIW it's always been the case.

My argument was that in general borrows are not tagged by mutability. Look at this:
fn borrow_thing<'a>(&'a mut self) -> Response<'a> { ... }

If Response<'a> would be a &'a T instead, you would think it's illogical. But in general borrows keep track of what they are derived from, right, not what they produce.

Ah okay I talked it out with @nikomatsakis on IRC and there's literally nothing that can be done here with Rust's current type system. Evidently the borrow system does not look at return types to decide the kind of borrow. If you use the lifetime 'a from an &'a mut, it will always behave as a mutable borrow regardless of what the 'a is stored in.
That is, fn foo<'a>(&'a mut self) -> &'a Foo will have &'a Foo behave as an &'a mut Foo for the purposes of borrow checking. I do not believe that this is a fundamental problem with Rust. The alternative would simply require spidering the return type of a function to "infer" the mutability of the borrow. Currently borrow checking doesn't need to look at the contents of the return type beyond what lifetimes it contains. And indeed it would be harder for a reader of the API to determine the mutability of the borrow in general if this was done. e.g. today if we see fn foo(&mut self) -> Foo<'a> we know the Foo mutably borrows self, but the proposed system would require a consumer to know the internals of Foo to know the mutability of the borrow. Since we encourage private-by-default, this may not be trivial to find out.

I'm closing this as cant-fix. This is fundamental to the current language design. No API change can handle this if the method needs to take &mut self.

Thanks for looking into it.

@andrewrk As a hack, you can potentially convert the &mut to a raw ptr, convert it back to an &'static, and then copy_lifetime it with &my_map to make it into a proper shared reference to the insides of the my_map. But this can't be returned from a method that takes &mut my_map, or else it will just get re-upgraded to an owned borrow.


Update to skia-safe 0.37

skia-safe 0.37, released 2 days ago, has a few breaking changes that would cause building skulpin-renderer to fail.
Please update the skia-safe dependency to require >=0.37 so users of skulpin-renderer doesn't get this issue.

Thanks for mentioning this. I've published a 0.10.1 which limits skia-safe to <0.37 to fix the build errors (added constraints on a couple other crates as well). I think this is the closest I can stay to semver rules while also fixing the build.

= 0.37 will require a 0.11 for skulpin or additional feature flags to opt-into 0.37. I don't plan to release a non-patch update until I migrate skulpin to a new renderer that I've been working on (shouldn't be too far out.) If you need >=0.37 immediately, adding a "None" param as a second arg to the function call fixes the compile error.

Thanks for mentioning this. I've published a 0.10.1 which limits skia-safe to <0.37 to fix the build errors (added constraints on a couple other crates as well). I think this is the closest I can stay to semver rules while also fixing the build.

= 0.37 will require a 0.11 for skulpin or additional feature flags to opt-into 0.37. I don't plan to release a non-patch update until I migrate skulpin to a new renderer that I've been working on (shouldn't be too far out.) If you need >=0.37 immediately, adding a "None" param as a second arg to the function call fixes the compile error.

0.12 includes skia 0.38.1. 0.38 is broken. While 0.37 would work, since I haven’t published anything with 0.37 as a dependency I went straight to 0.38.


Calculate restore-progress via blockNo instead of slotNo

Large portions of slots may be empty. On the current jörmungandr testnet
the slot-based progress starts at around 96% and goes to 100% when restoring a wallet.
This commit uses blockNo instead, which perfectly matches the amount of
work the wallet has to do. This way progress starts at 0% and increases to 100% at a stable speed.
Issue Number
None.
Overview

[x] I changed the progress to be calculated using blocks instead of blocks.

Comments

other version in anviking/alternative-progress

bors r+


Enhancements: event subscription

Added a prompt function. Added localstorage functions to handle persistence.
On the first visit the user is asked if he wants to subscribe to all events.
The user can subscribe/unsubscribe by clicking an event.
User gets a desktop notification 5 minutes prior to subscribed event start.
Fixed:
notification logo path
notification autoclose

added:

Text telling user how to subscribe to events
Replace unicode emoji with FontAwesome one. In my computer it was not showing properly as it doesnt have emoji compatibility

The rest of symbols are shown fine. So I would keep them. Trust me, if they are shown in my computer then they are surely fine.

Edge is not compatible. Moving on


MTSDK-26 Send Typing Indicator.

Add userIsTyping public api to send typing events from user.
Ensure that typing indicator not sent more that once every 5 seconds.
Extract commonality between EventMessage.kt and TextMessage.kt to BaseMessageProtocol.kt
Add EventMessage.kt data class for events sent to Shyrka.
Ensure that UI is notified about Outbound events only.
Include eventType in StructuredMessageEvent.kt
Just to be on the safe side, use type Long for duration field instead of Int.
Add/Update unit tests.
Add KDocs for public API.

Jenkins pipeline ran successfully.


Pressable is recommended over TouchableOpacity / TouchableWithoutFeed…

According to this document, Pressable is recommended over TouchableOpacity / TouchableWithoutFeedBack.

Hi @Kotlia,
Thank you for working o this PR. In general you are right that since 0.63 release Pressable is recommended over Touchables, however the link following the sentence leads to the Button implementation which still uses Touchables:

https://github.com/facebook/react-native/blob/master/Libraries/Components/Button.js#L289

In this case I think that it's better to leave the pages as is for now to avoid the confusion. The Touchables should be deprecated within few next major releases, so the Button implementation will need to be rewritten.
The note at the beginning of each Touchable page have been added to prepare developers for the future deprecation, and give them more time to react to future deprecation, since Touchables are the base components, used in almost all React Native apps.


Can't scan passports on Android

Tested with UK and NZ passports on a Pixel 8.
I get the initial vibration, but nothing more.

Hey, thanks for the feedback.
Have you tried waiting longer after the initial vibration? Also, curious if you got an error message, or saw the progress of the reading displayed on the screen. Feel free to dm me here to chat more about that.

Yep, I stop moving on the initial vibration as instructed. Then, nada. No error message for a bit, then a flash of two or three messages that disappear too quickly to read, then back to the "start scanning" button.
Also, the instructions say to hold the phone over the last page of the passport. That's valid for my UK passport. For my NZ passport, the NFC chip is on the second page from the front.
Would be happy to test new builds as they come out. Will DM you.

Thanks, will definitely improve that in coming versions.


[3.5.2] Build hanging after failing to load resources

When attempting to run CI, all three builds  hang after a few minutes.  There are several import errors in the log output, but I'm not sure if these are responsible for the hang.
Repository:
https://github.com/107zxz/inscr-onln/actions/runs/8306126279/job/22734051267
Log output:
Run mkdir -v -p build/mac
mkdir: created directory 'build'
mkdir: created directory 'build/mac'
Godot Engine v3.5.2.stable.official.170ba337a - https://godotengine.org

Loading resource: res://default_bus_layout.tres
CORE API HASH:<PHONE_NUMBER>7570[8](https://github.com/107zxz/inscr-onln/actions/runs/8306126279/job/22734051267#step:4:9)8[9](https://github.com/107zxz/inscr-onln/actions/runs/8306126279/job/22734051267#step:4:10)600
EDITOR API HASH:<PHONE_NUMBER>500112242
Loading resource: res://default_env.tres
Loading resource: res://scripts/singletons/CardInfo.gd
Loading resource: res://scripts/singletons/GameOptions.gd
Loading resource: res://scripts/singletons/NetworkManager.gd
Loading resource: res://scripts/singletons/TunnelHandlerNew.gd
Loaded builtin certs
Loading resource: res://packed/RulesetPickerProto.tscn
ERROR: Unable to open file: res://.import/Ouroboros.png-2d9286f8f1eb5e94474f8612d875d55a.stex.
   at: _load_data (scene/resources/texture.cpp:470)
ERROR: Failed loading resource: res://.import/Ouroboros.png-2d9286f8f1eb5e94474f8612d875d55a.stex. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:270)
Loading resource: res://packed/UI/JakeLoading.tscn
Loading resource: res://gfx/portraits/Ouroboros.png
ERROR: Unable to open file: res://.import/Off.png-7bf2881149d3cafedab6459673714505.stex.
   at: _load_data (scene/resources/texture.cpp:470)
ERROR: Failed loading resource: res://.import/Off.png-7bf2881149d3cafedab6459673714505.stex. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:270)
Loading resource: res://themes/sigilMat.tres
Loading resource: res://themes/papertheme.tres
Loading resource: res://fonts/MarksmanReal.tres
Loading resource: res://gfx/extra/Off.png
Loading resource: res://gfx/extra/On.png
ERROR: Unable to open file: res://.import/On.png-b501778bdf146086002dabf141db139f.stex.
   at: _load_data (scene/resources/texture.cpp:470)
ERROR: Failed loading resource: res://.import/On.png-b501778bdf146086002dabf141db139f.stex. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:270)
Loading resource: res://fonts/ScoreFont.tres
Loading resource: res://fonts/Marksman.otf
Loading resource: res://scripts/UI/RulesetPickerProto.gd
Loading resource: res://packed/UI/RulesetLine.tscn
Loading resource: res://gfx/portraits/Stoat.png
ERROR: Unable to open file: res://.import/Stoat.png-[10](https://github.com/107zxz/inscr-onln/actions/runs/8306126279/job/22734051267#step:4:11)c9f87fe157552701bf6fdb77f3add9.stex.
   at: _load_data (scene/resources/texture.cpp:470)
ERROR: Failed loading resource: res://.import/Stoat.png-10c9f87fe157552701bf6fdb77f3add9.stex. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:270)
Loading resource: res://packed/UI/Error.tscn
Loading resource: res://packed/ThemeEditor.tscn
Loading resource: res://themes/backuptheme.tres
Loading resource: res://scripts/UI/ThemeEditor.gd
Loading resource: res://gfx/portraits/Cat.png
ERROR: Unable to open file: res://.import/Cat.png-3a80b558[13](https://github.com/107zxz/inscr-onln/actions/runs/8306126279/job/22734051267#step:4:14)0e28336bd65275dc6a1fb9.stex.
   at: _load_data (scene/resources/texture.cpp:470)
ERROR: Failed loading resource: res://.import/Cat.png-3a80b558130e28336bd65275dc6a1fb9.stex. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:270)
ERROR: Unable to open file: res://.import/Raven Egg.png-52c7b790c28596cfb00[17](https://github.com/107zxz/inscr-onln/actions/runs/8306126279/job/22734051267#step:4:18)b07368b09b0.stex.
   at: _load_data (scene/resources/texture.cpp:470)
ERROR: Failed loading resource: res://.import/Raven Egg.png-52c7b790c28596cfb0017b07368b09b0.stex. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:270)
Loading resource: res://gfx/pixport/Raven Egg.png

Contents of godot-ci.yml
name: "godot-ci export"
on: push

env:
  GODOT_VERSION: 3.5.2
  EXPORT_NAME: test-project

jobs:
  export-windows:
    name: Windows Export
    runs-on: ubuntu-20.04
    container:
      image: barichello/godot-ci:3.5.2
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          lfs: true
      - name: Windows Build
        run: |
          mkdir -v -p build/windows
          godot --headless --verbose --export-release "Windows Desktop" ../build/windows/$EXPORT_NAME.exe
      - name: Upload Artifact
        uses: actions/upload-artifact@v1
        with:
          name: windows
          path: build/windows

  export-linux:
    name: Linux Export
    runs-on: ubuntu-20.04
    container:
      image: barichello/godot-ci:3.5.2
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          lfs: true
      - name: Linux Build
        run: |
          mkdir -v -p build/linux
          godot --headless --verbose --export-release "Linux/X11" ../build/linux/$EXPORT_NAME.x86_64
      - name: Upload Artifact
        uses: actions/upload-artifact@v1
        with:
          name: linux
          path: build/linux

  export-web:
    name: Web Export
    runs-on: ubuntu-20.04
    container:
      image: barichello/godot-ci:3.5.2
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          lfs: true
      - name: Web Build
        run: |
          mkdir -v -p build/web
          godot --headless --verbose --export-release "HTML5" ../build/web/index.html
      - name: Upload Artifact
        uses: actions/upload-artifact@v1
        with:
          name: web
          path: build/web
      - name: Install rsync 📚
        run: |
          apt-get update && apt-get install -y rsync
      - name: Deploy to GitHub Pages 🚀
        uses: JamesIves/github-pages-deploy-action@releases/v4
        with:
          branch: gh-pages # The branch the action should deploy to.
          folder: build/web # The folder the action should deploy.

  export-mac:
    name: Mac Export
    runs-on: ubuntu-20.04
    container:
      image: barichello/godot-ci:3.5.2
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          lfs: true
      - name: Mac Build
        run: |
          mkdir -v -p build/mac
          godot --headless --verbose --export-release "Mac OSX" ../build/mac/$EXPORT_NAME.zip
      - name: Upload Artifact
        uses: actions/upload-artifact@v1
        with:
          name: mac
          path: build/mac

Wrote my own github CI pipeline for Godot 3.5.3. Recommend doing the same

Thanks for the report! Consolidating in https://github.com/abarichello/godot-ci/issues/121, as this is due to the same cause: https://github.com/abarichello/godot-ci/issues/121#issuecomment-2016653286


Could /etc/hosts be cleaned without losing other changes?

We use kubefwd in combination with Glasses (actually an alternative build k8s-ingress-hosts). When kubefwd exits it will reset changes made by Glasses as well. Glasses on the contrary removes only its own entries.
What glasses does is it generates markers # generated using glasses start # and # generated using glasses end # (see also https://github.com/solsson/k8s-ingress-hosts/commit/ae424643e32f0ce2188a468ef196e53fadf7c2e1). Could kubefwd do the same thing?

kubefwd only removes hostnames it adds. If those same hostnames already exist or duplicates are added you will get unexpected behavior.
I do need to perform some checks to ensure a hostname does not already exist and probably issue a prompt if a user wishes to overwrite it. If kubefwd is removing entries added by another system then they are duplicate entries. For example, if kubefwd added "<IP_ADDRESS> grafana.local" it will remove the entry "portal" since technically there should only be one and it would have been added by kubefwd. If another system adds for example "<IP_ADDRESS> grafana.local" then you have duplicate entries, and your system will only use the first one. The expected behavior is dependant on execution order (a race condition).
Having multiple systems write to /etc/hosts concurrently is always going to be a risk.
Another check I can do would be to limit removing a hostname if it is assigned to an IP outside of the expected range and again this would need to warn the user of unexpected behavior.

Hi @cjimti,
Super cool tool you've built here! I thought I'd clarify @solsson's issue with some more insights:
We have two different tools writing to /etc/hosts. They don't write to the file concurrently, but I've noticed that kubefwd seems to save a "backup" file at $HOME/hosts.backup which I guess is used for removing the lines kubefwd adds.
This scenario reproduces the issue we're having:

kubefwd svc ...
In a new terminal: echo "<IP_ADDRESS> dev.local" >> /etc/hosts
Cancel kubefwd
My line from the second step is gone

The same problem seems to arise wherever I add a new line, not just if I put it at the bottom of /etc/hosts.
Please let us know if this is anything that you plan on supporting. Thanks in advance!

$HOME/hosts.backup is only created once as a safety-net and is not used. It is only created again if the user deletes it.
Unless kubefwd previously added dev.local it is a bug. I'll look at this today! If you are curious, I use txeh to manage /etc/hosts.

@solsson @atamon I confirmed the condition you reported. kubefwd needs to reload current the /etc/hosts content before it cleans it. It should be an easy fix and I can add it after reviewing a PR that involves this part of code as well.
Thanks for finding this. :thumbsup:

@cjimti :beers:
Thanks for the quick replies and thorough explanations!

Thank you for the bug report. This should now be fixed in the release 1.9.1.


Changed database path to /postgres instead of /gw

@Alanle1011 review this for me

@Alanle1011 please review this


Unexpected Revert on Test

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[ ] Foundryup

What version of Foundry are you on?
forge 0.2.0 (66ef1ae 2022-08-11T15:42:20.650087337Z)
What command(s) is the bug in?
test
Operating System
Linux
Describe the bug
Reverting on a transfer command on a very simple contract. The contract is basically just a bank account where anyone can "topup" or "withdraw" from the balance:
contract Example {

    function topUp() external payable {}

    function withdraw(uint256 amount) external {
        require(
            amount <= address(this).balance,
            "Cannot withdraw more than is within the contract"
        );

        payable(msg.sender).transfer(amount);
    }
}

This is the test:
contract ExampleTest is Test {

    Example public account;
    address public acc1;

    constructor () {
        acc1 = address(0x1);
        account = new Example();
    }

    function testItWorks() public {
        vm.deal(acc1, 25);
        vm.startPrank(acc1);
        account.topUp{ value : 25 }();
        account.withdraw(25);
        vm.stopPrank();
    }
}

account.withdraw causes a reversion (unexpected), here are the traces:
Traces:
  [52308] ExampleTest::testItWorks()
    ├─ [0] VM::deal(0x0000000000000000000000000000000000000001, 25)
    │   └─ ← ()
    ├─ [0] VM::startPrank(0x0000000000000000000000000000000000000001)
    │   └─ ← ()
    ├─ [96] Example::topUp{value: 25}()
    │   └─ ← ()
    ├─ [34422] Example::withdraw(25)
    │   ├─ [0] PRECOMPILE::ecrecover{value: 25}()
    │   │   └─ ←
    │   └─ ← "EvmError: Revert"
    └─ ← "EvmError: Revert"

I have tried running with --debug but cannot seem to find what's causing the issue. I have deployed the contract and it works as expected. I'm confused because I have implemented similar functionality in other contracts and testing has gone fine.
Please let me know if I have made any errors with my testing and/or writing the contract.
Thanks,
Ben

You can't use address(n) where n <= 10 since those are precompile addresses.


fix: supports container-id  prefix matching with 12 or more characters

LGTM. Thank you for your contribution.


BUG REPORT INFORMATION: cgroup error on fresh Amazon AMI on EC2

A similar issue has been discussed here: https://github.com/docker/docker/issues/8791
Steps to reproduce:

Start up an EC2 micro, using Amazon AMI

sudo passwd

su -

yum -y update

yum -y install docker

docker -d &

docker info

Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-202:1-263725-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 305.7 MB
 Data Space Total: 107.4 GB
 Data Space Available: 6.632 GB
 Metadata Space Used: 729.1 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 3.14.35-28.38.amzn1.x86_64
Operating System: Amazon Linux AMI 2015.03
CPUs: 1
Total Memory: 996.3 MiB
Name: ip-172-30-4-184
ID: NHAM:7CNT:AZEB:IE7G:JMBN:2AB7:M2CU:KDYF:7LIL:6ZAP:YHMX:5RLN
WARNING: No memory limit support
WARNING: No swap limit support

docker version

Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.3.3
Git commit (client): 7c8fca2/1.6.2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.3.3
Git commit (server): 7c8fca2/1.6.2
OS/Arch (server): linux/amd64

cat > Dockerfile

FROM centos:7.1.1503
MAINTAINER XXX XXX<EMAIL_ADDRESS>RUN yum -y install tar

docker build -t docker.io/XXX/XXX .

Sending build context to Docker daemon 9.216 kB
Sending build context to Docker daemon
Step 0 : FROM centos:7.1.1503
7.1.1503: Pulling from centos

f1b10cd84249: Pull complete
c43c1996cf18: Pull complete
f1dade627e25: Already exists
centos:7.1.1503: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.

Digest: sha256:76e269d9b5630806c3b714360e47e5cb01a1943bd987f5c2c99ce0248e7cddca
Status: Downloaded newer image for centos:7.1.1503
 ---> f1dade627e25
Step 1 : MAINTAINER XXX XXX<EMAIL_ADDRESS> ---> Running in 568ed7da89c5
 ---> afeaf86cbdf3
Removing intermediate container 568ed7da89c5
Step 2 : RUN yum -y install tar
 ---> Running in 5a306473efa6
INFO[0011] [8] System error: mountpoint for cgroup not found

Why am I getting this cgroup error?
The same thing does not happen on CentOS 7.1 with the following docker version:
Client version: 1.6.0
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 8aae715/1.6.0
OS/Arch (client): linux/amd64
Server version: 1.6.0
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): 8aae715/1.6.0
OS/Arch (server): linux/amd64

So, is there an issue in 1.6.2 or is this an issue with the Amazon AMI? The Amazon AMI ought to be very tested thought...?
Thanks!
{XXX left out on purpose}
UPDATE: Same issue also with centos:latest
UPDATE:

uname-a

Linux ip-172-30-4-184 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

@LEETcc Can you run pls contrib/check-config.sh script on that machine?

wget https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh
chmod +x check-config.sh
./check-config.sh

warning: /proc/config.gz does not exist, searching other paths for kernel config...
info: reading kernel config from /boot/config-3.14.35-28.38.amzn1.x86_64 ...

Generally Necessary:
- cgroup hierarchy: nonexistent??
    (see https://github.com/tianon/cgroupfs-mount)
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_DEVPTS_MULTIPLE_INSTANCES: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: enabled
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MACVLAN: missing
- CONFIG_VETH: enabled (as module)
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: enabled
- CONFIG_NF_NAT_IPV4: enabled (as module)
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: enabled
- CONFIG_POSIX_MQUEUE: enabled

Optional Features:
- CONFIG_MEMCG_SWAP: enabled
- CONFIG_MEMCG_SWAP_ENABLED: enabled
- CONFIG_RESOURCE_COUNTERS: enabled
- CONFIG_BLK_CGROUP: enabled
- CONFIG_IOSCHED_CFQ: enabled (as module)
- CONFIG_CGROUP_PERF: enabled
- CONFIG_CFS_BANDWIDTH: enabled
- Storage Drivers:
  - "aufs":
    - CONFIG_AUFS_FS: missing
    - CONFIG_EXT4_FS_POSIX_ACL: enabled
    - CONFIG_EXT4_FS_SECURITY: enabled
  - "btrfs":
    - CONFIG_BTRFS_FS: enabled (as module)
  - "devicemapper":
    - CONFIG_BLK_DEV_DM: enabled (as module)
    - CONFIG_DM_THIN_PROVISIONING: enabled (as module)
    - CONFIG_EXT4_FS: enabled (as module)
    - CONFIG_EXT4_FS_POSIX_ACL: enabled
    - CONFIG_EXT4_FS_SECURITY: enabled
  - "overlay":
    - CONFIG_OVERLAY_FS: missing
    - CONFIG_EXT4_FS_SECURITY: enabled
    - CONFIG_EXT4_FS_POSIX_ACL: enabled
  - "zfs":
    - /dev/zfs: missing
    - zfs command: missing
    - zpool command: missing

Thanks for helping!

This is a fresh AWS machine that I set up only to reproduce the error. Happy to give you root access so you can look around yourself. Email me on info ...at) leet  (dot) cc if you want to do that.

@LEETcc
- cgroup hierarchy: nonexistent??
(see https://github.com/tianon/cgroupfs-mount)

You should try this script to mount cgroups. You can see if they mounted with mount command.

I see, okay. Thanks!


fix wrong fbit config during tests

Fix invalid pipeline config used during tests.

Uhhh, nice. We got a panic https://github.com/calyptia/api/runs/7961711404?check_suite_focus=true#step:7:172


Serve over HTTPS

Github now makes this easy with a simple configuration toggle (IIUC): https://github.com/blog/2186-https-for-github-pages
This is required for proper embedding on tldr-pages.github.io

Good point! Need to figure out the HTML5 PushState routing around that. AFAIK, can't be done from Github Pages, that's why I have the site hosted on Amazon S3. I might be able to get a * certificate for my domain.
The other option would be to go all in, and host the whole thing (client and landing page) as one on Github.

In the meantime, https://github.com/tldr-pages/tldr-pages.github.io/commit/260a8ba04a6c1314e69f2206137e8188f16b7d09 fixes the iframe src.

Ok, although the iframe still doesn't work if the tldr website is loaded over https (in Chome at least). Anyway, sorry for jumping the gun, I forgot about the extra stuff you do under the hood 😇

Have you looked at Let's Encrypt certificates?

Done :) https://tldr.ostera.io/

@waldyrious ah, forgot to add one error redirect (403s -> index) :P to make the permalink work. CloudFront is redeploying the distribution now, should take a few minutes.

Good catch. It appears to be working now :)


swift-api-digester: detect the move of static members only.

This patch restricts the detection of moved members to be static members,
since only in this case we need to update qualified access to
them. The move of instance members will be either handled by rename or
we don't need to update anything at all.
Additionally, this patch introduces a sub-kind of type member diff item
called qualified replacement to describe the aforementioned case. However,
the migrator part has not started to honor this sub-kind yet.
rdar://32466196

@swift-ci please smoke test and merge


Fix flaky tests in async retry by using a latch instead of sleep.

Motivation
In the previous version, all test cases depended on sleep.
However, it made all test cases flaky.
(Please refer to this comment https://github.com/spring-projects/spring-kafka/pull/3523#issuecomment-2419692216)
Modification

Removed sleep.
Used latch instead.

Result

Fixes flaky test cases in AsyncCompletableFutureRetryTopicScenarioTests, AsyncMonoRetryTopicScenarioTests.

To Reviewer,
I removed a test case. that involved a random situation.
However, it is very hard to handle a random situation with a latch.
Therefore, I decided to remove it and create a new test with a more complex scenario.

Thanks for your review, and I apologize for the inconvenience 🙇♂.
I decided to use containsExactlyInAnyOther() instead of containsExactly().
Because, I think an issue which i cannot control seems occurs when kafkaTemplate.send(...)

Looks like some are still non-stable: https://github.com/spring-projects/spring-kafka/actions/runs/11433571335/job/31805772798. Feel free to disable them or remove altogether .

@artembilan , sorry to bother you.
I will remove test codes which required long test times.
Please wait an hour, i'm in office time. i will create a PR!

@chickenchickenlove , no rush. Just sharing with you a status. I don’t think those tests are failing because of some bug in the production code, but more as a design flaw of the tests themselves. Sometimes we are really just cannot model the situation and verify it at the same time. So, that is better to be present as a sample application .
But again : this does not stop us to move on and we can live with the current status a bit.


bug: Copy to clipboard doesn't work

Summary
Right clicking on a log analysis line shows "Copy Ctrl+C, ...," but using "Copy" doesn't work. No log contents are put in the clipboard.
Also, the "Cut" and "Paste" options are shown improperly, as they won't function in this context.
Steps To Reproduce

Run the Apex Log Analyzer on a debug log file.
Click on a line in the log analyzer output to select it, and right click on the selection, and choose "Copy Ctrl+C" or do Ctrl-C directly.
Try to paste the clipboard contents to another document, only to find the contents pasted aren't from the log analysis, so the copy operation failed silently.

Expected result
The clipboard should have been loaded with the selected text for pasting.
Actual result
The clipboard contents are old, not replaced with the selected log analyzer line text.
Additional information
Feel free to attach a screenshot.
VS Code Version: v1.14.1
Log Analyzer Extension Version: v1.14.1
OS and version: Windows 10 Enterprise, version 10.0.19045 Build 19045

Thanks for the report.
The cut, copy, paste context menu is provided by vscode and has default behaviour.
We have limited control over it but we can remove the context menu altogether or hide it in certain situations.
But it does have default behaviour and copies selected text so can be useful in some limited situations.
This is not really a bug but it is a feature gap, we need to handle copy and paste application wide, so I will turn this in a feature and get it targeted to a release.
There is a slight work around for copying text from the grids. You can selected some text with mouse down and then use CMD/ CTRL + C to copy BEFORE releasing mouse down.
If any of the tables have focus CTRL/ CMD+C will copy the full table content to the clipboard, but honestly it is a bit clunky.
Changes
I would suggest a bunch of changes to make copy nicer to use, feedback would be appreciated.

Copy should generally work like the browser (right click will select the highlight word).
Move the Export to CSV from table header menu to dedicated button .
Add a copy to clipboard button for the whole table content.
Allowing copying from the cells in the table (maybe similar to excel, right click will select the whole cel , double click to enter and edit state to select sub set of the text)

Let me know if you have other ideas and thought and I will add them to this 👍🏻


Don't pull inside build (pull and build seperately)

https://keybase.atlassian.net/browse/DESKTOP-2014

Reminder to self, after merging this update the plist on build machine

@cjb


Repository activity still appearing in stream after user removed from repository

First, let me say: I <3 this tool!
I hate using email to stay up-to-date with Github, I find the notifications app much better UX.
Right now though, the tool isn't usable to me, as it is flooded with notifications from a repository which I had been removed as a collaborator.

The requests to the Github API endpoints fail:

Any ideas how to clear this? I have already tried in incognito to see if it was a cache or cookie causing issue...

That sounds like an issue with web notifications.


Set node version for deployment to 13.x

Codecov Report

Merging #110 into master will not change coverage by %.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #110   +/-   ##
=======================================
  Coverage   36.92%   36.92%
=======================================
  Files           5        5
  Lines          65       65
  Branches        7        7
=======================================
  Hits           24       24
  Misses         38       38
  Partials        3        3

Continue to review full report at Codecov.

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


Fixes #1528

Changes
Fixes typo in QML tutorial that said "ramdom" instead of "random".
Closes #1528

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


Revert "Improve components infrastructure (#12145)"

WIP but may be taking this improvement out of preview 8 since it will regress source build.
The problem is that while the environment for source build has NodeJS and Yarn that is required to build Web.JS, it will be missing Javascript dependencies. I missed this since the source build test configuration passed but it's not mimicking the actual environment since it still has access to the network to install packages (and also downloads from packages from myget).
There are several possible approaches to resolve this though none of them seems feasible at the moment:

Check in node_modules. From what I can tell this is probably a non-starter. We'll be checking in way too many files and it's probably against our policy to check in source files from JS packages not written by us.
Use only dependencies from native package repositories. It might be possible to reduce our dependencies to only the js packages available on the distro package repositories such as https://packages.debian.org/stable/javascript/. I'll need to see how viable this approach may be.

@rynowak @SteveSandersonMS can someone help me test this?

cc @javiercn @pranavkm as well in case you can help verify the correctness of the generated js content.

@JunTaoLuo I would suggest you do the following:

pushd src\signalr\clients\ts; yarn install; yarn build; popd
pushd src\components\web.js; yarn install; yarn build; popd
See if blazor.server.js changed on disk.
Open the components solution.
Run all the tests in VS or in the command line.

Tests passed locally.


[WebSocket] Update with latest changes

Addressed the changes with https://github.com/ballerina-guides/websocket-integration/pull/11


Slicing pattern with range

@davidfowl
Does slicing using a range refer to code like this (using '..')?
Span<byte> buffer = ...

Span<byte> view1 = buffer.Slice(3, 2);
Span<byte> view2 = buffer[3..4];

// view1 == view2

@ahsonkhan, do you still want to keep this open?

That depends on whether we want to support range syntax or not.
This was from the initial discussion/backlog of span items where we were considering slicing using range. I presume that is what the syntax would look like.
Changing to future.

@KrzysztofCwalina, if we are getting the Range syntax support by 2.1, we should consider adding support for it for Span. Should we change the milestone of this issue to 2.1? Let me know and I will move it over to corefx.

Yeah, once we settle on the design for Range, we can add APIs. I would not add them sooner.


Idea: Unique Buildings (and possible gameplay plot arc)

I suggested this in issue #67, but I'm pulling it out and deleting it there because it should be its own thing.
Perhaps for a later milestone, create new upgrades -- or a new class of upgrades -- that are different unique Ponyville buildings? The most basic could have effects related to your wheel.
Start with only Pinkie Pie and background ponies unlocked for the wheel.
Train Station - When purchasing a new pony, you may select which one you buy.
Sweet Apple Acres - Unlocks Granny Smith, Applejack, Apple Bloom, Big Mac
Carousel Boutique - Unlocks Rarity, Sweetie Belle
Napping Cloud - Unlocks Rainbow Dash, Scootaloo
Gate to Tartarus - Unlocks Chrysalis, Sombra, other villains
The Friendship Castle - Unlocks alicorns
The Everfree Forest - Unlocks Fluttershy, and ...
... ooh, I just realized this might tie in with the Mirrorpocalypse: maybe you need to unlock the Everfree to be able to explore it and find late-game game-overhaul features like the Pool. That suggests that maybe (some or all) buildings are rewards for resetting after hitting certain muffin targets (or gameplay-time targets)?
This also suggests a possible actual plotline and endgame state beyond simply "earn smiles, get ponies". Ponyville has fallen through a Sadness Vortex (or insert other plot-coupon quest here) and your goal is, with the power of smiles (and muffins), to restore everything back to the way it was. You can have a win state when you buy a certain building (Sugarcube Corner) or when Ponyville is fully restored, and then have that achievable without 100%ing the game so that completionists can continue on past it to complete, and the truly obsessed can just keep going indefinitely in search of smile records.
Other buildings maybe could have effects other than unlocking ponies, but I don't know what yet. Sugarcube Corner, Town Hall, The Library Tree, and Quills and Sofas seem like obvious candidates. Maybe they unlock upgrades, or they're late-game bonuses that are kick-plot upgrades in themselves, or they give you new clicking modes or otherwise freshen the game as the curves are starting to level off. (The Mirror Pool then becomes the secret crazy ultra bonus level.)
Just to add, I really like the idea of an idle clicker game with an actual plot and win state.  I don't think that's actually been done; at any rate, the only ones I've ever played have all been "keep going until you run out of achievements".

I like the general idea here and I think it synergies well with the suggested UI overhaul in #50. However, it's obvious that this would be a significant time investment to implement and require even more advanced analysis and graphs to ensure it is properly balanced. This may require nuking the pony cost curve by setting it on an n^0.9 curve or something, because otherwise the resulting price explosion makes any ponies past 28 almost completely impossible.

To be clear, I'm not suggesting that purchasing buildings adds ponies to the wheel.  I'm suggesting that it adds to the pool of available ponies that clicking "Buy a Pony" might randomly add to your wheel.  The +pony buildings would be cosmetic upgrades.

I think that, as the game currently stands, this would have to be an extremely late game thing. In my game, I've gotten to the point where I can unlock every upgrade and get nonillions to decillions of SPS within 5 minutes of a Reset, and I still haven't really been able to have half the maximum number of ponies I can get in a single session.
Either that, or overhaul the current system of how ponies are generated (which would include a changing maximum of ponies, affect the SPS curve of the game, and potentially screw with existing saves).

Yeah, this would be an amazing addition to this game. I've been playing Adventure Capitalist for the past few weeks, only about 20 min every week.. But I noticed a pattern in the game, almost every item is a 3x more than the previous item. But maybe I'll bring this up on another issue.
But also, the game had a rough storyline.

This should probably be used as the core for a sequel.  Trying to implement it in the current game would require redoing almost everything (production would be too slow in the early game because of the limits on available ponies; if we don't change cost curves for ponies and friendships the cost of ponies is too high in late game to actually get the newly unlocked ponies and the production values for most buildings only work well for the current costs).


2.0 --grid no working?

Greetings,
Could someone confirmed that --grid or -g does save a grid? Not having any effect on Windows so far.

Since the WebGUI doesn't have a grid option, can I assume you are using the command-line interface?
I can confirm that --grid or -g  works for me at the invoke> command line if you invoke it like this:
invoke> an old man and the sea -n6 -g

If you provide -g at the time you launch the script, grids should now become the default:
python3 scripts\invoke.py --grid

If it is not behaving this way, please respond with more information about your platform and install method.

thank you lstein, Not sure why grid cant be used with all images at the same time so I made modification to 1.x before to handle images and grid to be saved by removing else after do_grid or whatnot. That same modification no longer works though, I'm still digging to find why.

the whole logic with grid/individual is funky, not sure that is necessary. Please, consider allowing both grid and images to be saved.

Oh I got it, the grid is overtighten by an image as they have the save name.

Yeah, in fact grid generation should be treated like a post-processing step akin to upscaling and face reconstruction. It's weird now because of the way it was integrated into image generation in the original CompViz code.
We've got a new service-oriented architecture coming along in which each image manipulation step is its own callable node: PR #1047 . I'm hoping that we can turn grid-generation into a discrete post-processing step.


feat(concurrency): implement execute_chunk

This change is

crates/blockifier/src/blockifier/transaction_executor.rs line 160 at r2 (raw file):
Previously, barak-b-starkware wrote…
Done.

It's not the last committed index. It is the first uncommitted index (last_committed_index+1). That is why it is the number of committed transactions (the first index is 0).


chapter13Cannot use the default session to execute operation

n_epochs = 10
batch_size = 40
n_iterations_per_epoch = len(flower_paths_and_classes_train) // batch_size

with tf.Session() as sess:
    init.run()
    inception_saver.restore(sess, INCEPTION_V3_CHECKPOINT_PATH)

    for epoch in range(n_epochs):
        print("Epoch", epoch, end="")
        for iteration in range(n_iterations_per_epoch):
            print(".", end="")
            X_batch, y_batch = prepare_batch(flower_paths_and_classes_train, batch_size)
            sess.run(training_op, feed_dict={X: X_batch, y: y_batch, training: True})

        acc_batch = accuracy.eval(feed_dict={X: X_batch, y: y_batch})
        print("  Last batch accuracy:", acc_batch)

        save_path = saver.save(sess, "./my_flowers_model")

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-85-214dfc6100e5> in <module>
      4
      5 with tf.Session() as sess:
----> 6     init.run()
      7     inception_saver.restore(sess, INCEPTION_V3_CHECKPOINT_PATH)
      8

~/anaconda3/lib/python3.6/site-packages/tensorflow/python/framework/ops.py in run(self, feed_dict, session)
   2448         none, the default session will be used.
   2449     """
-> 2450     _run_using_default_session(self, feed_dict, self.graph, session)
   2451
   2452 _gradient_registry = registry.Registry("gradient")

~/anaconda3/lib/python3.6/site-packages/tensorflow/python/framework/ops.py in _run_using_default_session(operation, feed_dict, graph, session)
   5205                        "`run(session=sess)`")
   5206     if session.graph is not graph:
-> 5207       raise ValueError("Cannot use the default session to execute operation: "
   5208                        "the operation's graph is different from the "
   5209                        "session's graph. Pass an explicit session to "

ValueError: Cannot use the default session to execute operation: the operation's graph is different from the session's graph. Pass an explicit session to run(session=sess).

Can anyone talk to me how to solve this problem?

Hi @Taylor-Tian ,
Thanks for your question. Sorry for the delay, I just got back from vacation.
In TF 1.x a session can only execute one graph. All the operations you ask it to run must come from that one graph. If you ask it to execute an operation that belongs to any other graph, it raises the exception you got. Since the stacktrace shows that the error took place on the line init.run(), we can deduce that the init operation does not belong to the current session's graph.
The init operation is created in cell [62], and it belongs to the default graph (since there is no 'with graph.as_default()block). Moreover, theSessionis created without anygraphas argument, meaning it uses the default graph. So the operation's graph _should_ be the same as the session's graph, i.e., the default graph. So the only explanation I can see is that you reset the graph after creating theinitoperation. In that case, theinit` operation would belong to the old default graph, while the session would use the new default graph.
So please ensure that:

the notebook is exactly like the one in the project, no modified code.
you run all the cells sequentially, especially between cell [54] (when the graph is reset) to cell [78] (when the session runs the graph).

I hope this helps,
Aurélien


slurm cluster module

@soumyapani you have a discussion here with spencer about refs in sources. I used develop for the hpc-toolkit modules used in our slurm-cluster module here -- is that bad?

@soumyapani you have a discussion here with spencer about refs in sources. I used develop for the hpc-toolkit modules used in our slurm-cluster module here -- is that bad?

We should add example env.list, terraform config and HPC toolkit to our example directory.
Let's merge this PR and we can do that in next PR.


GCC first pass (chapter 5.5) - Out of memory

Hello @reinterpretcat! I'm happy to create the first issue here :)
I'm having a problem with the LFS build phase, in particular with chapter 5.5.
A few minutes after script started working on this chapter (at the compilation stage of mpfr), I see a message saying that the container does not have enough memory (a lot of memory allocation errors), I have 16GB of RAM and the same size of the swap partition (video montage my hobbie).
What I just did not try... first I've changed the build directory from /tmp to /build, then I've set the "ulimit" (in bash and docker-compote.yml), yeah I've also rewriten some things to docker-compose (especially for mounting external directories and storing as little data as possible in the container).
https://github.com/EvilFreelancer/lfs/blob/master/docker-compose.yml
Funniest thing is that if I take only scripts and configure a normal virtual machine (virtualbox), then GCC compilation complete without problems.
~ $ docker -v
Docker version 18.02.0-ce, build fc4de44

~ $ docker-compose -v
docker-compose version 1.17.0, build ac53b73

~ $ free -h
              total        used        free      shared  buff/cache   available
Mem:            15G        7,8G        271M        300M        7,5G        7,4G
Swap:           15G         37M         15G

According to my observations, the docker does not know how to manage memory, perhaps this is due to the fact that I installed an unstable binary package (18.02)

Hi EvilFreelancer,
Hard to say what is the reason of the issue in your case.. I was running scripts on my environment with less physical memory (12Gb Ubuntu 17.10 and 10Gb Ubuntu 16.04) without OoM exceptions.
To debug scripts, I used to create an image from stopped container which exited due to an issue. Then I could start a new container with modified entrypoint running sh shell.
I guess this approach might help you to understand how to fix the issue on your environment without rerunning all scripts again.

Yeah, I've found what issue in memory after few reruns, fast solution to make this:
cd /mnt/lfs/sources
sh /mnt/lfs/scripts/prepare/5.5-make-gcc.sh

Maybe issue with new docker, what you you think? What version of your docker (probably my problem is here)?

On Ubuntu 16.04 I have:
 Docker version 17.05.0-ce, build 89658be

Hello!
I've checked build process on 17.05 verions of Docker and seems I was right, bug with memory usage in 18 version. Maybe need to add some note about this into the readme file?

The second thing, almost all fine, but seems you forgot set absolute path of the /dev/loop2 device inside scripts/image/2.create-ramdisk.sh file:
Start building bootable image..
/tmp /mnt/lfs/sources
Configuring syslinux..
Creating ramdisk..
800000+0 records in
800000+0 records out
819200000 bytes (819 MB) copied, 2.19472 s, 373 MB/s
losetup: /dev/loop2: failed to set up loop device: No such file or directory
I'll send PR with this to you :)

thanks, PR will be great :)


SO-4113: authorization improvements

This PR introduces new authorization options to allow/restrict access to server resources.
Access tokens describe the necessary scopes to give access to certain resources, either by:

directly denoting the resource ID in the scope
denoting the containing bundle ID in the scope (direct bundleId parent for now)
or by allowing access to all resources (*)

GetResourceRequest should also implement AccessControl, the same way as UpdateRequest does; I think I saw some sub-classes in the other repository where the implements keyword was removed entirely.

Unfortunately, we cannot apply the same pattern there because certain subclasses (like CodeSystemGetRequest) should NOT check for access control. Instead, they will do it using the internal search request and its security filter. What I could do instead is to introduce a new subclass that implements the same logic as the UpgradeRequest, but with the browse scope, but certain get requests require other scopes like ClassificationGetRequest, which require a non-default scope, which would further increase the complexity of that hierarchy, so I have decided to ditch the idea.

@apeteri fixed (or answered) all requested changes (comments).

Codecov Report

Merging #880 (8a8f89d) into 8.x (5900031) will increase coverage by 0.14%.
The diff coverage is 50.00%.

@@             Coverage Diff              @@
##                8.x     #880      +/-   ##
============================================
+ Coverage     62.46%   62.61%   +0.14%
- Complexity    11465    11520      +55
============================================
  Files          1709     1712       +3
  Lines         55001    55072      +71
  Branches       5267     5274       +7
============================================
+ Hits          34359    34485     +126
+ Misses        18467    18401      -66
- Partials       2175     2186      +11

Impacted Files
Coverage Δ

...onal/snowowl/core/authorization/AccessControl.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...owowl/core/branch/AbstractBranchChangeRequest.java
88.75% <ø> (ø)

...ional/snowowl/core/branch/BranchCreateRequest.java
92.85% <ø> (ø)

...ional/snowowl/core/branch/BranchDeleteRequest.java
100.00% <ø> (ø)

...national/snowowl/core/branch/BranchGetRequest.java
100.00% <ø> (ø)

...ional/snowowl/core/branch/BranchReopenRequest.java
0.00% <ø> (ø)

...ional/snowowl/core/branch/BranchSearchRequest.java
83.72% <ø> (ø)

...ional/snowowl/core/branch/BranchUpdateRequest.java
77.77% <ø> (ø)

...tional/snowowl/core/branch/DeleteMergeRequest.java
0.00% <ø> (ø)

...rnational/snowowl/core/branch/GetMergeRequest.java
75.00% <ø> (ø)

... and 92 more

Continue to review full report at Codecov.

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

EclSerializerTest failed in a previous CI build (NullPointerException was thrown in a Promise instead of concepts being returned), but it does not seem to be related to authorization changes. The concept search request invoked has a User instance registered with permissions in its context.


functional: sleep shortly to avoid errors in TestScheduleOneWayConflict

In TestScheduleOneWayConflict, after destroying conflicts-with-hello.service, we need to sleep shortly to avoid occasional errors of conflicts-with-hello.service being rescheduled even after being destroyed. In that case, the conflicts unit remains active, while the original
hello.service remains inactive. Then the test TestScheduleOneWayConflict fails at the end with a message "Incorrect unit started". This error seems to occur frequently when enable_grpc turned on.
This sleep is just a workaround. We should find out the long-term solution.
Also note that, before commit 8cfc189e ("Functional tests: Fix race condition in TestScheduleOneWayConflict()"), this error didn't occur, because there was already a sleep for 5 seconds in place. However, the commit 8cfc189e tried to fix a race using util.WaitForState(), also by removing the original sleep. Actually the commit didn't completely fix the race, so the hidden bug started to reappear.

Unless anyone has a better idea, I'll merge it tomorrow.