Add more sanitizer flags to shows more bugs by default

For now scons p=linuxbsd use_ubsan=yes shows this errors when running one of my projects:
thirdparty/glslang/glslang/MachineIndependent/localintermediate.h:100:8: runtime error: load of value 224, which is not a valid value for type 'bool'
thirdparty/glslang/glslang/MachineIndependent/localintermediate.h:100:8: runtime error: load of value 160, which is not a valid value for type 'bool'
thirdparty/glslang/glslang/MachineIndependent/localintermediate.h:100:8: runtime error: load of value 137, which is not a valid value for type 'bool'
thirdparty/misc/open-simplex-noise.c:195:14: runtime error: signed integer overflow:<PHONE_NUMBER>888963407 *<PHONE_NUMBER>846793005 cannot be represented in type 'long int'
thirdparty/misc/open-simplex-noise.c:196:14: runtime error: signed integer overflow:<PHONE_NUMBER>808476466 *<PHONE_NUMBER>846793005 cannot be represented in type 'long int'
thirdparty/misc/open-simplex-noise.c:198:15: runtime error: signed integer overflow: -7280499659394350823 *<PHONE_NUMBER>846793005 cannot be represented in type 'long int'
thirdparty/misc/open-simplex-noise.c:198:8: runtime error: signed integer overflow:<PHONE_NUMBER>496225463 +<PHONE_NUMBER>888963407 cannot be represented in type 'long long int'
thirdparty/misc/open-simplex-noise.c:194:14: runtime error: signed integer overflow: 2 *<PHONE_NUMBER>846793005 cannot be represented in type 'long int'
thirdparty/misc/open-simplex-noise.c:195:7: runtime error: signed integer overflow:<PHONE_NUMBER>362419545 +<PHONE_NUMBER>888963407 cannot be represented in type 'long long int'
thirdparty/misc/open-simplex-noise.c:194:7: runtime error: signed integer overflow:<PHONE_NUMBER>339275202 +<PHONE_NUMBER>888963407 cannot be represented in type 'long long int'
modules/bmp/image_loader_bmp.cpp:127:16: runtime error: load of misaligned address 0x6210003a7cb3 for type 'uint32_t', which requires 4 byte alignment
0x6210003a7cb3: note: pointer points here
 10  2c 80 10 2c 80 10 2c 80  10 2c 80 10 2c 80 10 2c  80 10 2c 80 10 2c 80 10  2c 80 10 2c 80 10 2c
              ^
thirdparty/misc/mikktspace.c:1659:21: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'
editor/input_map_editor.cpp:641:6: runtime error: load of value 190, which is not a valid value for type 'bool'

with this PR will shows additionally:
servers/rendering/rasterizer_rd/rasterizer_scene_high_end_rd.cpp:1136:52: runtime error: division by zero
servers/rendering/rasterizer_rd/rasterizer_scene_high_end_rd.cpp:1137:52: runtime error: division by zero
core/image.cpp:3202:3: runtime error: null pointer passed as argument 1, which is declared to never be null
core/image.cpp:3202:3: runtime error: null pointer passed as argument 2, which is declared to never be null
modules/svg/image_loader_svg.cpp:59:43: runtime error: index 1 out of bounds for type 'NSVGgradientStop [1]'
thirdparty/nanosvg/nanosvgrast.h:1293:47: runtime error: index 2 out of bounds for type 'NSVGgradientStop [1]'
thirdparty/nanosvg/nanosvgrast.h:1302:43: runtime error: index 1 out of bounds for type 'NSVGgradientStop [1]'
thirdparty/nanosvg/nanosvgrast.h:1304:37: runtime error: index 1 out of bounds for type 'NSVGgradientStop [1]'
thirdparty/nanosvg/nanosvgrast.h:1301:41: runtime error: index 1 out of bounds for type 'NSVGgradientStop [1]'
thirdparty/nanosvg/nanosvgrast.h:1303:35: runtime error: index 1 out of bounds for type 'NSVGgradientStop [1]'
thirdparty/nanosvg/nanosvg.h:2161:49: runtime error: division by zero

Also added memory sanitizer support which track uninitialized variables(it is only available on Linux LLVM) and for it is hard to find useful info in error flood(almost 4GB log when running project manager, mostly by thirdparty(Vulkan and SpirV)).
example report:
SUMMARY: MemorySanitizer: use-of-uninitialized-value /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/loader.c:2020:29 in loader_get_icd_loader_instance_extensions
Uninitialized bytes in __interceptor_strcmp at offset 0 inside [0x725000000104, 8)
==55437==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0xcd74cf6 in loader_get_icd_loader_instance_extensions /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/loader.c:2020:29
    #1 0xcddd3ab in terminator_EnumerateInstanceExtensionProperties /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/loader.c:7248:15
    #2 0xc926c43 in vkEnumerateInstanceExtensionProperties /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/trampoline.c:171:15
    #3 0xc8cc649 in VulkanContext::_initialize_extensions() /mnt/Miecz/mojgodot/drivers/vulkan/vulkan_context.cpp:229:8
    #4 0xc8ce6f1 in VulkanContext::_create_physical_device() /mnt/Miecz/mojgodot/drivers/vulkan/vulkan_context.cpp:281:15
    #5 0xc8e8c0d in VulkanContext::initialize() /mnt/Miecz/mojgodot/drivers/vulkan/vulkan_context.cpp:1133:14
    #6 0x1d8fc7a in DisplayServerX11::DisplayServerX11(String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) /mnt/Miecz/mojgodot/platform/linuxbsd/display_server_x11.cpp:3583:23
    #7 0x1d89e41 in DisplayServerX11::create_func(String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) /mnt/Miecz/mojgodot/platform/linuxbsd/display_server_x11.cpp:3196:22
    #8 0x1a379316 in DisplayServer::create(int, String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) /mnt/Miecz/mojgodot/servers/display_server.cpp:604:9
    #9 0x1e7f3da in Main::setup2(unsigned long) /mnt/Miecz/mojgodot/main/main.cpp:1377:20
    #10 0x1e7c408 in Main::setup(char const*, int, char**, bool) /mnt/Miecz/mojgodot/main/main.cpp:1299:10
    #11 0x1ca59cf in main /mnt/Miecz/mojgodot/platform/linuxbsd/godot_linuxbsd.cpp:51:14
    #12 0x7fd63a2ae0b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
    #13 0x1c29cbd in _start (/mnt/Miecz/mojgodot/bin/godot.linuxbsd.tools.64.llvms+0x1c29cbd)

  Uninitialized value was stored to memory at
    #0 0x1c2f826 in __msan_memcpy (/mnt/Miecz/mojgodot/bin/godot.linuxbsd.tools.64.llvms+0x1c2f826)
    #1 0xcd664d7 in loader_add_to_ext_list /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/loader.c:1563:9
    #2 0xcd76cd8 in loader_add_instance_extensions /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/loader.c:1418:19
    #3 0xcd746d7 in loader_get_icd_loader_instance_extensions /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/loader.c:2011:15
    #4 0xcddd3ab in terminator_EnumerateInstanceExtensionProperties /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/loader.c:7248:15
    #5 0xc926c43 in vkEnumerateInstanceExtensionProperties /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/trampoline.c:171:15
    #6 0xc8cc649 in VulkanContext::_initialize_extensions() /mnt/Miecz/mojgodot/drivers/vulkan/vulkan_context.cpp:229:8
    #7 0xc8ce6f1 in VulkanContext::_create_physical_device() /mnt/Miecz/mojgodot/drivers/vulkan/vulkan_context.cpp:281:15
    #8 0xc8e8c0d in VulkanContext::initialize() /mnt/Miecz/mojgodot/drivers/vulkan/vulkan_context.cpp:1133:14
    #9 0x1d8fc7a in DisplayServerX11::DisplayServerX11(String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) /mnt/Miecz/mojgodot/platform/linuxbsd/display_server_x11.cpp:3583:23
    #10 0x1d89e41 in DisplayServerX11::create_func(String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) /mnt/Miecz/mojgodot/platform/linuxbsd/display_server_x11.cpp:3196:22
    #11 0x1a379316 in DisplayServer::create(int, String const&, DisplayServer::WindowMode, unsigned int, Vector2i const&, Error&) /mnt/Miecz/mojgodot/servers/display_server.cpp:604:9
    #12 0x1e7f3da in Main::setup2(unsigned long) /mnt/Miecz/mojgodot/main/main.cpp:1377:20
    #13 0x1e7c408 in Main::setup(char const*, int, char**, bool) /mnt/Miecz/mojgodot/main/main.cpp:1299:10
    #14 0x1ca59cf in main /mnt/Miecz/mojgodot/platform/linuxbsd/godot_linuxbsd.cpp:51:14
    #15 0x7fd63a2ae0b2 in __libc_start_main /build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16

  Uninitialized value was created by an allocation of '' in the stack frame of function 'loader_add_instance_extensions'
    #0 0xcd75700 in loader_add_instance_extensions /mnt/Miecz/mojgodot/thirdparty/vulkan/loader/loader.c:1369

The only missing flag is -fsanitize=implicit-unsigned-integer-truncation available only in LLVM because it cause to big error spam.

Sorry for the late review. Seems fine to me, more diagnostics for sanitizer modes are always good to take, even if they make the build command crazily long :P

Thanks!


Minor improvements

Didn't remove all the unused variables since im not sure what they were for and don't want to mess anything up

thanks a lot


Test testSetFlutterViewControllerAfterCreateCanStillDispatchTouchEvents on engine iOS tests is flaky

The test is flaky.
Log:
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket.appspot.com/8870773991329664432/+/steps/Host_Tests_for_ios_debug_sim/0/stdout?format=raw

@godofredoc I can't reproduce this flake locally (Had about 50k runs). To help debugging, is there a way to get the crash log from the LUCI machine? The above log shows where the file is located:
/Users/chrome-bot/Library/Developer/Xcode/DerivedData/IosUnitTests-accqtxfeirzsdjbzktfvllceohpz/Logs/Test/Test-IosUnitTests-2020.08.27_16-10-50--0700.xcresult

Can you please share the task link?

https://ci.chromium.org/p/flutter/builders/prod/Mac iOS Engine/6562

Seems like that bot only has these two files:

Test-IosUnitTests-2020.08.27_23-44-26--0700.xcresult
Test-IosUnitTests-2020.08.27_20-19-45--0700.xcresult

Would one of those help?

Thanks! Looks like it only keeps 2 history log files. I guess the original file when the crash happened was gone. I'll watch for the next failure (if happens) the next couple of weeks and let you know right away so we can get the file.
Or there might be a way to save more history files?

If this helps debugging we can make a change to always add those files to the isolated output of the task.

Yeah that will definitely help!

looks like it's not flaky anymore, closing the issue.


[BUG] default yurt-tunnel-agent.yaml is invalid if chose  manual install openyurt

What happened:
yurt-tunnel-agent can't connect to kube-apiserver and yurt-tunnel-agent display has not permission to list/watch/create resources.
What you expected to happen:
yurt-tunnel-agent can start correctly.
How to reproduce it (as minimally and precisely as possible):
kubectl apply -f config/setup/yurt-tunnel-agent.yaml
Anything else we need to know?:
Environment:

OpenYurt version:
Kubernetes version (use kubectl version):
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

others
/kind bug

@kong Thank you for filing issue.
Would you be able to upload the detail logs of yurt-tunnel-agent?


fix: [M3-8523] - Fix styling on Support Ticket Details page

Description 📝
In dark mode especially, the Support Ticket Details page needed some attention. I kept the scope of these changes small because there is future UX work to improve the design of this page further, at which point we can also refactor.
Changes  🔄

Fix dark mode container colors so that the expandable replies are distinct from each other
Adjust avatar padding to better align the avatar and prevent jumping, especially on resize to small viewports

Target release date 🗓
9/30/24 or following release
Preview 📷

Before
After

Prod:  Dev:

How to test 🧪
Prerequisites
(How to setup test environment)

Have an open or closed support ticket with multiple responses or use the MSW.
Turn on dark mode as the theme

Reproduction steps
(How to reproduce the issue, if applicable)

Go to a support ticket's details page and observe the lack of visible containers around each reply
Change the viewport size and notice with mobile view, the avatar is too close to the container

Verification steps
(How to verify changes)

Confirm the above are fixed

As an Author I have considered 🤔
Check all that apply

[ ] 👀 Doing a self review
[x] ❔ Our contribution guidelines
[ ] 🤏 Splitting feature into small PRs
[x] ➕ Adding a changeset
[ ] 🧪 Providing/Improving test coverage
[ ] 🔐 Removing all sensitive information from the code and PR description
[ ] 🚩 Using a feature flag to protect the release
[x] 👣 Providing comprehensive reproduction steps
[ ] 📑 Providing or updating our documentation
[ ] 🕛 Scheduling a pair reviewing session
[ ] 📱 Providing mobile support
[ ] ♿  Providing accessibility support

Unrelated Cypress failure in CI on machine-image-upload.spec.ts; this is good to merge.


DX-1971 updated env variable names

Should we just revise the whole readme here to reflect the template readme?

Same comment as my other one, probably should but I'd like to have a different PR for it


Generate send op return rounding patch

I was able to burn SLP tokens in change outputs using the previous configuration. Looking into it, the problem arose from rounding errors.
Here are some example transactions with burned tokens using the previous method:

https://explorer.bitcoin.com/bch/tx/0e8a113005d72e31dce25233bc6bf80deee9b12d3b6e2f451040e0c5f7b21c4b
https://explorer.bitcoin.com/bch/tx/6eca3abb2bd469e98dccc21946a4ef4ade8ad817c64d572ce0ee07200e3014b7

Note: This PR is pending tests to ensure no new issue has been introduced.
The bug can be reliably repeated by sending the smallest decimal amount of an SLP token. Same issue occurs on SLP tokens with larger decimal amounts (tested on 7 and 8).
Here is some console output showing what was going on:

I modeled this approach on slp-sdk. Below please find a description of this method with links to relevant lines:

TokenType1 send function in slp-sdk: https://github.com/Bitcoin-com/slp-sdk/blob/master/src/TokenType1.ts#L125
It takes input type ISendConfig where amount is type Number;(https://github.com/Bitcoin-com/slp-sdk/blob/master/src/TokenType1.ts#L125) but immediately converts it to a BigNumber
TokenType1.send calls the simpleTokenSend method in slpjs/bitboxnetwork.ts https://github.com/simpleledger/slpjs/blob/master/lib/bitboxnetwork.ts#L120
This simpleTokenSend method in turn calls a transaction helper class here https://github.com/simpleledger/slpjs/blob/master/lib/transactionhelpers.ts#L36
The transaction helper class calls this preSendSlpJudgementCheck method here (https://github.com/simpleledger/slpjs/blob/master/lib/slp.ts#L172); this checks for things like mint batons or bad utxos. The transaction helper class is what calculates the total input and change amounts. Total input calc here (https://github.com/simpleledger/slpjs/blob/master/lib/transactionhelpers.ts#L65); and change amount here (https://github.com/simpleledger/slpjs/blob/master/lib/transactionhelpers.ts#L74)
Finally, the op return is created by another call of a file of a file, with this function: https://github.com/simpleledger/slp-metadatamaker.js/blob/master/lib/util.ts#L154

Great work on this, @josephroyking! I really appreciate all the thorough tests.
Because this is such big change, which will effect all token sending in wallet.fullstack.cash, I'm going to wait to merge this PR until after the dust has settled from the fork. I don't want to do anything at this point that could further complicate debugging during the fork.
I'm very excited to remove the bug this fixes. It's been irritating to see small amount of SLP tokens get burned.

:tada: This PR is included in version 4.4.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[BUG] Conflicting netty package between azure-storage-blob and spring-boot-starter-data-redis when calling Azure Redis

Describe the bug
Our application employs spring-boot-starter-data-redis to interact with Azure Redis for Cache via a private link, a setup that functioned perfectly until we incorporated the azure-storage-blob library. Upon introducing this new library, we observed that our Azure Cache for Redis access through the private link ceased functioning. We discovered that a conflict in the netty package between the two libraries was the root cause, with azure-storage-blob relying on an outdated version of the package. The issue was temporarily resolved by excluding netty from azure-storage-blob, which reinstated the function of Azure Cache. However, we aim to use both libraries without resorting to the stopgap solution of exclusion, as it could potentially affect our application's functioning.
Exception or Stack Trace
Unable to connect to Redis; nested exception is io.lettuce.core.RedisConnextionException : unable to connect to "rediscachename.redis.cache.windows.net":6380
To Reproduce

Have an app service with java SE 11 runtime and vnet integration to  a vnet "vnetA"
Have an azure cache for redis with ssl port only and a private link the "vnetA"
Use the following java code for using Azure Cache for redis (from azure samples) : https://github.com/Azure-Samples/java-on-azure-examples/tree/main/redis/springboot-azureredis
Add to the pom file the library azure-storage-blob https://mvnrepository.com/artifact/com.azure/azure-storage-blob/12.22.2
Deploy the code to the app service
Call the app service with POST /product/add with the payload   {  "id": "4",  "name": "tajine" }
Call the app service with GET /product/4, It will return 500 with the error : "rediscachename.redis.cache.windows.net :  6380 unable to connect "

Code Snippet
Adding the following dependency to pom.xml
com.azure: azure-storage-blob:12.22.2
Expected behavior
A clear and concise description of what you expected to happen.
apps that have the dependency spring-boot-starter-data-redis and calls Azure Cache for Redis via private link continue to work when we add the dependency azure-storage-blob
Screenshots
If applicable, add screenshots to help explain your problem.
Setup (please complete the following information):

OS: linux or windows (issue is in both)
IDE:  vsCode
Library/Libraries:  com.azure:azure-storage-blob:12.22.2
Java version: 11
App Server/Environment: Azure App Service with Java web server Java SE (Embedded web server)
Frameworks:  Spring Boot

If you suspect a dependency version mismatch (e.g. you see NoClassDefFoundError, NoSuchMethodError or similar), please check out Troubleshoot dependency version conflict article first. If it doesn't provide solution for the problem, please provide:

verbose dependency tree (mvn dependency:tree -Dverbose)
com.asmexple:demoredis:jar:0.0.1-SNAPSHOT
+- org.springframework.boot:spring-boot-starter-data-redis:jar:2.5.12:compile
|  +- org.springframework.boot:spring-boot-starter:jar:2.5.12:compile
|  |  +- org.springframework.boot:spring-boot:jar:2.5.12:compile
|  |  +- org.springframework.boot:spring-boot-autoconfigure:jar:2.5.12:compile
|  |  +- org.springframework.boot:spring-boot-starter-logging:jar:2.5.12:compile
|  |  |  +- ch.qos.logback:logback-classic:jar:1.2.11:compile
|  |  |  |  - ch.qos.logback:logback-core:jar:1.2.11:compile
|  |  |  +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.17.2:compile
|  |  |  |  - org.apache.logging.log4j:log4j-api:jar:2.17.2:compile
|  |  |  - org.slf4j:jul-to-slf4j:jar:1.7.36:compile
|  |  +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile
|  |  - org.yaml:snakeyaml:jar:1.28:compile
|  +- org.springframework.data:spring-data-redis:jar:2.5.10:compile
|  |  +- org.springframework.data:spring-data-keyvalue:jar:2.5.10:compile
|  |  +- org.springframework:spring-tx:jar:5.3.18:compile
|  |  +- org.springframework:spring-oxm:jar:5.3.18:compile
|  |  +- org.springframework:spring-aop:jar:5.3.18:compile
|  |  - org.slf4j:slf4j-api:jar:1.7.36:compile
|  - io.lettuce:lettuce-core:jar:6.1.8.RELEASE:compile
|     +- io.netty:netty-common:jar:4.1.75.Final:compile
|     +- io.netty:netty-handler:jar:4.1.75.Final:compile
|     |  - io.netty:netty-resolver:jar:4.1.75.Final:compile
|     +- io.netty:netty-transport:jar:4.1.75.Final:compile
|     - io.projectreactor:reactor-core:jar:3.4.16:compile
|        - org.reactivestreams:reactive-streams:jar:1.0.3:compile
+- org.springframework.boot:spring-boot-starter-web:jar:2.5.12:compile
|  +- org.springframework.boot:spring-boot-starter-json:jar:2.5.12:compile
|  |  +- com.fasterxml.jackson.core:jackson-databind:jar:<IP_ADDRESS>:compile
|  |  +- com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.12.6:compile
|  |  +- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.12.6:compile
|  |  - com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.12.6:compile
|  +- org.springframework.boot:spring-boot-starter-tomcat:jar:2.5.12:compile
|  |  +- org.apache.tomcat.embed:tomcat-embed-core:jar:9.0.60:compile
|  |  +- org.apache.tomcat.embed:tomcat-embed-el:jar:9.0.60:compile
|  |  - org.apache.tomcat.embed:tomcat-embed-websocket:jar:9.0.60:compile
|  +- org.springframework:spring-web:jar:5.3.18:compile
|  |  - org.springframework:spring-beans:jar:5.3.18:compile
|  - org.springframework:spring-webmvc:jar:5.3.18:compile
|     +- org.springframework:spring-context:jar:5.3.18:compile
|     - org.springframework:spring-expression:jar:5.3.18:compile
+- org.springframework.boot:spring-boot-starter-test:jar:2.5.12:test
|  +- org.springframework.boot:spring-boot-test:jar:2.5.12:test
|  +- org.springframework.boot:spring-boot-test-autoconfigure:jar:2.5.12:test
|  +- com.jayway.jsonpath:json-path:jar:2.5.0:test
|  |  - net.minidev:json-smart:jar:2.4.8:test
|  |     - net.minidev:accessors-smart:jar:2.4.8:test
|  |        - org.ow2.asm:asm:jar:9.1:test
|  +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.3:compile
|  |  - jakarta.activation:jakarta.activation-api:jar:1.2.2:compile
|  +- org.assertj:assertj-core:jar:3.19.0:test
|  +- org.hamcrest:hamcrest:jar:2.2:test
|  +- org.junit.jupiter:junit-jupiter:jar:5.7.2:test
|  |  +- org.junit.jupiter:junit-jupiter-api:jar:5.7.2:test
|  |  |  +- org.apiguardian:apiguardian-api:jar:1.1.0:test
|  |  |  +- org.opentest4j:opentest4j:jar:1.2.0:test
|  |  |  - org.junit.platform:junit-platform-commons:jar:1.7.2:test
|  |  +- org.junit.jupiter:junit-jupiter-params:jar:5.7.2:test
|  |  - org.junit.jupiter:junit-jupiter-engine:jar:5.7.2:test
|  |     - org.junit.platform:junit-platform-engine:jar:1.7.2:test
|  +- org.mockito:mockito-core:jar:3.9.0:test
|  |  +- net.bytebuddy:byte-buddy:jar:1.10.22:compile
|  |  +- net.bytebuddy:byte-buddy-agent:jar:1.10.22:test
|  |  - org.objenesis:objenesis:jar:3.2:test
|  +- org.mockito:mockito-junit-jupiter:jar:3.9.0:test
|  +- org.skyscreamer:jsonassert:jar:1.5.0:test
|  |  - com.vaadin.external.google:android-json:jar:0.0.20131108.vaadin1:test
|  +- org.springframework:spring-core:jar:5.3.18:compile
|  |  - org.springframework:spring-jcl:jar:5.3.18:compile
|  +- org.springframework:spring-test:jar:5.3.18:test
|  - org.xmlunit:xmlunit-core:jar:2.8.4:test
+- org.projectlombok:lombok:jar:1.18.22:compile (optional)
+- com.h2database:h2:jar:1.4.200:runtime
+- org.springframework.boot:spring-boot-starter-cache:jar:2.5.12:compile
|  - org.springframework:spring-context-support:jar:5.3.18:compile
+- org.springframework.boot:spring-boot-starter-data-jpa:jar:2.5.12:compile
|  +- org.springframework.boot:spring-boot-starter-aop:jar:2.5.12:compile
|  |  - org.aspectj:aspectjweaver:jar:1.9.7:compile
|  +- org.springframework.boot:spring-boot-starter-jdbc:jar:2.5.12:compile
|  |  +- com.zaxxer:HikariCP:jar:4.0.3:compile
|  |  - org.springframework:spring-jdbc:jar:5.3.18:compile
|  +- jakarta.transaction:jakarta.transaction-api:jar:1.3.3:compile
|  +- jakarta.persistence:jakarta.persistence-api:jar:2.2.3:compile
|  +- org.hibernate:hibernate-core:jar:5.4.33:compile
|  |  +- org.jboss.logging:jboss-logging:jar:3.4.3.Final:compile
|  |  +- org.javassist:javassist:jar:3.27.0-GA:compile
|  |  +- antlr:antlr:jar:2.7.7:compile
|  |  +- org.jboss:jandex:jar:2.2.3.Final:compile
|  |  +- com.fasterxml:classmate:jar:1.5.1:compile
|  |  +- org.dom4j:dom4j:jar:2.1.3:compile
|  |  +- org.hibernate.common:hibernate-commons-annotations:jar:5.1.2.Final:compile
|  |  - org.glassfish.jaxb:jaxb-runtime:jar:2.3.6:compile
|  |     +- org.glassfish.jaxb:txw2:jar:2.3.6:compile
|  |     +- com.sun.istack:istack-commons-runtime:jar:3.0.12:compile
|  |     - com.sun.activation:jakarta.activation:jar:1.2.2:runtime
|  +- org.springframework.data:spring-data-jpa:jar:2.5.10:compile
|  |  +- org.springframework.data:spring-data-commons:jar:2.5.10:compile
|  |  - org.springframework:spring-orm:jar:5.3.18:compile
|  - org.springframework:spring-aspects:jar:5.3.18:compile
- com.azure:azure-storage-blob:jar:12.22.2:compile
+- com.azure:azure-core:jar:1.39.0:compile
|  +- com.azure:azure-json:jar:1.0.1:compile
|  +- com.fasterxml.jackson.core:jackson-annotations:jar:2.12.6:compile
|  - com.fasterxml.jackson.core:jackson-core:jar:2.12.6:compile
+- com.azure:azure-core-http-netty:jar:1.13.3:compile
|  +- io.netty:netty-handler-proxy:jar:4.1.75.Final:compile
|  |  - io.netty:netty-codec-socks:jar:4.1.75.Final:compile
|  +- io.netty:netty-buffer:jar:4.1.75.Final:compile
|  +- io.netty:netty-codec:jar:4.1.75.Final:compile
|  +- io.netty:netty-codec-http:jar:4.1.75.Final:compile
|  +- io.netty:netty-codec-http2:jar:4.1.75.Final:compile
|  +- io.netty:netty-transport-native-unix-common:jar:4.1.75.Final:compile
|  +- io.netty:netty-transport-native-epoll:jar:linux-x86_64:4.1.75.Final:compile
|  |  - io.netty:netty-transport-classes-epoll:jar:4.1.75.Final:compile
|  +- io.netty:netty-transport-native-kqueue:jar:osx-x86_64:4.1.75.Final:compile
|  |  - io.netty:netty-transport-classes-kqueue:jar:4.1.75.Final:compile
|  +- io.netty:netty-tcnative-boringssl-static:jar:2.0.51.Final:compile
|  |  +- io.netty:netty-tcnative-classes:jar:2.0.51.Final:compile
|  |  +- io.netty:netty-tcnative-boringssl-static:jar:linux-x86_64:2.0.51.Final:compile
|  |  +- io.netty:netty-tcnative-boringssl-static:jar:linux-aarch_64:2.0.51.Final:compile
|  |  +- io.netty:netty-tcnative-boringssl-static:jar:osx-x86_64:2.0.51.Final:compile
|  |  +- io.netty:netty-tcnative-boringssl-static:jar:osx-aarch_64:2.0.51.Final:compile
|  |  - io.netty:netty-tcnative-boringssl-static:jar:windows-x86_64:2.0.51.Final:compile
|  - io.projectreactor.netty:reactor-netty-http:jar:1.0.17:compile
|     +- io.netty:netty-resolver-dns:jar:4.1.75.Final:compile
|     |  - io.netty:netty-codec-dns:jar:4.1.75.Final:compile
|     +- io.netty:netty-resolver-dns-native-macos:jar:osx-x86_64:4.1.75.Final:compile
|     |  - io.netty:netty-resolver-dns-classes-macos:jar:4.1.75.Final:compile
|     - io.projectreactor.netty:reactor-netty-core:jar:1.0.17:compile
+- com.azure:azure-storage-common:jar:12.21.1:compile
+- com.azure:azure-storage-internal-avro:jar:12.7.1:compile
- com.fasterxml.jackson.dataformat:jackson-dataformat-xml:jar:2.12.6:compile
+- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.12.6:compile
+- org.codehaus.woodstox:stax2-api:jar:4.2.1:compile
- com.fasterxml.woodstox:woodstox-core:jar:6.2.4:compile
exception message, full stack trace, and any available logs
Unable to connect to Redis; nested exception is io.lettuce.core.RedisConnextionException : unable to connect to "rediscachename.redis.cache.windows.net":6380
Additional context
Add any other context about the problem here.

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[ x ] Bug Description Added
[ x ] Repro Steps Added
[ x ] Setup information Added

Thank you for filing this @AsmaeFILALI.
The outdated version of Netty is actually due to the dependencies being used by spring-boot-starter-data-redis 2.5.12. It depends on lettuce-core 6.1.8.RELEASE which in turn depends on the versions of Netty you're seeing resolved, https://mvnrepository.com/artifact/io.lettuce/lettuce-core/6.1.8.RELEASE.

The root issue happening is that azure-storage-blob 12.22.2 depends on much newer versions of Netty, 4.1.89.Final for all the non-tcnative dependencies and 2.0.56.Final for the tcnative dependency.
There are a few possible options to resolve this:

Override the dependency of lettuce-core to a newer version not using as old Netty dependencies.
Downgrade the version of azure-storage-blob to one that aligns more closely with the Netty dependencies used by lettuce-core 6.1.8.RELEASE.
Upgrade the version of spring-boot-starter-data-redis to the latest 2.7.x version (though this may not work well as that still uses an older version of lettuce-core that depends on fairly old Netty dependencies, 4.1.82.Final).

Thanks a lot  for your response @alzimmermsft, for the 3d option, upgrading the spring-boot-starter-data-redis to 2.7.x we already tried that , and as you expected it did not work

That's unfortunate, given that I'd look into upgrading lettuce-core to 6.2.4.RELEASE as that updates the Netty dependencies being used by the library. Or, downgrading azure-storage-blob to 12.16.0 would bring down the dependencies used by Storage Blob to be inline with the dependencies being used by spring-boot-starter-data-redis 2.5.12. And one last option would be reordering the dependencies in the pom.xml as that will have Maven tiebreak dependency conflicts with the dependencies in azure-storage-blob (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#transitive-dependencies).

Hi @AsmaeFILALI,  could you please collect some logs (and traces if you have them enabled) for us?
Here's how to enable Azure SDK logging. INFO level should be ok, but if you can, sharing verbose logs would be even better.
If you have distributed tracing enabled, would you also be able to export collected traces for the relevant operation(s) and share them with us?
Thanks!

Thank you @lmolkova and @alzimmermsft  for your response, in fact there is some news :
During my examination of the logs, I noticed this line: "[Default DNS servers: [/<IP_ADDRESS>:53, /<IP_ADDRESS>:53] (Google Public DNS as a fallback {"LoggerName":"io.netty.resolver.dns.DefaultDnsServerAddressStreamProvider","SourceType":"Logger","ThreadName":"main"}]"  suggesting that the Google DNS is being used. This originates from the DNS resolver within the io.netty:netty-resolver-dns library, which is contained within io.projectreactor.netty:reactor-netty-http, itself under com.azure:azure-storage-blob.
By excluding io.netty:netty-resolver-dns from io.projectreactor.netty:reactor-netty-http (which is under com.azure:azure-storage-blob), the project began working again. I believe the root cause to be the DNS resolver io.netty:netty-resolver-dns within io.projectreactor.netty:reactor-netty-http. This makes sense given that the error we are experiencing stems from spring-data-redis's failure to resolve the Azure Cache for Redis private link address after adding the com.azure:azure-storage-blob library to the project, which sets up a DNS for Netty different from that of Azure. Here is the pom configuration that made it work :
	<dependencies>
		<dependency>
			<groupId>com.azure</groupId>
			<artifactId>azure-storage-blob</artifactId>
			<version>12.22.2</version>
			<exclusions>
				<exclusion>
					<groupId>com.azure</groupId>
					<artifactId>azure-core-http-netty</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>com.azure</groupId>
			<artifactId>azure-core-http-netty</artifactId>
			<version>1.13.3</version>
			<exclusions>
				<exclusion>
					<groupId>io.projectreactor.netty</groupId>
					<artifactId>reactor-netty-http</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>io.projectreactor.netty</groupId>
			<artifactId>reactor-netty-http</artifactId>
			<version>1.0.32</version>
			<exclusions>
				<exclusion>
					<groupId>io.netty</groupId>
					<artifactId>netty-resolver-dns</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

Is there any solution other than exclusion for remediating this behavior  ? thank you a lot  :)

@AsmaeFILALI, it looks like Netty allows for the configuration of the fallback DNS server, added in this change: https://github.com/netty/netty/pull/13065/files. Configuring this should unblock the customer by using the DNS server that works with Private Link.

Another potential solution is using a different HTTP stack provided by the Azure SDKs. The following example is using the OkHttp HTTP stack:
<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-storage-blob</artifactId>
    <version>12.22.2</version>
    <exclusions>
        <exclusion>
	    <groupId>com.azure</groupId>
	    <artifactId>azure-core-http-netty</artifactId>
	</exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-core-http-okhttp</artifactId>
    <version>1.11.9</version>
</dependency>

Note: the azure-core-http-netty exclusion will have to be done for every Azure SDK being used in the application.

Lastly, it appears that Spring has documentation on how to use Configuration and Beans to modify the connection factory. Taking the example on observability (https://github.com/spring-projects/spring-data-redis/blob/main/src/main/asciidoc/reference/observability.adoc) it can be mutated a bit to force the JVM default DNS resolver:
@Configuration
class DnsConfiguration {

    @Bean
    public ClientResources clientResources() {
        return DefaultClientResources.builder()
            .dnsResolver(DnsResolver.jvmDefault())
            .build();
    }

    @Bean
    public LettuceConnectionFactory lettuceConnectionFactory(ClientResources clientResources) {
        LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
            .clientResources(clientResources).build();
        RedisConfiguration redisConfiguration = …;
        return new LettuceConnectionFactory(redisConfiguration, clientConfig);
    }
}

Appreciate your assistance, @alzimmermsft . I'll put your proposed solution to the test and revert back with my findings. Meanwhile, I wanted to inquire about future azure-storage-blob updates. As it's a sub-library that automatically integrates the DNS resolver, would it be possible for upcoming versions to include the azure DNS resolver configuration by default? This could be a beneficial feature. Thank you again :)

Thank you for your reply, @alzimmermsft . The previously suggested solution of integrating the configuration .dnsResolver(DnsResolver.jvmDefault()) and using the lettuceconnectionfactory  didn't bring any changes to the prior behavior. The io.netty.resolver.dns.DefaultDnsServerAddressStreamProvider class still fetches an empty list of the default environment DNS servers. This, in turn, defaults to Google's fallback DNS address.
Nonetheless, the problem was successfully addressed when I designated Azure DNS as the fallback DNS. This was achieved by incorporating the JAVA_OPTS -Dio.netty.resolver.dns.defaultNameServerFallback=<IP_ADDRESS> into the app setting, as you previously recommended

That's great new @AsmaeFILALI that this was able to be resolved. I'll leave the other options in this issue as they make work but just might need further configuration as I only took a quick look into how Spring and Lettuce Core handle configurations, so something may be missing.
I'll go ahead and close this as resolved.


Version change to 0.0.3

r? @chandraprakash
(maidsafe_highfive has picked a reviewer for you, use r? to override)

r? @Viv-Rajkumar


Massive Insert/Update Using Graph API

OrientDB Version:   2.2.33
OS:   linux
I'm using java API (graph) for Orientdb and I want to insert/update the graph about 500,000,000 (Five hundred million including vertex and edge) per day. Also I want when I'm inserting/updating the graph, the users can access the graph and so they could send a query from another connection. As my experience, I just can insert/update about 100,000,000 million in a day when I'm not using cloud and about 50,000,000 million when I'm using cloud Orient. Is it the maximum limitation and can I insert/update more?

Hi @hossein-md
There is no explicit limitation, it all depends on the import procedure, on the hardware and on the type of connection you are using (ie. plocal vs remote).
If you could share some snippets of code, maybe we could give you some advice
Thanks
Luigi

Hi @luigidellaquila

My connection type is "remote" because as I understand in the "plocal" mode the database is not available to other remote connections

It is interesting for me to know what my hardware should be to have about 10 billion documents (Including vertices and edges)? At this time I have about 3 billion documents but I didn't insert them into the Orientdb.

I use java-api and I wrote some functions for insert data into my Orientdb. For example my upsert function is in MyUpsertFunction
I use this to connect to my db (OrientGraph graph = new OrientGraph("remote:localhost/DBNAME");)

Thanks
Dehghan

Hi @hossein-md

actually you can launch a full server embedded, so that other nodes can connect to it, see https://orientdb.com/docs/2.2.x/Embedded-Server.html

as a general rule, the performance depends a lot on how many records you can keep in cache (in memory), so that you can avoid expensive disk access.
A DB with ten billions of records will be in the order of terabytes on disk. For the ram of course, the more the better, but for such dataset I'd suggest to have at least 64GB for a decent performance

Thanks
Luigi


[FEATURE] We need to be able to call modal windows from the sidebar menu described in the EventServiceProvider

Is your request related to a problem? Please describe.
No way to call the modal window from the sidebar
Describe the solution you'd like
We need to be able to call modal windows from the sidebar menu described in the EventServiceProvider
Describe alternatives you've considered
Hadn't considered
Additional context
Add any other context or screenshots about the feature request here.

Currently, you may put a link on the left sidebar to open a modal that is defined globally using next workaround:

You should define a base layout for your application and put your modal there to be available globally, see issue #925 to check for an example on how to create a base layout. An example for your base layout may be:{{-- resource/views/layout.blade.php --}}

@extends('adminlte::page')

{{-- You may add other layout customizations here... --}}

{{-- Global Modal --}}
<x-adminlte-modal id="exampleModal" title="Minimal"/>

Then, you may define next item on your sidebar menu to toggle the modal:[
    'text'   => 'Open Modal',
     'url'    => '',
     'data'   => [
         'toggle' => 'modal',
         'target' => '#exampleModal',
     ]
]

Thank you, the question is closed.


Reader considers that a number is a text

Hi guys,
just a question cuz I've searched for solutions and haven't found one.
When I'm reading worksheet content
    DATA(o_reader) = CAST zif_excel_reader( NEW zcl_excel_reader_2007( ) ).
    DATA(o_excel) = o_reader->load_file( filename ).

    o_excel->set_active_sheet_index( o_excel->get_active_sheet_index( ) ).
    DATA(o_worksheet) = o_excel->get_active_worksheet( ).

    LOOP AT o_worksheet->sheet_content ASSIGNING FIELD-SYMBOL(<cell>) GROUP BY <cell>-cell_row ASSIGNING FIELD-
    SYMBOL(<row>).
    ....

    ENDLOOP.

when reading an amount which is in format xxxx,xx it's automatically converted to xxxx.xx in the sheet_content. data_format is blank/empty
But when reading an amount in the same column in format xxxx,xx- it's not converted to xxxx.xx-. It stays the same. data_format is 's'.
Does anybody have a solution for this issue?
Best regards

Hi sandraros,
thanks for your reply. Here's the file.
Excel file to read in.xlsx
.

Thank you. I confirm they are not defined as numbers (by adding zero, it returns an error for negative numbers), so it's normal that abap2xlsx returns these "numbers" as texts:

Yeah, that is correct. They are probably just copy & pasted out of the system, but anyway I have to read them in and post them.
As this file is created by the enduser and the enduser will call my program to read this file into the system, I have to get the right amount.
The issue is that right now, these common numbers can be interpreted like numbers, even if the cell is not formatted.
The negative ones can not be interpreted.
I was just thinking if the cell number_format can always be the same? Like if they are just entered and not formatted, that they can be interpreted as text/string?

I think the best solution is to educate the users to be responsible of providing data in the right format. If you, as a developer, interprets those information according to rules known by only you, you will be responsible of any issue. You'd better send a clear error message to the user.
Concerning the component data_format in sheet_content, the value "s" means a string.

Alright, thank you.
I'll try to educate them :).
Thanks for your help. This issue can be closed


Added platinum-* snippets

+ platinum-sw-cache (psw-cache)
+ platinum-sw-fetch (psw-fetch)
+ platinum-sw-import-script (psw-import)
+ platinum-sw-offline-analytics (psw-analytics)
+ platinum-sw-register (psw-register)

Closing as platinum-* soon-to-be deprecated


Connect items to ontologies

Optionally provide an Ontology for the Item constructor; if given, only properties that are present in the ontology would be allowed.
Likely do the same in ItemCollection.

Item and ItemCollection were moved to UserSimCRS and this feature has been implemented in this PR.


Listen to events from a already deployed smart contract

I'd like to listen to a specific event for a smart contract that is already deployed on Rinkeby. Could you show a few lines of example code for doing that?
Cheers

Heyo, yes, so I would setup a contract object  and then use either getLogs or onEvent.
getLogs will scan through the entire chain from where you specify the fromBlock blocknumber and toBlock blocknumber. The log data will then be decoded and will be returned.
I would use getLogs initially then use onEvent for keeping up to date. I'll get an example up tomorrow.
Sent from my iPhone

On Mar 13, 2018, at 10:10 PM, Magnus Bondesson<EMAIL_ADDRESS>wrote:
I'd like to listen to a specific event for a smart contract that is already deployed on Rinkeby. Could you show a few lines of example code for doing that?
Cheers
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

An example would be awesome! Thanks!


Unable to fork

Describe the bug
Unable to fork an Angular app.
Link to the blitz that caused the error
https://stackblitz.com/run?file=src/app/form-field-error-example.ts
Steps to reproduce

Go to https://material.angular.io/components/form-field/overview#error-messages
Open the StackBlitz example for "Form field with error messages" demo
Attempt to fork it
Observe the fork button to start spinning infinitely.
The console seems to report a 500 error

Expected behavior
I should be able to fork a project
Parity with Local

[ ] I have run the project in my local machine and I could not reproduce the issue.

Screenshots
No response
Platform
Browser name  = Chrome
Full version  = 96.0.4664.110
Major version = 96
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36
performance.memory = {
  "totalJSHeapSize": 112298920,
  "usedJSHeapSize": 104070140,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Hash = 528f704493b63b14b6f9ee36935eead8382e8395

Additional context
Upon clicking "Fork", I see a network request POST /api/projects failing with a 500 status code right away

duplicate of #569 - we just shipped a fix for this too ❤


Jump to Graby 2.0

WIP PR about using Graby 2.0 with HTTPlug and Guzzle 6.

Coverage decreased (-0.07%) to 97.7% when pulling 73a9a3adb767156345327c3ff50454b2b006b476 on httplug into 86d0f07ca91a32a5082c36fce3a243779f68237f on master.


[UPDATE] Adds 1.28 -> 1.31 of CPI, Adds 3.1.2 -> 3.3.1 of the CSI

Overview

Update vsphere cloud provider images
Update the update.py

to filter images which can longer be sync'd b/c upstream dropped those images
filter out releases which we didn't sync in time (1.27)

LP#2083999
Huge thanks to @jblesener for bringing this to my attention
This can replace #32

@jblesener it's on slate to get into the charm soon

@jblesener would you be willing to check 1.31/edge charm to see if it fits your liking?

@addyess yep, working fine here. thanks for pushing this through!


How could i change luaVersion for luaparse

Usually I avoid goto, but today needed to use it and got this:
message: 'unexpected identifier 'goto' near 'end'' at: '25,13' source: 'luaparse'
so i think i should to set luaVersion for luaparse. How could i do that?
By the way i love your extension. 👍 Thx.

Should be fixed in v0.7.0. There's now a version indicator in the bottom right of the window you can press. The change is persisted through your workspace settings.

You are great, thank you.

I now using v0.12.4 still have this problem?

It is working great. trixnz fixed that in July 2017.

@SWSAmor thk

I'm also using v0.12.4 and getting this error.

I don't know why but I have this issue with 0.12.4


keyboard shortcut

Godot version:
3.0, 3.1
OS/device including version:
all
Issue description:
I would like an editable and saveable keyboard shortcut list, accessible through the menu toolbar (https://github.com/godotengine/godot/issues/25918) as well as through a shortcut itself, similar to that of Aseprite, with is very thorough

It's in the editor settings already.


refactor(theme-classic): make tag text visually certered

Pre-flight checklist

[x] I have read the Contributing Guidelines on pull requests.
[ ] If this is a code change: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
[ ] If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation

The tag content was visually offset which looked out of place. This fixes it.
Test Plan

Manually verified.

Before
After

Interesting. I don't like the idea of hacking dimensions just so things appear "visually aligned", because if you use a font with different baseline height then everything is misaligned again. But I'm not master with CSS so I'll defer this to someone else to review.

Thanks.
I'll merge because it looks better by default and with many fonts.
However, this is not a good generic solution to this problem.
The problem is that fonts have different ascenders/descenders.
Different fonts will give you different results here, and this change may even annoy some Docusaurus users that are using fonts that are already more "balanced".
See for example what the "fantasy" font looks like (no padding change) compared to the original:

This is a good lib to work with ascenders/descenders, or just to understand the problem: https://seek-oss.github.io/capsize/

@slorber absolutely it's not a perfect solution by any means. However it is the simplest and quickest, short term at least.


Allow a cache item to be stored forever

Q
A

Bug fix?
yes

New feature?
no

BC breaks?
no

Deprecations?
no

Related tickets
fixes #19,

Documentation

License
MIT

What's in this PR?
If you configure your default_ttl to be null you should store (and be valid) the response as long as the cache item is stored.
Also, if you configure cache_lifetime to be null you should store the cache item forever.
Why?
At the moment we calculate the expiresAt as $maxAge + time() which is just time() when $maxAge is null. This is why we got issues like #19.

@Nyholm :+1: It fixes #19

i think we should change the default_ttl to something like 10 minutes, otherwise we will start caching responses without caching instructions forewever, which could be unexpected.

i think we should change the default_ttl to something like 10 minutes,

If we are using respect_cache_headers=>true and there is no cache headers. We fallback on the default_ttl. The default behavior should be that we do not cache at all. (Since there is not cache headers) The user has to configure the default_ttl himself.
I've changed the default value of default_ttl to 0.

looks good to me. any objections? otherwise lets squash and merge this.

No objections, but we have to make sure that there are no regressions.
David Buchmann<EMAIL_ADDRESS>ezt írta (2016. augusztus 15.,
hétfő):

looks good to me. any objections? otherwise lets squash and merge this.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/php-http/cache-plugin/pull/20#issuecomment-239738671,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABK2kHifTc3tYUe0d0z1lWE8PiMwzEXzks5qgAp5gaJpZM4JjpXV
.

No objections, but we have to make sure that there are no regressions.

yes. i think it looks right, did you see any problematic thing? do you
have a suggestion what we should do additionally to prevent regressions?

No, I haven't spotted anything. Generally speaking our last few features
introduced some regressions, which is bad. I would rather maintain BC than
adding new shiny features. Just a note, nothing special for this PR.
David Buchmann<EMAIL_ADDRESS>ezt írta (2016. augusztus 15.,
hétfő):

No objections, but we have to make sure that there are no regressions.

yes. i think it looks right, did you see any problematic thing? do you
have a suggestion what we should do additionally to prevent regressions?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/php-http/cache-plugin/pull/20#issuecomment-239740081,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABK2kJpgDUZST7hUDn5gZELUGOMLvAiMks5qgA1DgaJpZM4JjpXV
.

looking over the code again, i wonder two things: does it make sense to cache for longer than max-age if we have no information for cache validation (Last-Modified or Etag)? it seems like in that case we can't reuse the cached item anyways. maybe too complicated, and in the future we could be adding support for grace operations. (stale-on-error, stale-while-revalidate)
and would it ever make sense to configure default ttl to a value higher than the cache lifetime? probably not, but again not critical.
RE regressions: i think this is a bugfix, not just a new feature, so we should do it. and if we feel not confident about breaking behaviour, we need to check on the test coverage and maybe add more tests.

looking over the code again, i wonder two things: does it make sense to cache for longer than max-age if we have no information for cache validation (Last-Modified or Etag)? it seems like in that case we can't reuse the cached item anyways. maybe too complicated,

You are correct. We "waste" cache here. But I would like to leave that as a possible future improvement. And yes, it could be too complicated.

and in the future we could be adding support for grace operations. (stale-on-error, stale-while-revalidate)

Yes. =)

thanks a lot @Nyholm !

Thank you for merging


Swift Package Manager support

This doesn't work perfectly - it looks like the Automation target has an error when running swift build.
It works for the SwipeTransition framework though, and has made it so I can target my branch as a dependency in my app. I might look to fix this in a few weeks, but if someone else would like to commandeer this and finish what I started, please feel free!

Thank you for your contribution!
It's a nice feature 👍
I'll merge it after trying it.

@AndrewSB  it may be broken with Carthage build.
% carthage update
*** Checking out SwipeTransition at "0452b7929e128631e856dce2db0780422bacd008"
*** xcodebuild output can be found in /var/folders/z3/lyh75tws0hg4nsp2wrg6gxnw0000gq/T/carthage-xcodebuild.cv7MVo.log
*** Building scheme "SwipeTransition" in SwipeTransition.xcodeproj
Build Failed
        Task failed with exit code 65:

Could you fix the problem?

just rebased all the changes on master.
2 issues with this PR:

breaks Carthage support. this isn't something i'm going to prioritize fixing, i'm happy to continue using my branch
It has a single "Automation" product that isn't exposed, instead of having AutoSwipeBack and AutoSwipeToDismiss as 2 targets that can be pulled in. since I'm only using the SwipeBack framework, i haven't taken the time to separate them out

I'm happy to accept anyone else's work on top of this to enable that, i'll try to keep my branch upto date 😄

Hi @tattn Any update on the above PR ? are you merging it
we would like to have spm version

Sorry for my late reply.
I think this implementation is good and I now believe that Carthage support is unnecessary.
Therefore, I'd like to merge this PR, but I can't merge it into main branch until updating README.md and some code.
So I create swiftpm branch and I'll merge this PR into it after resolving conflicts.
I'd like to fix it if I have time, but would welcome PRs from anyone.

@tattn Any update here? It would be great to have SPM support :)

I will merge this PR into swiftpm branch, so if you are in a hurry, please use the swiftpm branch. I plan to release it after making some adjustments to the implementation.

@hansemannn i've been using .package(url: "https://github.com/reclipapp/SwipeTransition", revision: "222f5246f128ab459a20aef06935e6ef29240e51") for about a year now, we'll keep it upto date until upstream is fully SPM compliant


340 change age bands in scotland

Pull Request submission
I have created an if statement in data_transform.py which handles any instances where the bins are larger than 90+. It should be generalised to work with any time that there are more bins over 90. I also changed the renaming of columns in scotland.py.
Closes or fixes
Fixes #
Code

[x] Requirements My/our code matches the requirements of the ticket
[x] Functionality: New functions meet requirements in issue ticket
[x] Compliant Code Code is as PEP 8 compliant as I can humanly make it
[x] Code runs The code runs on my machine
[x] Clean Code

[ ] Code has been linted (use your favourite linter)
[ ] Code adheres to DRY

Documentation
Any new code includes all the following forms of documentation:

[x] Function Documentation Docstrings within the function(s') definition(s) have been created

[x] Includes parameters and returns for all major functions
[ ] Includes data types

[ ] Updated Documentation: Working doc has been updated and a new ticket to update the master documentation has been created.

Data

[ ] All data needed to run this script has been added to Sync

Testing

[ ] Unit tests Unit tests have been created and are passing or a new ticket to create tests has been created

Peer Review Section

[ ] All requirements install from (updated) requirements.txt NA
[ ] Documentation has been created and is clear - check the google Doc NA
[ ] Doctrings (Google format) have been created and accurately describe the function's functionality NA
[ ] Unit tests pass, or if not present a new ticket to create tests has been created
[ ] Code runs The code runs on reviewer's machine

Final approval (post-review)
The author has responded to my review and made changes to my satisfaction.

[ ] I recommend merging this request.

Review comments
Insert detailed comments here!
These might include, but not exclusively:

bugs that need fixing (does it work as expected? and does it work with other code
that it is likely to interact with?)
alternative methods (could it be written more efficiently or with more clarity?)
documentation improvements (does the documentation reflect how the code actually works?)
additional tests that should be implemented (do the tests effectively assure that it
works correctly?)
code style improvements (could the code be written more clearly?)

Your suggestions should be tailored to the code that you are reviewing.
Be critical and clear, but not mean. Ask questions and set actions.

I will review :)

Review comments
Insert detailed comments here!
These might include, but not exclusively:
bugs that need fixing (does it work as expected? and does it work with other code
that it is likely to interact with?)
alternative methods (could it be written more efficiently or with more clarity?)
documentation improvements (does the documentation reflect how the code actually works?)
additional tests that should be implemented (do the tests effectively assure that it
works correctly?)
code style improvements (could the code be written more clearly?)
Your suggestions should be tailored to the code that you are reviewing.
Be critical and clear, but not mean. Ask questions and set actions.

The function _age_bin is correctly defined, however when it's being used it needs to be assigned a variable.

@Antonio-John I think I have now addressed all your comments, let me know if there is anything else :)


[Dubbo-3555] check if remoteGroup is empty or not to fix 3555

What is the purpose of the change
fix #3555
Brief changelog
XXXXX
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #3558 into master will decrease coverage by 0.01%.
The diff coverage is 50%.

@@             Coverage Diff              @@
##             master    #3558      +/-   ##
============================================
- Coverage     64.16%   64.15%   -0.02%
  Complexity       71       71
============================================
  Files           664      664
  Lines         28629    28630       +1
  Branches       4771     4772       +1
============================================
- Hits          18371    18368       -3
- Misses         8034     8036       +2
- Partials       2224     2226       +2

Impacted Files
Coverage Δ
Complexity Δ

...apache/dubbo/rpc/cluster/support/ClusterUtils.java
69.35% <50%> (-1.14%)
0 <0> (ø)

...he/dubbo/remoting/transport/netty/NettyServer.java
69.64% <0%> (-3.58%)
0% <0%> (ø)

...bo/rpc/cluster/support/FailbackClusterInvoker.java
67.21% <0%> (-3.28%)
0% <0%> (ø)

...dubbo/remoting/exchange/support/DefaultFuture.java
70.94% <0%> (-1.36%)
0% <0%> (ø)

.../java/org/apache/dubbo/config/ReferenceConfig.java
57.14% <0%> (+0.37%)
0% <0%> (ø)
:arrow_down:

.../apache/dubbo/remoting/transport/AbstractPeer.java
63.04% <0%> (+4.34%)
0% <0%> (ø)
:arrow_down:

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 05a98f3...d11b0d3. Read the comment docs.

I have to do a javaagent to make a workaround 😢


Create BigQuery library version 1.2.0

New feature: geo-regionalization, which allows datasets and jobs to
be created in specific location.

(No need to review this on Sunday, but I'd like to create a release on Monday morning.)


Rework random generator to use LCG

Fixes #789.
Current random generator suffers from a few issues which I tried to address in this PR:

it uses the !generated.Contains(newRnd) statement to guarantee the uniqueness of the produced values. This approach could lead to significant delays when latest elements in a sequence are generated - we should find those "remaining" numbers using random 😕
it leads to OOM exceptions when you create large number of items, because underlying collection grows too much.

To address those issues I used the Linear Congruential Generator which generates the unique values if constants match the specific criteria. It has very small memory footprint and offers a good generation performance. I used constants from this document, where they mentioned that values are pretty good. Also I've tested all the constants till 2^33 and proven that they indeed produce a unique sequence (there were a few wrong constants, so I fixed them). I haven't tested the constants above because my PC has no enough power for that (RAM and CPU cores).
The issue with LCG is that it always produces the same sequence for the given constants. To overcome that I used a few techniques:

I use the system random to generate a seed - the starting number;
we have a few generator constants for the same value range and we randomly pick the constant to use.

Those approaches allows to make the produced sequence even more random and non-repeating.
A few things we should to be aware of:

Under the hood generator uses the hardcoded constants, meaning that random value range is fixed (this.m-1). To adapt to the required range I ignore random values above the range (see a cycle in the GenerateNextValue() method). In average we ignore a half of the generated numbers as we have constants for each power of 2. So far I haven't noticed any issues with that during testing.
I haven't tested the distribution and randomless quality of the hardcoded constants (using SmallCrush, Diehard and or tests). I believe that it shouldn't be an issue, as we are not a crypt tool and the previous approach didn't guarantee any distribution neither. I reviewed values visually and they look pretty random 😅
I used Debug.Assert() a few times - that condition is never expected to happen logically, however left them for documentation purpose and as a sanity check.

No tests were modified (you might see a refactoring only).
Additionally I've referenced the System.ValueTuple package in the AutoFixture package, so we could use the tuples from C# 7. That shouldn't be an issue as we are still building v4. Also that could enable us to support tuples generation by AutoFixture if needed.
@moodmosaic Please take a look and let me know your opinion. I've spent a few weeks working on this, but it could happen that I overlooked something 😉

The issue with LCG is that it always produces the same sequence for the given constants.

This is NOT an issue; that's how PRNGs are supposed to work 😉

given the same seed
you get back the same result
— so how do you have PRNGs generate random numbers, then?
you make sure to supply a totally random seed
and one way of implementing this is by splitting the seed each time you need to generate a number

I have A LOT feedback to provide here, as my experience from years with AutoFixture, and the issues I've seen by using FsCheck for years, are more or less the result of finding myself working in Hedgehog.
It really depends on you, @zvirja, which direction you'd like to take:

Keep around the existing random number generation (as well as the existing way of dealing with ranges (#919)), which is fine—after all, these are already there, from version 3—though, we'd have to be conservative with bugfixes, as we can easily end up putting a lipstick on pig...
Fix the random number generation by decoupling the 'range' concept (constant, linear, exponential) from the PRNG itself, and use some reasonable seed, preferably SplitMix.

It's exciting that you took the time to tackle this very issue 👍 — I look forward to hearing your decision.

we'd have to be conservative with bugfixes, as we can easily end up putting a lipstick on a pig...

Well, this is approximately what I'm trying to do in this PR 😄 I don't change the overall architecture and
simply change the implementation to require much less memory and provide results with less delay.

It really depends on you, @zvirja, which direction you'd like to take:

Well, actually it's pretty hard for me to decide 😕 The idea of total rework looks attractive, however, I feel that it's probably better to keep the existing approach and simply improve it internally for now. That would decrease the amount of changes we have in v4, as we already applied a set of them. Also that will allow us to save some time and finally release v4 RTM. In v5 when we have more time, we could rework that and probably a few other things.
I feel a high level of uncertainty with this decision, however it looks like a good plan for now.
Does that make sense to you?

I understand that you threw a lot of effort on this, and it is highly appriciated 🎉

However,

Is it a simple change?
Is this set of changes warranted?

Why choose LCG over others, battle-tested ones, like

TFGen
SplitMix

I understand that the current implementation suffers from mediocre performance, however,

we haven't run statistical tests (e.g. diehard) between the current and the proposed implementation.

That being said, it might be just as easy as

trying to 'fix/optimize' the current one, without throwing in a whole bunch of changes.
—or—by moving LCG to its own class, and then change the Fixture instance to use that once instead.

Why choose LCG over others, battle-tested ones, like

I'm not very strong in this particular area, therefore I relied on the Google. I didn't want to change the behavior of the existing generator, and the current one has a full cycle (no repetitions within the range). From what I got we have either LCG or LFSR which could produce such sequences. I ended up with the first one as it was documented to provide a bit better quality. Could the "TFGen"  or "SplitMix" also produce non-repeating values withing the specified range? Otherwise, that change is breaking and it was not my intention.

we haven't run statistical tests (e.g. diehard) between the current and the proposed implementation.

Yep, it's the whole point. While we haven't tested, I 99% sure that the previous generator implementation suffered from the distribution issues due to the nature of its implementation. Therefore, when I decided to replace it with LCG, I assumed that quality is not the strong point here. Rather, we expect have something a bit random and that's enough. The LCG provided me with such values, so ti looked like a good replacement even if I haven't tested that function has good enough quality. The more important thing is that it preserves the full-cycle semantics as that is asserted in our unit tests.

That being said, it might be just as easy as

I don't see too much value in persisting the previous implementation as a new one provides the exactly same output. The observer will not see any difference after this change. The only visible difference might be the changed distribution of numbers, but our tool is not designed to generate random of the perfect quality, so I'm keeping the status quo.
That is how I see the situation and that's why I suggested to proceed with current non-optimal architecture and re-design it later in v5 in a more architectural way if we will.

Probably, from your experience my changes look like a vandalism or something totally amateurish and that might be so. However I didn't pursue a goal to build a generator with a good distribution. Rather I simply wanted to have:

full-cycle generator
which doesn't suffer from current issues
and generates pseudo-random sequence of "non-obvious" quality 😄.

From my perspective this PR achieved that goal.
If you see that my goal is not achieved or you see the issues I've introduced - please share your feedback, so we are aligned. I'd be really happy to learn this area and see why my proposal is not acceptable (if that is so), despite the fact that I've already invested a lot of resources into that.

You did a massive work here, and I think we can use this in place of the RandomNumericSequenceGenerator in Fixture.
Would you mind putting this in a new file named as LinearCongruentialNumberGenerator or LinearCongruentialNumericGenerator if we want to be consistent?
It's just that it feels like we're putting a lipstick on a pig trying to fix the existing one is all 😅

That's the same strategy we used with all sorts of new generators, we never deleted or modified the old ones, and instead we've added new ones. (SOLID can be append-only, too.)

The more I think about this PR and review the stuff, the more internal pain I start to feel 😅
My initial intent was to fix the current generator issues, without changing the observable behavior. I assumed that our clients will not notice any difference after the change, while internally we win performance. In fact, the public API wasn't changed, none of the test failed - I simply adjusted the implementation detail, which is safe to do even in bug fix releases.
Previously, you mentioned and now I that clearly see, that current implementation is.. not the best one. I also don't like the idea that RandomNumericSequenceGenerator has too much responsibilities both in implementation and usage. Because of that class contract is very fuzzy. For instance, if you request sbyte elements, you'll quickly start to see negative numbers due to overflow. As for the int type you would probably never get the negative numbers. This builder blows my mind each time I see it, because it pretends that it offers full cycle, however that will be only if you request "types" large enough to hold that value. I also don't see any reason in that contract. And so on 😧😟😢
I was fine to keep that architecture as-is and simply change the implementation. However, if you decline that idea and the only option is to add a new builder, that's another story. I don't want to add a shiny new builder which will be poisoned by the bad architecture from the beginning. We'll need to keep it in our code for a few major versions even if we have a good replacement. In that light, I'd vote to close this PR (keeping the implementation in branch to re-use it later) and do nothing for now. Later we'll design the better architecture (as you initially suggested) where we'll fix all the drawbacks and split responsibilities, so this issue will be automatically fixed. We can develop that in minor updates, as that will not lead to the breaking changes.
Therefore, let's see your final voice. If you see reasons why we cannot alter implementation of the RandomNumericSequenceGenerator, then let's close the PR - I don't want to spread this chaos across the project 😄

Yes, you probably didn't see any tests failing as we haven't done any statistical testing on what we currently have.

Yep, that is probably the only thing that could be affected. I don't know the project background well to know whether we actually promised the distribution quality to our clients. I was under the impression, that we didn't (as we don't have tests for that) so it's safe to change it.
Therefore, I keep it up to you to decide whether current change is acceptable or not, as you are more experienced on this area than me 😉

I'd rather keep your implementation in a new file as LcgNumericSequenceGenerator, and then change the Fixture class to use this one instead.

If you do that, I have a few comments for your implementation, but you'd have to move it to a new file first.

@moodmosaic In this case let's follow the other option you suggested - decouple random generator (and the range concept) from the RandomNumericSequenceGenerator, that is used to serve number requests.
I suggest to create the following interface in the Random namespace:
interface IRandomGenerator
{
    long GetNextValue();
}

and also probably:
interface IRangedRandomGenerator: IRandomGenerator
{
    (long value, (long min, long max) range) GetNextValueAndRange();
}

The latter one could be used by RandomRangedNumberGenerator, so we don't hardcode the range and use the default one.
With this approach we could:

implement different generators (i.e. Random based, LCG, exponential, etc);
easily customize fixture to use different random generator, as we simply need to change the strategy for the existing builder;
use generators directly when we need random values (e.g. by ElementsBuilder), rather than RandomNumericSequenceGenerator that provides less obvious API.

Is that design fine to you, or you see some drawbacks with it? Is that what you previously meant?

@zvirja, I'm not sure we need to expose (and maintain) interfaces right now. After all,

"clients [...] own the abstract interfaces"
-- Agile Principles, Patterns, and Practices, ch. 11

I think, all we really need is two functions, like those in here and a seed like this one.


Add additional style props

containerStyle
pageStyle
pageStyleLoading

Feel free to reopen this PR if needed, resolving conflicts at the same time


How much free space is actually needed?

Sorry for posting it here, but I didn't found this information anywhere else. I know that it use the bitcoin core database, I saw that we cant use prune too, but is there any other option for reducing the database size? Im using around 300gb and not full synced still.
PS: I'll use it for wallet function only (Exchange).

You need around 400-500gb right now without btc-experimental-balances=1 otherwise it would be above 740GB.