Sanity Check Fails:

Describe the bug
A clear and concise description of what the bug is.
I wanted to contribute to the zephyr, therefore I ran sanity check on my local repo before creating PR. but it failed on my local version of repo.
What have you tried to diagnose or workaround this issue?
I tried to select specific board and tried again the sanity check but failed again.
To Reproduce
Steps to reproduce the behavior:

mkdir build; ./scripts/sanitycheck
cmake -DBOARD=any
make
See error

Expected behavior
A clear and concise description of what you expected to happen.
The test should successfully run on the system.
Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)
I am not able to create PR because of this check.
Screenshots or console output
If applicable, add a screenshot (drag-and-drop an image), or console logs
(cut-and-paste text and put a code fence (```) before and after, to help
explain the issue.
Renaming output directory to /home/tahir/zephyr-latest2/https:/github.com/mtahirbutt/zephyr/zephyr/sanity-out.9
INFO    - JOBS: 1
INFO    - Selecting default platforms per test case
INFO    - Building initial testcase list...
INFO    - 4183 test configurations selected, 201981 configurations discarded due to filters.
INFO    - Adding tasks to the queue...
ERROR   - cc1352r1_launchxl         samples/boards/ti/cc13x2_cc26x2/system_off/sample.boards.ti.cc13x2_cc26x2.system_off FAILED: Build failure
ERROR   - see: /home/tahir/zephyr-latest2/https:/github.com/mtahirbutt/zephyr/zephyr/sanity-out/cc1352r1_launchxl/samples/boards/ti/cc13x2_cc26x2/system_off/sample.boards.ti.cc13x2_cc26x2.system_off/build.log
INFO    - Total complete:    1/4183   0%  skipped:    0, failed:    1
ERROR   - sensortile_box            samples/boards/sensortile_box/sample.board.sensortile_box.sensors FAILED: Build failure
ERROR   - see: /home/tahir/zephyr-latest2/https:/github.com/mtahirbutt/zephyr/zephyr/sanity-out/sensortile_box/samples/boards/sensortile_box/sample.board.sensortile_box.sensors/build.log
INFO    - Total complete:    2/4183   0%  skipped:    0, failed:    2
ERROR   - bbc_microbit              samples/boards/bbc_microbit/sound/sample.board.bbc_microbit.sound FAILED: Build failure
.................................................................................................................................
Environment (please complete the following information):

OS: (e.g. Ubuntu 18.04.4 LTS)
Toolchain (e.g Zephyr SDK 0.11.2)
Commit SHA: 251cb61e20e4a50116f03f82029413df7ce31d4e, zephyr-2.3-rc1

Additional context
Add any other context about the problem here.

mkdir build; ./scripts/sanitycheck
cmake -DBOARD=any
make
See error

Are you really running this? any is not a valid board

mkdir build; ./scripts/sanitycheck
cmake -DBOARD=any
make
See error

Are you really running this? any is not a valid board

what i meant. I just used ./scripts/sanitycheck which considered all the boards during the check and created log there.

@mtahirbutt which SHA of zephyr are you using? This builds fine locally for me:
$ west build -b cc1352r1_launchxl samples/boards/ti/cc13x2_cc26x2/system_off/
-- west build: generating a build system
-- Application: /home/carles/src/zephyr/zephyr/samples/boards/ti/cc13x2_cc26x2/system_off
-- Zephyr version: 2.3.0-rc1 (/home/carles/src/zephyr/zephyr)
-- Found Python3: /usr/bin/python3.8 (found suitable exact version "3.8.2") found components:  Interpreter
-- Board: cc1352r1_launchxl
-- Found toolchain: zephyr (/home/carles/bin/zephyr-sdk)
-- Found west: /home/carles/.local/bin/west (found suitable version "0.7.2", minimum required is "0.7.1")
-- Found dtc: /home/carles/bin/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found BOARD.dts: /home/carles/src/zephyr/zephyr/boards/arm/cc1352r1_launchxl/cc1352r1_launchxl.dts
-- Generated zephyr.dts: /home/carles/src/zephyr/zephyr/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /home/carles/src/zephyr/zephyr/build/zephyr/include/generated/devicetree_unfixed.h
Parsing /home/carles/src/zephyr/zephyr/Kconfig
Loaded configuration '/home/carles/src/zephyr/zephyr/boards/arm/cc1352r1_launchxl/cc1352r1_launchxl_defconfig'
Merged configuration '/home/carles/src/zephyr/zephyr/samples/boards/ti/cc13x2_cc26x2/system_off/prj.conf'
Configuration saved to '/home/carles/src/zephyr/zephyr/build/zephyr/.config'
Kconfig header saved to '/home/carles/src/zephyr/zephyr/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/carles/bin/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Cache files will be written to: /home/carles/.cache/zephyr
-- Configuring done
-- Generating done
-- Build files have been written to: /home/carles/src/zephyr/zephyr/build
-- west build: building application
[1/139] Preparing syscall dependency handling

[134/139] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       18208 B     360360 B      5.05%
      FLASH_CCFG:          88 B         88 B    100.00%
            SRAM:        5000 B        80 KB      6.10%
        IDT_LIST:         120 B         2 KB      5.86%
[139/139] Linking C executable zephyr/zephyr.elf

I tried ./scripts/sanitycheck as mentioned in the zephyr website. but I stopped using that for now and will use online submission. if anything happes i will see this again. I used 251cb61, zephyr-2.3-rc1

OK, closing this for now then


feat: initial implementation of ERC1046

🚀 Description
This is the initial implementation of ERC1046, which adds (optional) tokenURI to ERC20 tokens to allow them to exist on-par with ERC721 tokens.
https://eips.ethereum.org/EIPS/eip-1046

[x] 📘 I've reviewed the OpenZeppelin Contributor Guidelines
[x] ✅ I've added tests where applicable to test my new functionality.
[x] 📖 I've made sure that my contracts are well-documented.
[x] 🎨 I've run the JS/Solidity linters and fixed any issues (npm run lint:all:fix).

👍


Respect kind property

The current code escapes the markdown regardless of if the kind property is set to markdown.
This PR updates it to skip escaping the string if it is supposed to be markdown.

Thanks @avigoldman !


Improve unstable API badges

Unstable APIs currently get a badge highlighting the fact that they are unstable. However, it's hard to tell what exactly is being referenced given its size and where it appears.
This badge should appear on the same line as the api that is unstable (flex flex-row gap-3 items-center) and the label itself should be slightly adjusted (px-2 py-1.5 text-base) so it's size is more appropriate as a label for the adjacent text.

note to re-consider cases where multiple badges may be used here.


With the latest version, context menu is not working

My application was installed with latest d3-context-menu which is 1.0.1. Unfortunately, context menu has stopped working and doesn't spit any errors.
Verified with previous versions, worked alright!

I started to see the same problem. It is because in d3-context-menu.js where it makes it visible:
// display context menu
d3.select('.d3-context-menu')
.style('left', (d3.event.pageX - 2) + 'px')
.style('top', (d3.event.pageY - 2) + 'px')
.style('display', 'block');  <--- THIS LINE DOES NOT EXISTS IN THE LATEST VERSION, MENU WILL STAY HIDDEN
			d3.event.preventDefault();

@manikumarrepuri  @adrianbota

@terocohu What browser are you using? And you can confirm that adding that line back causes the menu to work correctly again?
The menu seems to work fine for me with and without the line (both in Firefox and Chrome on Mac). I'm not sure why it was taken out, but if it fixes the problem you're encountering I can put it back in.

Hi Patorjk,
Thanks for the quick response.
I confirm that adding that line fixes this issue at least in Chrome, Safari and Firefox browser (running in Mac), where it is broken without it.
If you check the element in element inspector, it is missing the display: block, when this problem occurs.
For a while I was wondering why I got inconsistent results on my and on our server machine. That turnout to be issue of caching the bower_components on my machine where server got always the latest. Could you be experiencing also that?
Please put that line back.
I also experience the problem, that I cannot request a certain (0.1.2) version of the package (causes . Only the "latest" works).
That shows error:
_$ node_modules/bower/bin/bower install --allow-root
bower not-cached    https://github.com/patorjk/d3-context-menu.git#0.1.2
bower resolve       https://github.com/patorjk/d3-context-menu.git#0.1.2
bower ENORESTARGET  No tag found that was able to satisfy 0.1.2
Additional error details:
No versions found in https://github.com/patorjk/d3-context-menu.git
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command._
I get the same result also if I fix to version 1.0.1 which is supposedly the latest.

I'll update the package and repo tonight with that line added back in.
I've been looking into the bower issue, I'm not sure what's causing it (there's another issue open about it). Installing the latest version works, though trying to get a version by its version number leads to an error. However, you can still install by the commit number and it'll work that way (ex: "bower install d3-context-menu#9b9c146", from: https://github.com/patorjk/d3-context-menu/commits/master).

Thank you so much.
-Mani
On Feb 2, 2018 2:26 PM, "patorjk"<EMAIL_ADDRESS>wrote:

I'll update the package and repo tonight with that line added back in.
I've been looking into the bower issue, I'm not sure what's causing it
(there's another issue open about it). Installing the latest version works,
though trying to get a version by its version number leads to an error.
However, you can still install by the commit number and it'll work that way
(ex: "bower install d3-context-menu#9b9c146", from:
https://github.com/patorjk/d3-context-menu/commits/master).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/patorjk/d3-context-menu/issues/36#issuecomment-362597835,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATt7zDweyRVQoZR_hh97i0KO7aDWFu8Rks5tQxjAgaJpZM4Rwijw
.

Updated in version 1.0.2.

@terocohu are you sure your code/css doesn't hide the context menu? To me, that .style('display', 'block') doesn't make sense with the latest code, because the d3-context-menu is no longer hidden either from css or js, instead it's appended to the DOM when shown, and then removed from the DOM when hidden. We have version 1.0.1 working in a staging environment and it has been tested thoroughly. We haven't seen this issue.
Also I had not trouble installing v 0.1.2 via npm using npm install<EMAIL_ADDRESS>Bower installation should probably be deprecated, even their official websites suggests that there are better alternatives these days: https://bower.io/ see ...psst! While Bower is maintained, we recommend using Yarn and Webpack for front-end projects read how to migrate!

Also I suggest clearing the caches:

browser cache after upgrading and running the latest version
npm cache (delete node_modules and npm install again)
bower cache (bower cache clean)

Also make sure you don't need admin privileges to run the commands (you might need to run the install commands with sudo)

Hi,
I do not have more time to investigate the root cause. What I experienced
on my Firefox, Chrome and Safari browsers, I have shared. Caching was not
an issue. I manually deleted the library and installed it. The only change
I made was the one I have described.
After your fix was deployed (adding the display: block) our server
environment version started to work again, so I can confirm that it does
make a change for what ever reason.
Perhaps would be enough to set display: block in the css.
Br,
Tero
www.spacenation.org
Tero Viitala-Kiss
CTO
+358 5 <+358%2040%205673344>0 486 9473
<EMAIL_ADDRESS>Skype: terinko
Unearth your potential. Discover your Space. No Borders.
On Sun, Feb 4, 2018 at 11:33 PM, Adrian Bota<EMAIL_ADDRESS>wrote:

Also I suggest clearing the caches:

browser cache after upgrading and running the latest version
npm cache (delete node_modules and npm install again)
bower cache (bower cache clean)

Also make sure you don't need admin privileges to run the commands (you
might need to run the install commands with sudo)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/patorjk/d3-context-menu/issues/36#issuecomment-362941662,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ86FwoNwPnQb6yRqdsPicS9My6LBSKGks5tRiIVgaJpZM4Rwijw
.


Enable Asynchronous Munchkin Script

Enable Asynchronous Munchkin Script for embedded Marketo Munchkin tracking.

LGTM, will merge on 🍏


Update mappluto.yml with as_wkt

Adding as_wkt for mappluto yml template file

@SSimon16  before merging make sure you also
include the schema json file in a schemas folder here
https://github.com/NYCPlanning/db-pluto


[Map] MH-Malus_Keep

URL: https://unrealarchive.org/maps/unreal-tournament/monster-hunt/M/mh-malus_keep_cd7fb063.html
Hash: cd7fb063d03828373a523d4fe2f609d2e367ba6e
Current name: MH-Malus_Keep
This is not a playable MH map - it consists of a 'flight' through the Keep and looks to me like a Demo map for the maker's textures.  The flight ends in a dungeon with 'real' krall that kill the player - restarting the map results in the death of the player presumably because the start of the map is a 'void'.  There is a playable version of this I think but this isn't it.  Probably best placed in Demos?

Set to Tests and Demos


Yahoo validation is not working now

Hi,
Recently, the yahoo validation is not working but it was working before, could you check it ?

doesn't work for gmail also though it used too.

`    private function get_yahoo_cookies(){
$this->debug[] = 'Attempting to get the cookies from the sign up page...';
if($this->yahoo_signup_page_content !== false){
$this->debug[] = 'Extracting cookies from headers...';
$cookies = array();
foreach ($this->yahoo_signup_page_headers as $hdr) {
if (preg_match('/^(Set-Cookie|set-cookie):\s*(.?;).?$/', $hdr, $matches)) {
$cookies[] = $matches[2];
}
}
    if(count($cookies) > 0){
      $this->debug[] = 'Cookies found: '.implode(' ', $cookies);
      return $cookies;
    }
    else{
      $this->debug[] = 'Could not find any cookies.';
    }
  }`

      if (preg_match('/^(Set-Cookie|set-cookie):\s*(.*?;).*?$/', $hdr, $matches)) {
        $cookies[] = $matches[2];

Replace line 278 and 279 with this.

@v1ra1  It still doesn't work! can you help?

Fixed. see v1.0.8


Master tests

I've updated tests for master. I've also updated the micro_dl codebase since the current master was broken for certain use cases like segmentation and 3D inference.
I've also updated some packages to avoid errors and upgrade soon to be obsolete functions. Updated packages are:

matplotlib
pandas
skimage

While I hope my changes to the codebase will not break anything for the way you're currently running microDL, the tests don't cover everything so it would be great if someone could test and see if everything still runs as expected for some current data. I look forward to your feedback. Thanks!

@smguo @JohannaRahm I rebased this branch with respect to master. I had to make some changes to Johanna's code to make it work with 3D data and metrics orientations other than xy. Please let me know if you'd like to review again, otherwise I'll merge to master.

Since nobody is jumping on this exciting opportunity to do a re-review, I'm merging. :-)


Add way to specify coverage file format

:zap: Summary
It would be great if the coverage reporter had a way to specify the format of the coverage file, rather than relying on detection from the filename.
Background
After upgrading from coverallsapp/github-action@v1 to coverallsapp/github-action@v2 my .NET projects which use coverlet to produce coverage results in lcov format fail to upload the coverage to coveralls with an error similar to the following:

⚠ Coverage reporter does not yet know how to process this file: NetCoreProject.UnitTests/TestResults/a4c52cc8-0a0c-4d2e-aacd-e6aa12cdeef6/coverage.info

Example with v1 and with v2.
This occurs because coverage.info does not match the filename patterns coverage-reporter expects.  Unfortunately, it's not possible to change the name produced by coverlet (see https://github.com/coverlet-coverage/coverlet/issues/1276 ) so an extra build step is currently required to rename coverage.info to lcov.info to satisfy coverage-reporter.  It would be great if there were a way to avoid this hassle.

Hey! Thank you for the issue. I've recently released a new version of coverage-reporter and updated Github action v2 tag. Now you can specify format: lcov, and the reporter should use it to parse the report.
Now this setup should work:
- uses: coverallsapp/github-action@v2
  with:
    file:  NetCoreProject.UnitTests/TestResults/a4c52cc8-0a0c-4d2e-aacd-e6aa12cdeef6/coverage.info
    format: lcov

Please, feel free to reopen this issue or open a new one if you face any problems.

Looks perfect!  Thanks for the lightning-fast fix @mrexox!


Use express session for storage of user's auth data

Use express session for storage of user's auth data

I can work on this issue. Please assign me


Reobfuscate

For distributing compiled jars to be used in non dev-enviroments the jars need to be reobfuscated,
I don't know how and couldn't find information on how to do so.

fixed in 89ec9466ef3b4210b68f4a2c62b41f179fdcc0b9


Remove check that only shows Service Level option on non-EU firmwares

There looks to be an issue where the service level can be set to 1 in the EU firmware, without this option this can not be corrected.

Shouldn't this be fixed on evse fw? As there's no such thing as service
level in Europe, it was really confusing.
Le mer. 25 oct. 2023, 20:41, Glyn Hudson @.***> a
écrit :

Merged #15 https://github.com/OpenEVSE/openevse-gui-v2/pull/15 into
master.
—
Reply to this email directly, view it on GitHub
https://github.com/OpenEVSE/openevse-gui-v2/pull/15#event-10771082274,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADXKVP5DODAAV5WE2EDBITYBFMNNAVCNFSM6AAAAAA6MU4CIOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJQG43TCMBYGIZDONA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Yes, but the EVSE firmware is not easily updatable so we have to do something for them. Maybe we can add something to the WiFi firmware to correct the issue but this is a quick fix for now


Added 2 managed preferences

In groups where not everyone should be allowed to use admin privileges these settings will restrict the use of the Privileges app and cli to only members of a group or to a single user.
AllowForUser and AllowForGroup
This will allow for an organization to control this with an MDM such as Jamf. By having the AllowForUser the MDM could have a single profile with a variable. Jamf allows you to use $USERNAME to specify the documented primary user of the system as controlled by Jamf and when the profile is deployed with contain the value for that user.
  <key>AllowForUser</key>
  <string>$USERNAME</string>
  <key>AllowForGroup</key>
  <string>privileges_user</string>

 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.Nestor, Michael P 123613304 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Will be implemented in Privileges 1.0.6. Thanks for the feedback.

Adding these features to a future version of Privileges. Thanks!


Added expiry to Redis backend

Added expiry time option
Removed asserts
Added documentation

Thanks!
Let's focus on expiration feature only in this PR and refactor it as the next step.


How to change the grid color , hide it under the chart and decide which axis to show in victory chart

How to change the grid color, hide it under the chart and decide which axis to show in victory chart

Here's an example that might help: https://codesandbox.io/s/sub-grid-styles-0zxv8


Fix for not being able to fly as a bat

Well, I hope this will fix it
https://github.com/Budschie/BudschieMorphMod/issues/50

Praying for @Budschie to kindly notice that)

Merged :+1:

Can't wait for the 1.16.5 release of the update)


Support toml source

fix(bin): remove usless print
feat(source): Support toml source

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 74.85%. Comparing base (8adc60b) to head (ef9a81a).

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #4   +/-   ##
=======================================
  Coverage   74.85%   74.85%
=======================================
  Files          15       15
  Lines         883      883
=======================================
  Hits          661      661
  Misses        197      197
  Partials       25       25

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


Feature: Create generating invitation link fn

Overview

implement fetching hash value
Screen Captures
invHash_test.webm
References

https://dev.to/hirohata/created-result-type-in-typescript-128m
https://jestjs.io/docs/expect

Notes

Assignee Checklist:

[X] The naming convention of the PR title is correct (See the comment at the top of this template)
[X] The base branch is correct (See: Types of Branches)
[X] The branch name follows the Branch Naming Conventions
[X] The correct assignees and reviewers have been designated for this PR
[X] The coding style follows the Coding Style Guide
[X] All the related issues are associated with this PR
[X] All criteria in the associated issues are met (please tick the checkboxes)
[X] My changes do not generate new warnings or errors (especially in the console)

Reviewer Checklist:

[ ] Double-check the "Assignee Checklist"
[ ] The code follows the generic best practices and our Coding Style Guide
[ ] The code is well-commented and easy to understand
[ ] The UI changes accurately reflect the provided design

This button at GroupSingle page should have same functionality of InviteMemberDialogContent.tsx.


Provider specified to strict aws provider major version

Seems like the provider is strict to ~> 5.0 which is not best practice for internal modules. Since we might use other modules that will require higher versions in the future.
Is it possible to change it to >=  5.0?

Hi, Thanks for this issue and suggestion.
I will change the version constraint on next version.

This bug fix is included in version 2.2.3. Thank you


Update ch3.md

fix incorrect translation of key-value and try to make the sentence more fluent

That make sense, but since there is a similar PR : https://github.com/Vonng/ddia/pull/77/files
I could do nothing but closing this one, sorry...

That's ok.
Thank you for the great project.


In composition style, the  tag cannot be used by component name

Vue version
3.3.4
Link to minimal reproduction
https://codesandbox.io/s/magical-meadow-4hhmk3?file=/src/Demo.vue
Steps to reproduce
<template>
  <div>
    <!-- ... -->
    <component
      :is="(workflowStore.selectedNode.type || '').toLowerCase()"
      :config="workflowStore.selectedNode.props"
    />
    <!-- ... -->
  </div>
</template>

<script setup lang="ts">
  import { useWorkflowStore } from '@/store/modules/workflow';
  import Root from<EMAIL_ADDRESS>
  const workflowStore = useWorkflowStore();
</script>

<style scoped lang="less"></style>

I can solve this problem temporarily by registering components globally
import Root from<EMAIL_ADDRESS>// ....
  const app = createApp(App);
  app.component('Root', Root);
// ...

In composition style, how do you register components locally
The doc only has this example

What is expected?
The component is rendered normally
What is actually happening?
The component is not rendered
System Info
System:
    OS: Windows 11 10.0.22621
    CPU: (16) x64 12th Gen Intel(R) Core(TM) i5-1240P
    Memory: 10.71 GB / 39.70 GB
  Binaries:
    Node: 16.17.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
    npm: 8.15.0 - C:\Program Files\nodejs\npm.CMD
    pnpm: 8.5.1 - C:\Program Files\nodejs\pnpm.CMD
  Browsers:
    Edge: Spartan (44.22621.2283.0), Chromium (110.0.1587.57)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    vue: ^3.3.4 => 3.3.4

Any additional comments?
null

Solve successfully

Solve successfully

<script setup lang="ts">
  import Root from<EMAIL_ADDRESS>
  defineOptions({
    components: {
      Root,
    },
  });
<script />

or
<script lang="ts">
  import Root from<EMAIL_ADDRESS>
  export default {
    components: {
      Root,
    },
  };
</script>


Performance recommendation

Hi, thanks for this great lib. It's very powerful. I am hoping to move from the unmaintained react-native-qrcode-svg to this lib. However when I tried it, rendering is much more intensive. Is there any advice to get good performance?
This was my old code:
import QRCode from 'react-native-qrcode-svg';

<QRCode value="uuid_goes_here" size={96} />

This is my code when trying this lib:
import QRCode from 'react-native-qrcode-styled';

<QRCode data="uuid_goes_here" height={96} width={96} />

Yes, you are right, this can happen if you had a lot of re-renders. In 0.3.2 I added some memoization, but if you will use renderCustomPieceItem, please memoize it and use it with useCallback. Thanks for you recommendation!

Also, as an alternative way, you can memoize your entire qrcode component

Thank you! I will test it out. I think it was causing such a lag on first render though, as my modal enterance animation was dropping frames when it contained qr code. I will test and share if memoization helped that.


ConnectionPool cleanup is eager and results in unnecessary connection churn and (potentially) port exhaustion

Currently, OkHttp reaps "idle" connections (i.e. connections not in use) if either of the following is true:

a connection has not been used in a period greater than the idle timeout, or
the number of idle connections is greater than some threshold

      if (longestIdleDurationNs >= this.keepAliveDurationNs
          || idleConnectionCount > this.maxIdleConnections) {
        // We've found a connection to evict. Remove it from the list, then close it below (outside
        // of the synchronized block).
        connections.remove(longestIdleConnection);
      }

https://github.com/square/okhttp/blob/95ae0cf421c0f9c5521578781952108d1a1e1bdd/okhttp/src/main/java/okhttp3/ConnectionPool.java#L226-L230
This policy favors keeping the number of open connections close to the maxIdleConnections value.
We've run into situations internally where we have multiple threads using a single OkHttpClient instance to issue concurrent requests to an upstream (roughly 60 threads), but we observe that many of the connections (and underlying TCP sockets) are closed very soon after their initial use. This eventually leads to a situation where the host may run out of ephemeral ports (as the sockets are placed into TIME_WAIT for a period of time, and the port cannot be reused). Eventually connect() syscalls fail.
One workaround is to set the maxIdleConnections value to some value sufficiently high enough to allow for the connections to be reused in high request-rate environments. However, these connections will not be closed in the case that the request rate falls.
Maybe this is by design? I'd posit that the principle of least surprise would have one assume that a connection is only closed if it has been idle for some extended period of time. Indeed that has caught a few of us by surprise.
An alternative we'd like to propose is that connections are closed only if an eligible connection exists and the maxIdleConnections value has been exceeded. i.e. change the OR to and AND in the code above. This would allow the connection pool to grow with the load during bursts, and to shrink when the connections are not being utilized.
Here's a small reproducer we put together where we observe the port exhaustion issue:
https://github.com/nicktrav/okhttp/commits/nickt.time-wait-issue
This has also been mentioned here, but the comments didn't seem to point at a resolution:
https://stackoverflow.com/questions/41011287/why-okhttp-doesnt-reuse-its-connections

cc: @rpeng

We really need to close connections that have exceeded the keep alive duration. We evict these connections not to conserve resources but to prevent failures later caused by use of stale connections.
I think the right fix here is to dramatically increase the maxIdleConnections; perhaps to 1,000 or more. Closing non-stale connections is merely about conserving memory, and memory is cheap! Probably about ~64 KiB per socket, depending on system buffer sizes.
And we should change the default value in OkHttp also. Perhaps a default of 64? That would be 4 MiB of memory if my socket math is right, which seems in the right order of magnitude.

Next steps:

[ ] Measure on Android and JVM how much memory an idle socket needs.
[ ] Set a target idle connection count based on that per-socket memory requirement. Probably between 1 and 8 MiB is the right range.
[ ] Document this change and announce it loudly. Provide guidance for users on what they should use if not our new defaults.

One other secondary factor: each socket also has a cost on the server as well. Growing our pools will memory used by servers!

I definitely agree with you for the most part on your proposals!
One part I’d push back on a little is:

Closing non-stale connections is merely about conserving memory, and memory is cheap!

We’re seeing that’s not really the case for our clients, as a) it eats up all of the ports on the server the machine is running, given we’re opening tons of sockets and then closing them immediately (the ports can’t be reused as they’re in TIME_WAIT), b) there’s a non-trivial CPU cost here for new sockets that have to negotiate TLS when doing HTTPS.
Maybe the docs just need to be a little clearer? It took a while to work out why the sockets were immediately closed, and that was a little surprising, given experience at least with other servers that tend to close when idle conns > max value AND conn has been idle for a while.
For now, at least, we can get around this on our end by bumping up the max idle connection count, as you suggest.

@swankjesse I think the defaults here are sane for mobile clients - i.e. I doubt an android app would really require more than 5 simultaneous connections anywhere.
However, for servers usage, there are a lot less memory / battery life constraints that we need to worry about. It might be a good idea to have a way to have different sane defaults for separate use cases (i.e. client side vs. server side, similar to how java has -server and -client modes).
In reality, every user is likely to have a somewhat different use case, and would likely need to run some profiling to figure out the ideal idle size and keep-alive time to come up with reasonable values.

Punting to the next release ’cause there’s no code changes here.

Closing as effectively a dupe of https://github.com/square/okhttp/issues/4530


Chapter09 - Set polarbookshop as standard docker repo

Problem
When following the steps in the book with as start begin chapter 9, I got error when running the docker-compose commands. Problem was caused by the user have to set the right docker repo.
suggestion
Since for the begin of this chapter names are fixed, why not fix the docker repo name as well.

Thanks for the suggestion. It was indeed a bit confusing. I simplified the approach and used unqualified images when working locally here: https://github.com/ThomasVitale/cloud-native-spring-in-action/blob/update-spring-boot/Chapter09/09-end/polar-deployment/docker/docker-compose.yml