[Bug]: Low trhoughput on AMD MI250 using llama 3.1 (6 toks/s)

Your current environment

The output of `python collect_env.py`
Collecting environment information...
WARNING 09-21 15:25:16 rocm.py:14] `fork` method is not supported by ROCm. VLLM_WORKER_MULTIPROC_METHOD is overridden to `spawn` instead.
2024-09-21 15:25:17.467502: I tensorflow/core/util/port.cc:111] oneDNN custom operations are on. You may see slightly different numerical results due to floating-point round-off errors from different computation orders. To turn them off, set the environment variable `TF_ENABLE_ONEDNN_OPTS=0`.
2024-09-21 15:25:17.520263: I tensorflow/core/platform/cpu_feature_guard.cc:182] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 AVX512F AVX512_VNNI AVX512_BF16 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
PyTorch version: 2.6.0.dev20240915+rocm6.1
Is debug build: False
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: 6.1.40091-a8dbc0c19

OS: Ubuntu 22.04.5 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: version 3.30.3
Libc version: glibc-2.35

Python version: 3.10.14 | packaged by conda-forge | (main, Mar 20 2024, 12:45:18) [GCC 12.3.0] (64-bit runtime)
Python platform: Linux-5.15.0-121-generic-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: AMD Instinct MI210 (gfx90a:sramecc+:xnack-)
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: 6.1.40091
MIOpen runtime version: 3.1.0
Is XNNPACK available: True

CPU:
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        52 bits physical, 57 bits virtual
Byte Order:                           Little Endian
CPU(s):                               64
On-line CPU(s) list:                  0-63
Vendor ID:                            AuthenticAMD
Model name:                           AMD EPYC 9124 16-Core Processor
CPU family:                           25
Model:                                17
Thread(s) per core:                   2
Core(s) per socket:                   16
Socket(s):                            2
Stepping:                             1
BogoMIPS:                             5999.65
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 invpcid_single hw_pstate ssbd mba ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid overflow_recov succor smca fsrm flush_l1d
Virtualization:                       AMD-V
L1d cache:                            1 MiB (32 instances)
L1i cache:                            1 MiB (32 instances)
L2 cache:                             32 MiB (32 instances)
L3 cache:                             128 MiB (8 instances)
NUMA node(s):                         2
NUMA node0 CPU(s):                    0-15,32-47
NUMA node1 CPU(s):                    16-31,48-63
Vulnerability Gather data sampling:   Not affected
Vulnerability Itlb multihit:          Not affected
Vulnerability L1tf:                   Not affected
Vulnerability Mds:                    Not affected
Vulnerability Meltdown:               Not affected
Vulnerability Mmio stale data:        Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   Mitigation; safe RET
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] onnxruntime==1.19.2
[pip3] pytorch-triton-rocm==3.1.0+5fe38ffd73
[pip3] pyzmq==26.2.0
[pip3] sentence-transformers==3.1.0
[pip3] torch==2.6.0.dev20240915+rocm6.1
[pip3] torchaudio==2.5.0.dev20240916+rocm6.1
[pip3] torchvision==0.20.0.dev20240916+rocm6.1
[pip3] transformers==4.44.2
[pip3] triton==3.0.0
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] pytorch-triton-rocm       3.1.0+5fe38ffd73          pypi_0    pypi
[conda] pyzmq                     26.2.0          py310h71f11fc_1    conda-forge
[conda] sentence-transformers     3.1.0                    pypi_0    pypi
[conda] torch                     2.6.0.dev20240915+rocm6.1          pypi_0    pypi
[conda] torchaudio                2.5.0.dev20240916+rocm6.1          pypi_0    pypi
[conda] torchvision               0.20.0.dev20240916+rocm6.1          pypi_0    pypi
[conda] transformers              4.44.2                   pypi_0    pypi
[conda] triton                    3.0.0                    pypi_0    pypi
ROCM Version: 6.1.40093-bd86f1708
Neuron SDK Version: N/A
vLLM Version: 0.6.1.post2@1c1bb388e0d35a2d10da5c5cda2edac57bf62591
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
============================ ROCm System Management Interface ============================
================================ Weight between two GPUs =================================
       GPU0         GPU1
GPU0   0            72
GPU1   72           0

================================= Hops between two GPUs ==================================
       GPU0         GPU1
GPU0   0            3
GPU1   3            0

=============================== Link Type between two GPUs ===============================
       GPU0         GPU1
GPU0   0            PCIE
GPU1   PCIE         0

======================================= Numa Nodes =======================================
GPU[0]          : (Topology) Numa Node: 0
GPU[0]          : (Topology) Numa Affinity: 0
GPU[1]          : (Topology) Numa Node: 1
GPU[1]          : (Topology) Numa Affinity: 1
================================== End of ROCm SMI Log ===================================

Model Input Dumps
No response
🐛 Describe the bug
I'm running vllm serve with vllm serve meta-llama/Meta-Llama-3.1-8B-Instruct --trust-remote-code --tokenizer meta-llama/Meta-Llama-3.1-8B-Instruct --max-num-seqs 1024 --max-num-batched-tokens 1024.
When I send requests to the vllm api, I monitor the gpu usage, it reaches 100% usage and memory usage above 90%, therefore, the GPU is being used but the trhoughput is between 3-6 tok/s.
I'm using rocm 6.1.2, and I installed vllm from source (main 1c1bb388e0d35a2d10da5c5cda2edac57bf62591).
To give a comparison, ollama with llama3.1 get's 85 toks/s with the same rocm version.
Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

@huberemanuel Any update on this?

Hi! I had some help from @daviswer and I was able to achieve better results. In summary, I used the following versions:

ROCm 6.2.0
vLLM 0.5.5
torch 2.5.0
triton 3.0.0

Also, using the following script:
export HIP_FORCE_DEV_KERNARG=1
export VLLM_INSTALL_PUNICA_KERNELS=1
export VLLM_USE_ROCM_CUSTOM_PAGED_ATTN=1
export VLLM_USE_TRITON_FLASH_ATTN=0
export PYTHONPATH=$PYTONPATH:/opt/rocm/share/amd_smi

python3 ./benchmarks/benchmark_throughput.py   --dataset=ShareGPT_V3_unfiltered_cleaned_split.json --model=meta-llama/Meta-Llama-3.1-8B-Instruct -tp=1 --dtype=float16

With those versions, I was able to achieve the following result:
Processed prompts: 100% 1000/1000 [03:07<00:00,  5.32it/s, est. speed input: 1145.65 toks/s, output: 1055.93 toks/s]
Throughput: 5.31 requests/s, 2196.35 tokens/s

ok. Can this issue be closed now? @huberemanuel


Troubleshooting Documentation should include lockout duration information

It wasn't obvious to me that the active directory domain services included an internal lockout period and I thought my account wasn't working. Looks like the default is 1440 minutes or 24 hours on Active Directory and applies here as well, unless changed.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7236bae9-3382-65d8-221e-581be68fb0ba
Version Independent ID: 65bcb458-1a82-9a5a-e2f3-a6d0a633316d
Content: Azure Active Directory Domain Services: Troubleshooting Guide
Content Source: articles/active-directory-domain-services/troubleshoot.md
Service: active-directory
Sub-service: domain-services
GitHub Login: @MikeStephens-MS
Microsoft Alias: mstephen

@nopjmp Thanks for the feedback !  I have assigned this issue to content author to investigate and update the document as appropriate.

Sorry you ran into issues, @nopjmp
For Azure AD DS, five invalid password attempts within 2 minutes on the managed domain cause a user account to be locked out for 30 minutes. After 30 minutes, the user account is automatically unlocked. Invalid password attempts on the managed domain do not lock out the user account in Azure AD. The user account is locked out only within your Azure AD Domain Services managed domain.
You can optionally configure fine grained password policies that change the defaults mentioned above - https://docs.microsoft.com/en-us/azure/active-directory-domain-services/password-policy
I'll update the troubleshooting article to include this information if a user suspects that their account has been locked out.
#in-progress


fix: PluginFunction type is not assignable to type options

How to reproduce
app.ts
Vue.use(InfiniteLoading, {
    slots: {
        noMore: '',
        error: '',
    },
});

TypeScript terminal
No overload matches this call.
  Overload 2 of 2, '(plugin: PluginObject<any> | PluginFunction<any>, ...options: any[]): VueConstructor<Vue>', gave the following error.
    Argument of type 'typeof InfiniteLoading' is not assignable to parameter of type 'PluginObject<any> | PluginFunction<any>'.
      Type 'typeof InfiniteLoading' is not assignable to type 'PluginObject<any>'.
        Types of property 'install' are incompatible.
          Type 'PluginFunction<never>' is not assignable to type 'PluginFunction<any>'.
            Type 'any' is not assignable to type 'never'.

How to fix

fix plugin install with assignable options type PluginFunction<never> to PluginFunction<InfiniteOptions>

@PeachScript , I also stumbled upon it. Can you, please, merge this PR?

@ArthasEclat of course yes :D

@PeachScript : Can you publish latest release with merged this to registry? I think its not published npm registry yet

@PeachScript I have the same problem too. Could you please publish npm registry?

@unachang113 sorry for late, v2.4.5 released


Version mismatched

Tag: v0.1.1
package.json: 0.1.0
To fix: update package.json version, then re-tag v0.1.1

A newer version has already been released.


Fix _changes?filter=_design

Overview
_changes?filter=_design was returning a
{
  "error": "unknown_error",
  "reason": "function_clause",
  "ref": 240731020
}

This PR fixes that and re-enabled the related elixir test.
Testing recommendations

mix test --trace test/elixir/test/changes_test.exs:220
Related Issues or Pull Requests

Checklist

[ ] Code is written and works correctly
[ ] Changes are covered by tests
[ ] Any new configurable parameters are documented in rel/overlay/etc/default.ini
[ ] A PR for documentation changes has been made in https://github.com/apache/couchdb-documentation

Thank you for the review, @nickva ! I'm about to merge this.


Issue to tag new releases

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/29224
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.1 -m "<description of version>" c50a7340384ff1825d44df45ebbfd3b4b537d950
git push origin v0.1.1

Also, note the warning: This looks like a new registration that registers version 0.1.1.
Ideally, you should register an initial release with 0.0.1, 0.1.0 or 1.0.0 version numbers
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/29586
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.3 -m "<description of version>" b303a8f893617722b17d2b769397cc5317cf6fba
git push origin v0.1.3

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/29750
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.4 -m "<description of version>" 5e3341f093faf27a8e3e62d2fb7d9822ce951f60
git push origin v0.1.4

@JuliaRegistrator register
release notes:

extend compat for MLJModelInterface to include v1.0

Registration pull request created: JuliaRegistries/General/34795
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.5 -m "<description of version>" 0b3ad1df4fc3f9e1515c782f0d22e7141115160b
git push origin v0.1.5

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/41130
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.6 -m "<description of version>" 354e1b61f318d60bad947b866a09091a24876be2
git push origin v0.1.6

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/52904
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.0 -m "<description of version>" 16481631b2fecdc32de8d9e4880f30dd731fb08c
git push origin v0.2.0

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/69725
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.1 -m "<description of version>" ffa561d38e0747f2f9b87e9b0f8c9ab2baf123a8
git push origin v0.2.1

Registration pull request created: JuliaRegistries/General/80060
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.2 -m "<description of version>" ef0b6622ac251b68810deddbd4e2c39c4b534bbc
git push origin v0.2.2

@JuliaRegistrator register branch=master

Registration pull request created: JuliaRegistries/General/83623
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.3 -m "<description of version>" 0664bab3ab3e6a09a10af344c745a7da48c2a977
git push origin v0.2.3


Update Quickstart Sample to use beta.4

@hamiltonha Heads-up that there are some changes here that will need to be backfilled into the quickstart and tutorial on docs.microsoft.com that this sample backs.

https://docs.microsoft.com/azure/active-directory/develop/quickstart-v2-javascript-auth-code
https://docs.microsoft.com/azure/active-directory/develop/tutorial-v2-javascript-auth-code

Cc: @sameerag @pkanher617


Unable to use development plugins with flag --use-plugins

I made some changes into the plugin code and then followed the same instructions to uninstall the production version plugin and then run clean & build scripts and thereafter used the same version to restart appium server with the altunity plugin but the plugin isn't getting activated after that.
The version was changed to 1.3.3 from 1.3.2.
List Installed Plugins,
➜  appium-altunity-plugin git:(master) ✗ appium plugin list
✔ Listing available plugins
-<EMAIL_ADDRESS>[installed (dev mode)]
- images [not installed]
- execute-driver [not installed]
- relaxed-caps [not installed]
- universal-xml [not installed]

Appium Logs when plugin is enabled with the provided flags,
➜  appium-altunity-plugin git:(master) ✗ appium --use-plugins=altunity
[Appium] Welcome to Appium v2.0.0 (REV 9600617c52d0d2e48493424c529ac6c945d2775b)
[Appium] Non-default server args:
[Appium] {
[Appium]   usePlugins: [
[Appium]<EMAIL_ADDRESS>[Appium]   ]
[Appium] }
[Appium] Attempting to load driver uiautomator2...
[debug] [Appium] Requiring driver at /Users/bipinchaurasia/Documents/github/appium-altunity-plugin/node_modules/appium-uiautomator2-driver
[Appium] Appium REST http interface listener started on http://<IP_ADDRESS>:4723
[Appium] You can provide the following URLS in your client code to connect to this server:
[Appium] 	http://<IP_ADDRESS>:4723/ (only accessible from the same host)
[Appium] 	http://<IP_ADDRESS>:4723/
[Appium] 	http://<IP_ADDRESS>:4723/
[Appium] Available drivers:
[Appium]   -<EMAIL_ADDRESS>(automationName 'UiAutomator2')
[Appium] Available plugins:
[Appium]   -<EMAIL_ADDRESS>[Appium] No plugins activated. Use the --use-plugins flag with names of plugins to activate

Not sure what you're trying to report is going on here. Are you wanting to use a developer branch of this plugin? In that case, simply run npx appium --use-plugins=altunity from within this repo's directory and appium will find this plugin


Upgrade solana to 1.16.1

Upgrading solana to version 1.16.1
Upgrading rust version to 1.69.0
Updating cargo audit to the latest version 1.17.6
Temporarily disabling build warnings in the ci due to deprecation of Pubkey::new

Closing this since it was done in #4592


Radio and checkbox toggles size

Radio toggles are about 40x40px what is right IMHO while Checkbowes are only 36x36px.

Can you point out where you are getting the sizes from in the specification? I'm not seeing them mentioned anywhere on the selection control page.

@Garbee Dont know exact size, looked at https://www.google.com/design/spec/components/lists.html#lists-specs where checkbox is in the place of avatar whis is 40x40px. The point is  - radio and checkbox controls have different blocks sizes in MDL http://www.getmdl.io/components/index.html#toggles-section. There is a chance I'm mistaken but I suppose they should be the same size.

List design may be its own sizing. I'm not even seeing exactly where checkboxes are placed instead of avatars. There are some squares, but they could be placeholders for icons.
cc @santokii to see if we can get some guidance here without needing to go back to the MD team directly.

Radios and checkboxes will be reimplemented as #4477 and #4471. Not feasible to fix until then.


Methods to check if the Sequence is Increasing or Decreasing

IsIncreasing and IsDecreasing verifies whether the underlying sequence is sorted in Ascending Order / Descending Order / Random Sequence.

:memo: PR for #532

Closing this since #532 has been closed too.


Dart2js does not support a generic mixin application as mixin.

FAILED: dart2js-d8 release_ia32 language/mixin_mixin2_test
Expected: pass
Actual: fail
CommandOutput[dart2js]:
CommandOutput[d8]:
stdout:
/usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js:734: Expect.equals(expected: <num>, actual: <dynamic>) fails.
  throw $.wrapException(new $.ExpectException(message));
          ^
Error
    at wrapException (/usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js:315:13)
    at Expect__fail (/usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js:734:11)
    at Expect_equals (/usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js:730:5)
    at main (/usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js:745:5)
    at /usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js:868:7
    at init.currentScript (/usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js:838:5)
    at /usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js:856:3
    at /usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js:1073:3
Command[dart2js]: out/ReleaseIA32/dart-sdk/bin/dart2js --allow-mock-compilation --categories=all --package-root=out/ReleaseIA32/packages/ /usr/local/google/home/regis/dart2/dart/tests/language/mixin_mixin2_test.dart --out=/usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js
Took 0:00:01.451000
Command[d8]: /usr/local/google/home/regis/dart2/dart/third_party/d8/linux/d8 /usr/local/google/home/regis/dart2/dart/out/ReleaseIA32/generated_tests/dart2js-d8/tests_language_mixin_mixin2_test/out.js
Took 0:00:00.040000
Short reproduction command (experimental):
    python tools/test.py --use-sdk -mrelease -cdart2js -rd8 -t60 language/mixin_mixin2_test
===
=== 1 test failed
===

The issue with language/mixin_mixin2_test is that the intermediate types Set and Map are not in the program, causing RuntimeType.toString to crash because the type term has null classes.


fix some 0.4 deprecation warnings

Sorry about the trailing whitespace fixes, I have my editor automatically remove them when I save a Julia file.

No problem, thanks for the fix.


doesn't work in sketch 40.3

I downloaded the zip, installed manually and tried to use the example provided. When I change color values in the stylesheet file (sass or less) nothing changes in my .sketch file.

+1

Also doesn't work in 41 unfortunately.

Fixed it and did a pull request but I guess that John Coates is a bit to busy right now.
You can find my fork over here
https://github.com/samueljoos/CSSketch

@samueljoos I cloned your repo into Plugins but when I restarted and tried to install, Sketch shows message that it is already installed. Is there a cache that has Sketch already thinking that it is installed even though I did rm -rf on the previous directory before cloning yours?

You might need to remove the old version from you plugins folder first.
More information to find your plugins folder is here:
http://developer.sketchapp.com/introduction/installing-plugins/

@samueljoos I tried to install yours. But it still doesn't work on 41.1

@samueljoos Yes I had already removed the old version before cloning yours. I was not able to get it to work with the 41.1

Hi friends. I also tried using this plugin (original version and samueljoos version) and both didn't work. Changes on the CSS files don't do anything on the sketch file. My sketch version is 41.2 (35397). Anyone can help? I'm looking to use it soon! Thanks!

Hi guys, just to let you know, I really wanted to try this plugin so I tested it with other sketch versions below the current version.  With Sketch 3 it will work, if you are interested in just testing it for a while until it's not fixed for newest version but just for experimenting I recommend going to this page and download the older versions: https://www.sketchapp.com/updates/
Hope at least you can see how it works. Hope the owner will update it soon so we can use it with version is 41.2.

Are there some news about this issue? We need this plugin to work with the latest version.


NominalParamDef and BayOpt

If I'm understanding correctly, NominalParamDef instances are currently not compatible with the 'BayOpt' optimizer.  The way I found this out initially was from the error
Traceback (most recent call last):
  File "apsis/assistants/experiment_assistant.py", line 128, in get_next_candidate
    self.optimizer.get_next_candidates(self.experiment))
  File "apsis/optimizers/bayesian_optimization.py", line 127, in get_next_candidates
    self._refit(experiment)
  File "apsis/optimizers/bayesian_optimization.py", line 158, in _refit
    warped_in = experiment.warp_pt_in(c.params)
  File "apsis/models/experiment.py", line 278, in warp_pt_in
    warped_in[name] = self.parameter_definitions[name].warp_in(value)
AttributeError: 'NominalParamDef' object has no attribute 'warp_in'

I think this could be handled better - e.g. by checking that all parameters have the method warp_in on initialization of the experiment and raising an appropriate error if not.  Alternatively, if possible, it seems like it'd be worthwhile to provide a ParamDef which implements the simple hack of quantizing a floating point value.

Here's a hack for a "quantize-to-list" parameter definition:
class QuantizedListParamDef(apsis.models.parameter_definition.NumericParamDef):
    '''
    Defines a parameter value which can take one of a finite number of
    enumerable values by quantizing the space between [0, 1] and mapping it
    to indices of the values.
    '''
    values = []

    def __init__(self, values):
        '''
        Initializes the possible values the parameter can take.

        Parameters
        ----------
        values : list
            List of permissable values.
        '''
        try:
            self.values = list(values)
        except:
            raise ValueError('values must be a list of possible values.')
        self.values = values

    def warp_in(self, value_in):
        return self.values.index(value_in)/float(max(len(self.values) - 1, 1))

    def warp_out(self, value_out):
        return self.values[int((value_out - 1e-10)*len(self.values))]

    def is_in_parameter_domain(self, value):
        return self.values.count(value) > 0

I get the following warning: WARNING - L-BFGS-B Optimization produced only parameter values thatdo not match the defined parameter range. This indicates that increasing the parameter definition range mightdeliver better results.Using results from RandomSearch. It appears that the optimizer uses the bound [0, 1] for all parameters, and then tests whether the resulting parameter values are valid.  Given that those are the bounds (this appears to be true even for MinMaxNumericParamDef instances where the range is not [0, 1]), it seems like the resulting values should be warped before being used, but I'm likely just misunderstanding the intended usage.  Any tips are appreciated.

First of all, thanks for the issue!
Your first issue is a limitation for Bayesian Optimization coupled with an overlooked error message by us. This is similar to #111. The function to check for it exists, it just wasn't used. The branch i111_exp_check has a fix for it, and we'll include it in the next release.
It's pretty difficult to warp a categorical parameter definition to something made up of floats; to my knowledge, apart from warping it into an n-dimensional [0, 1] hypercube for n different possible values of the categorical parameter, there's no paper describing a way to do it. The hypercube model is, apparently, comparatively inefficient why we haven't implemented it. I'll do so for the next release, but am currently working on support for multiple workers/clusters, which will still take some time.
As to your hack: There already exists a class of parameter definitions which you can modify for that, which is PositionParamDef. PositionParamDef maintains one list each for a value and a position for that value, whose warping will be done automatically. By defining something like this:
class EquidistantPositionParamDef(PositionParamDef):
    """
    Extension of PositionParamDef, in which the position of each value is
    equidistant from its neighbours and their order is determined by their
    order in values.
    """
    def __init__(self, values):
        positions = []
        for i, v in enumerate(values):
            pos = float(i)/(len(values)-1)
            positions.append(pos)
        super(EquidistantPositionParamDef, self).__init__(values, positions)

you can then initialize it with your categorical parameter definition. The above should work, and is pushed to the branch i_117_equidistant_fix.
However, I am not sure it will actually help you (much) with categorical parameters, because it implies a certain structure in these parameters which might or might not exist. For example, if you use [sigmoid, rectifiers, tanh] as activations for a neural network layer, depending on the order in which you define them, there will be different results. This is because the GP will assume that, in the example above, the result of a network with only the activation changed from sigmoid to rectifiers will be closer to the sigmoid result than if you would change it to tanh. Of course, it's probably still better than random search :-)
I hope that the above helped you, and I'd be happy if you could tell us about your experiences with it.

First of all, thanks for the issue!

Thanks for your thorough response!

Your first issue is a limitation for Bayesian Optimization coupled with an overlooked error message by us. This is similar to #111. The function to check for it exists, it just wasn't used. The branch i111_exp_check has a fix for it, and we'll include it in the next release.

Great, thanks.

It's pretty difficult to warp a categorical parameter definition to something made up of floats; to my knowledge, apart from warping it into an n-dimensional [0, 1] hypercube for n different possible values of the categorical parameter, there's no paper describing a way to do it. The hypercube model is, apparently, comparatively inefficient why we haven't implemented it. I'll do so for the next release, but am currently working on support for multiple workers/clusters, which will still take some time.

Wouldn't this still require quantization; specifically, quantization around .5 for each hypercube dimension (or something)?

As to your hack: There already exists a class of parameter definitions which you can modify for that, which is PositionParamDef. PositionParamDef maintains one list each for a value and a position for that value, whose warping will be done automatically. ... The above should work, and is pushed to the branch i_117_equidistant_fix.

Cool, I will try it now.  As a side note, from a development standpoint, it would be cool if all of the "stable, to be included in the next release" branches were merged into a single "development" branch, so it was easy to use e.g. i111_exp_check and i_117_equidistant_fix at the same time.

However, I am not sure it will actually help you (much) with categorical parameters, because it implies a certain structure in these parameters which might or might not exist. For example, if you use [sigmoid, rectifiers, tanh] as activations for a neural network layer, depending on the order in which you define them, there will be different results. This is because the GP will assume that, in the example above, the result of a network with only the activation changed from sigmoid to rectifiers will be closer to the sigmoid result than if you would change it to tanh. Of course, it's probably still better than random search :-)

From a high-level point, I'm not clear why order is important - it seems to me that the GP wouldn't care about order as it's not assuming any sort of consistent correlation between a change in hyperparameter values and objective values, right?
Thanks for your responses!

For what it's worth, I still get the warning WARNING - L-BFGS-B Optimization produced only parameter values thatdo not match the defined parameter range. This indicates that increasing the parameter definition range mightdeliver better results.Using results from RandomSearch. when using EquidistantPositionParamDef.  As before, L-BFGS-B is constrained for all parameters on the interval [0., 1.], and the check is_in_parameter_domain for EquidistantPositionParamDef is just the one for NominalParamDef:
    def is_in_parameter_domain(self, value):
        """
        Tests whether value is in self.values as defined during the init
        function.
        """
        return value in self.values

which is typically false, because self.values in EquidistantPositionParamDef is just a list of arbitrary values which may or may not include the values in [0., 1.].  Any ideas?

Wouldn't this still require quantization; specifically, quantization around .5 for each hypercube dimension (or something)?

Not quite. If you are using Automated Relevance Determination (ARD, see for example Gaussian Processes in Machine Learning pg 106, of which an online version can be found here) - which apsis does by default - you can learn different length scales for the different parameters.
Suppose, for example, that you have three categorical values, A, B and C. A is encoded by [1, 0, 0], B by [0, 1, 0] and C by [0, 0, 1]. Gaussian processes define similarity via a distance metric; let's just use Manhattan distance here. Without modification of the distances, all distances are 2.
Using ARD, you now can learn some distance factor per dimension. In the above, maybe this factor is 0.25, 0.5, 3 for the three dimensions. This means our learned distances are now AB=0.75, BC=3.5 and AC=3.25 - and suddenly, you have learned that exchanging A for B means the result is closer to the original than exchanging C for B.
There are - apparently - still some shortcomings of this, mostly corresponding to difficulties of the GP to adequately explore the corners of the hypercube (which is where most of the interesting stuff happens using this method).

From a high-level point, I'm not clear why order is important - it seems to me that the GP wouldn't care about order as it's not assuming any sort of consistent correlation between a change in hyperparameter values and objective values, right?

Correct, but it does care about the distance between the points. For example, assume you have three points X, Y and Z. You know the results for X and Z, and want to find out the result of Y. If the distance between X and Y is less than the distance between Y and Z, the predicted result for Y is going to be closer to the result of X than to the result of Z.
To visualize this, look at this picture, which you can also find in the paper on page 2.:

The red point's result depends more on the result of the three points to the right of it than of the three points to the left. (I just notice that this might pose problems to red/green colour blindness; the red point is the middle one at ca 0.7.)
This is also why projecting categorical data on a single [0, 1] axis may pose a problem. If you project the classes from our example above to [A, B, C] --> [0, 0.5, 1] you implicitly tell the GP that the distances AB = BC = 2AC compared to the above where AB = 4.66BC = 4.33AC. And, had you changed the order to [A, C, B] --> [0, 0.5, 1], you'd have distances of AC = CB = 2AB, which is pretty much the opposite compared to the distances learned above.

Cool, I will try it now. As a side note, from a development standpoint, it would be cool if all of the "stable, to be included in the next release" branches were merged into a single "development" branch, so it was easy to use e.g. i111_exp_check and i_117_equidistant_fix at the same time.

That's a very good point. I've created it.

For what it's worth, I still get the warning WARNING - L-BFGS-B Optimization produced only parameter values thatdo not match the defined parameter range. This indicates that increasing the parameter definition range mightdeliver better results.Using results from RandomSearch. when using EquidistantPositionParamDef.  As before, L-BFGS-B is constrained for all parameters on the interval [0., 1.], and the check is_in_parameter_domain for EquidistantPositionParamDef is just the one for NominalParamDef:

def is_in_parameter_domain(self, value):
    """
    Tests whether value is in self.values as defined during the init
    function.
    """
    return value in self.values

> which is typically false, because self.values in `EquidistantPositionParamDef` is just a list of arbitrary values which may or may not include the values in [0., 1.].  Any ideas?

I've looked through the code again, and this is a pretty relevant bug you've detected. I've corrected it.

Some more details, if you are interested:
Currently, the optimization of the acquisition function works like this: It generates a set of random points equivalent to `initial_random_runs`, then (unless you've chosen a random optimizer) it optimizes with these as its starting points. Remember that we can sample from the acquisition function several orders of magnitude faster than from the real objective function (significantly less than a second compared to minutes, hours or days for the bigger machine learning problems).

Afterwards, for each of the generated samples, we check whether it's a correct sample. If it isn't, we add the random sample from which the optimization originated instead.

This check was wrongly implemented. Instead of checking whether the generated parameter vector was in [0, 1] ^N (we're working with only a [0, 1] hypercube in `AcquisitionFunction`), we checked whether each of the generated parameter values was an acceptable value for the parameter. So, for example, if we had a `MinMaxNumericParamDef` instance whose value could be between [0, 0.5], we'd have checked whether the internal hyper-cube value was between [0, 0.5] which would have meant that we'd only use L-BFGS optimized values when optimizing on parameter between \[0, 0.25] (after warping out).

This would've resulted (especially with things like `DistanceBasedParamDef`) in the optimizer only using random optimization on the acquisition function instead of L-BFGS. This is worse than using a real optimizer, but it's probably still better than `RandomSearch` which is why we've only logged a warning instead of an exception.

Instead, we're now checking whether the vector is actually in [0, 1]^N, and I've clarified the `is_in_parameter_domain` docstring to clearly state that we should only work with original, non-warped parameter values in that.

Correct, but it does care about the distance between the points.

Ah, thanks for your thorough explanations - I see now why the hypercube method makes a lot more sense in this setting.  In that case, I may take a hack at implementing that, as all of my discrete parameters only have 3 or 4 values.

That's a very good point. I've created it.

Thanks!

I've looked through the code again, and this is a pretty relevant bug you've detected. I've corrected it.
...
nstead, we're now checking whether the vector is actually in [0, 1]^N, and I've clarified the is_in_parameter_domain docstring to clearly state that we should only work with original, non-warped parameter values in that.

Thanks - this is what I had suspected was happening.  Will give everything a go again.

In that case, I may take a hack at implementing that, as all of my discrete parameters only have 3 or 4 values.
You've given me the motivation to implement it myself. Look into the i_117_nominal_hypercube branch. I've not yet merged it into dev because I had no chance to test it on nominal parameters, but all the other tests still pass. If it works for you, I'll write a few more tests then merge it to dev.

The main difference is that now, instead of warping any given parameter to just [0, 1] we warp it to [0, 1]^N where N is given in param_def by the warped_size function. This is (usually) 1, except for, for example, NominalParamDef.

Sorry, I'm not seeing param def in the i_117_nominal_hypercube branch which warps onto the [0, 1]^N hypercube, can you point me to the right one to try?  Thanks.

Any ParamDef does so now. Granted, most of them still point to [0, 1]^1 as before.
All classes inheriting from ParamDef must implement the warp_in, warp_out and warping_size functions (see lines 47-89). The main change in practice is to NominalParamDef and all classes inheriting from that - in your case, simply using NominalParamDef should work; the new warping is done internally.

Ok, trying it out and I'm getting an error because NominalParamDef calls warped_value.index in warp_out, and warp_out is called by RandomSearch's _gen_param_val method with a np.ndarray.  A simple fix would be to always cast warped_value to a list in warp_out.
  File "apsis/assistants/experiment_assistant.py", line 128, in get_next_candidate
    self.optimizer.get_next_candidates(self.experiment))
  File "apsis/optimizers/bayesian_optimization.py", line 130, in get_next_candidates
    return self.random_searcher.get_next_candidates(experiment, num_candidates)
  File "apsis/optimizers/random_search.py", line 50, in get_next_candidates
    list.append(self._get_one_candidate(experiment))
  File "apsis/optimizers/random_search.py", line 57, in _get_one_candidate
    value_dict[key] = self._gen_param_val(param_def)
  File "apsis/optimizers/random_search.py", line 77, in _gen_param_val
    return param_def.warp_out(self.random_state.uniform(0, 1, param_def.warped_size()))
  File "apsis/models/parameter_definition.py", line 181, in warp_out
    return self.values[warped_value.index(max(warped_value))]
AttributeError: 'numpy.ndarray' object has no attribute 'index'

I've both changed random search's call and added the conversion in NominalParamDef.
Also, since I've written some tests for it, I have fixed the creation of L-BFGS-Bounds which had a bug only occuring when using parameter definitions whose warping_size was not 1 and fixed AsymptoticParamDef's warping.
Sorry for not testing for those before; I wanted to get you the changes yesterday. All unit tests are working now, and include NominalParamDef for BayOpt.

Seems like it's working to me!  Thanks for all your help!

Awesome! How's your experience with it?

I've been running random hyperparameter search for a while and have your BayOpt version working, so I will be switching over to that soon.  I had previously been using Spearmint, and although it was working better than random search on this problem, using it was a huge pain and it seems bad to use software which isn't actively developed and with a non-permissive license... so, I look forward to re-running it with your BayOpt version!


[Optimization] Remove redundant throws

What is the purpose of the change
This method has no compile-time exception, so we don't need to throw it

Checklist

[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.
[x] Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] 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 sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #9969 (3ca951d) into 3.0 (51c7b15) will decrease coverage by 0.57%.
 Consider uploading reports for the commit bdd0661 to get more accurate results

@@             Coverage Diff              @@
##                3.0    #9969      +/-   ##
============================================
- Coverage     65.72%   65.15%   -0.58%
+ Complexity      320      294      -26
============================================
  Files          1215     1215
  Lines         53038    53031       -7
  Branches       8036     8010      -26
============================================
- Hits          34860    34553     -307
- Misses        14377    14664     +287
- Partials       3801     3814      +13

Impacted Files
Coverage Δ

...dubbo/rpc/protocol/dubbo/CallbackServiceCodec.java
82.46% <ø> (ø)

...luster/router/script/ScriptStateRouterFactory.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...zookeeper/curator/CuratorZookeeperTransporter.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...pc/cluster/router/file/FileStateRouterFactory.java
0.00% <0.00%> (-80.96%)
:arrow_down:

...o/rpc/cluster/router/script/ScriptStateRouter.java
0.00% <0.00%> (-67.31%)
:arrow_down:

...ting/zookeeper/curator/CuratorZookeeperClient.java
16.34% <0.00%> (-52.89%)
:arrow_down:

...dubbo/remoting/zookeeper/ZookeeperTransporter.java
55.55% <0.00%> (-33.34%)
:arrow_down:

.../remoting/api/SingleProtocolConnectionManager.java
61.53% <0.00%> (-23.08%)
:arrow_down:

...nt/metadata/ServiceInstanceHostPortCustomizer.java
65.78% <0.00%> (-21.06%)
:arrow_down:

.../apache/dubbo/rpc/filter/ProfilerServerFilter.java
62.85% <0.00%> (-20.00%)
:arrow_down:

... and 58 more

Continue to review full report at Codecov.

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


Include dependencies and let some code more readable

Changes

Include forgotten tests and locals dependencies
Refactor some comparison condition
Make the apply_message_translator function more readable

Congratulations! Great lib 🥇

hey @silviolleite thanks for your collaboration.
I'll check it later for more feedback. o/


update(changelog): add changelog for falco 0.39.0

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

/kind release

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area engine

/area tests

/area proposals

/area CI

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: alacuku
Once this PR has been reviewed and has the lgtm label, please assign andreagit97 for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/milestone 0.39.0

LGTM label has been added.  Git tree hash: 8a092a8d47e201c8228b97fca08c3d82451e3214

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: alacuku, FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Revert "Revert "[BinderTransport] Send correct version to server and …

Reverts #28090
msan test failed before because the mock object returns uninitialized
value and the code tries to conditionally log when the value is wrong.
Some EXPECT_CALL are removed because enforces how the code under test reads parcel, which might be too strong. (we should prefer checking the externally observable behavior of the classes) and we EXPECT_CALL the code that read the version inside the mock object that gives transaction to the class under test instead.

Basic Tests Python Windows timeouts
Basic Tests ObjC iOS  xcodebuild: error: 'Tests.xcworkspace' does not exist.


error from daemon in stream: Error grabbing logs: EOF

HI,
Since 1 month I'm having this error and can't resolve it . apsl/thumbor is throwing a 502 and when I try to check the logs I have this error : error from daemon in stream: Error grabbing logs: EOF
It appears that this is an error within the container of apsl.
Does someone had this issue before? and know how to fix this ?
Thanks.

I don't think this project is actively maintained. Take a look at https://github.com/MinimalCompact/thumbor - maybe it helps solve your problem? Otherwise, feel free to open an issue with more details and I hope someone can help.


capture / silence julia initialization in stdout

Hello,
I am trying to run a julia program inside python with juliacall and use the stdout. I am having a bit of trouble because stdout is polluted by me running from juliacall import Main as jl and I was wondering if there is a way to capture or silence this output.
Cheers,
Alex

If you're referring to the logging that happens when dependencies are resolved, then I'm afraid there is no way to turn those off currently.
For generic capturing of stdout, see https://www.devdungeon.com/content/python-use-stringio-capture-stdout-and-stderr
I can't really help without more specifics of what you're doing (ideally give a MWE).

Thank you for the quick reply. I was able to work around the issue as soon as I understood a bit more what was happening.
The part I left out in my post because I didn't consider it part of the issue was that I was running this in a docker container. As you correctly identified, I was referring to the dependency resolution (or is there more happening?). What I didn't realize because I am in a container is that this usually only happens once, so after adding RUN python3 -c "from juliacall import Main as jl to the container build, the dependencies are not checked every time I run but at container build.
This stops the stdout from being polluted, and I can read from it and process the output as I intended.
I am happy with my solution, so I am closing the issue, but if you are looking for a feature request it would be disabling the output of the dependency resolution by some environment variable or whatever you consider a good mechanism.
I also noticed that the first execution of my function takes longer (my interpretation is compilation of the function) and I was wondering if there is a recommendation on how to provide precompiled functions in docker?


Sync eng/common directory with azure-sdk-tools for PR 3457

Sync eng/common directory with azure-sdk-tools for PR https://github.com/Azure/azure-sdk-tools/pull/3457  See eng/common workflow

/azp commands

/azp run java - storage - tests, java - keyvault - tests, java - eventhubs - tests

Failure in java - keyvault - tests is happening in other builds

/check-enforcer override


Parse Yokogawa data with overlap

When parsing grids of yokogawa data with overlap, let's move the individual tiles such that there is no overlap.
The only thing we will initially support are grids with regular overlap. Thus, we can calculate the shift that will be necessary and ensure that the overlap is regular after metadata parsing.
See https://github.com/fractal-analytics-platform/fractal-tasks-core/issues/15 for detailed discussion of how we handle overlap and https://github.com/fractal-analytics-platform/fractal-tasks-core/issues/11 for an overview of the image data modalities. This is modality # 2: Grid imaged with overlap

The next thing to be done here is that we get a reasonable, small, real-world test set to check whether the current implementation already works. I've seen that it fails when there is some non-regular overlap (see https://github.com/fractal-analytics-platform/fractal-tasks-core/issues/110). That's fine, because that's the current scope. I wonder though whether with the 1 pixel shifts, this actually won't hold up as well and also run into this error by chance?
=> to be tested! :) Maybe it already works well, we need to get a fitting dataset @gusqgm :)

Hey there!
just added information on this test dataset. It has 50 pixel overlap between FOV's, so it will be interesting to test run it and see if Fractal manages to put FOV's side by side. more information can be found in the list. Curious to see its output!

This is working well now. Fractal parses images with overlap, moves them so that they are just next to each other, but keeps track of the original positions in the FOV_ROI table.
See here for the example of this running for the dataset mentioned above: https://github.com/fractal-analytics-platform/fractal-demos/tree/fb71f0e03b77eb7d6ada92e42e7674c9cf64375e/examples-v1/17_Overlap
It then looks like this (a small shift between the two FOVs because we imaged with overlap):

Or like this as an overview:


We were going with type-less variable

Compiling with clang -std=c++98/03 didn't catch that log
didn't have any type. But clang -std=c++11/14 did help us.
GCC also wasn't any help to warn that in following variable log
log = log_in;

couldn't get its rightful type.
Fix: auto log = log_in; needs C++11/14 but it's
good even parameter type change Install function.
If we have C++98/03
ngx_log_t* log = log_in;

works well.

The code in question is:
namespace {

ngx_log_t* log = NULL;
...
}  // namespace

namespace net_instaweb {

namespace log_message_handler {

void Install(ngx_log_t* log_in) {
  log = log_in;
  ...
}

}  // namespace log_message_handler

}  // namespace net_instaweb

Changing log = log_in to ngx_log_t* log = log_in would not do what we want: the goal of that code is to store the log_in pointer in the global variable log.
What's the error message clang gives?

Sorry I commited out of my morning's cloudy memory rather than right from the terminal.
Actually it is a case of name lookup which results in ambiguity.
A macro expansion clash with global "log".
This is the error on my terminal:
make[1]: Entering directory `/home/fooldo/cppfool/buildhelp/nginx/nginx-1.6.2'
clang++ -c -pipe  -O -std=c++11 -Wall -Wextra -Wpointer-arith -Wconditional-uninitialized -Wno-unused-parameter -g  -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -I src/http -I src/http/modules -I src/mail  -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/third_party/chromium/src -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/third_party/google-sparsehash/src -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/third_party/google-sparsehash/gen/arch/linux/x64/include -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/third_party/protobuf/src -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/third_party/re2/src -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/out/Release/obj/gen -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/out/Release/obj/gen/protoc_out/instaweb -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/third_party/apr/src/include -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/third_party/aprutil/src/include -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/third_party/apr/gen/arch/linux/x64/include -I /home/fooldo/cppfool/workcopy/ngx_pagespeed//psol/include/third_party/aprutil/gen/arch/linux/x64/include
-o objs/addon/src/log_message_handler.o \
/home/fooldo/cppfool/workcopy/ngx_pagespeed//src/log_message_handler.cc
/home/fooldo/cppfool/workcopy/ngx_pagespeed//src/log_message_handler.cc:102:3: error: reference to
'log' is ambiguous
log = log_in;
^
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:109:13: note: candidate found by name lookup is 'log'
__MATHCALL (log,, (Mdouble __x));
^
/usr/include/math.h:53:25: note: expanded from macro '__MATHCALL'
__MATHDECL (Mdouble,function,suffix, args)
^
/usr/include/math.h:55:22: note: expanded from macro '__MATHDECL'
__MATHDECL_1(type, function,suffix, args);
^
/usr/include/math.h:63:31: note: expanded from macro '__MATHDECL_1'
extern type __MATH_PRECNAME(function,suffix) args __THROW
^
/usr/include/math.h:66:42: note: expanded from macro '__MATH_PRECNAME'
#define __MATH_PRECNAME(name,r) __CONCAT(name,r)
^
/usr/include/x86_64-linux-gnu/sys/cdefs.h:88:23: note: expanded from macro '__CONCAT'
#define __CONCAT(x,y)   x ## y
^
/home/fooldo/cppfool/workcopy/ngx_pagespeed//src/log_message_handler.cc:41:12: note: candidate found by
name lookup is '(anonymous namespace)::log'
ngx_log_t* log = NULL;
^
/home/fooldo/cppfool/workcopy/ngx_pagespeed//src/log_message_handler.cc:107:7: error: reference to
'log' is ambiguous
if (log->log_level >= NGX_LOG_DEBUG) {
^
long
/home/fooldo/cppfool/workcopy/ngx_pagespeed//src/log_message_handler.cc:107:10: error: cannot use arrow
operator on a type
if (log->log_level >= NGX_LOG_DEBUG) {
^
/home/fooldo/cppfool/workcopy/ngx_pagespeed//src/log_message_handler.cc:107:10: error: variable
declaration in condition must have an initializer
5 errors generated.

From the error message it looks like mathcalls.h defines a function log to handle natural logarithms, and then we define a ngx_log_t* log as a pointer to the global log file.  How is mathcalls.h getting included?
It seems like one way to fix this would be for us to just call our variable ps_log instead of log.  Does renaming all the uses of log in log_message_handler.cc fix the problem you're seeing?

Renaming log into ps_log seems to have fixed the problem at hand.
But I'am saying this only after compilation. Testing has to be done yet.
/usr/include/x86_64-linux-gnu/bits/mathcalls.h might have come from
inbuilt(ubuntu's software channel) gcc's installation on my Linux-mint machine.

When we plan to move with c++11/14,
code ngx_log_t* ps_log = nullptr;
might not give us surprises
as code ngx_log_t* ps_log = NULL; might.

If testing works ok, could you update your pull request to do the log to ps_log rename?
When we eventually move to newer versions of C++ we'll have a lot of NULLs to change, but lets stick with NULL for now.

"  /usr/local/nginx/sbin/nginx -t "  is succesful. Going to http://localhost/ gives "Welcome to nginx!" messgae.
But running ngx_pagespeed/test/run_tests.sh fails in the following way:
/cppfool/workcopy/ngx_pagespeed/test $ sudo ./run_tests.sh 80 8080 ../../../buildhelp/mod_pagespeed/ /usr/local/nginx/sbin/nginx
nginx: no process found
check mkdir /home/fooldo/cppfool/workcopy/ngx_pagespeed/test/tmp
check mkdir /home/fooldo/cppfool/workcopy/ngx_pagespeed/test/tmp/file-cache
check test -e /home/fooldo/cppfool/workcopy/ngx_pagespeed/test/pagespeed_test.conf.template
check_not grep @@ /home/fooldo/cppfool/workcopy/ngx_pagespeed/test/tmp/pagespeed_test.conf
FAIL
nginx: [emerg] unknown directive "set_random" in /home/fooldo/cppfool/workcopy/ngx_pagespeed/test/tmp/pagespeed_test.conf:172
With serf fetcher setup.
I don't know how directive "set_random" has been used here. This directive is not
in the list nginx directives here:
http://nginx.org/en/docs/dirindex.html
Any help? What has gone wrong?
In case following help.
/usr/local/nginx/sbin/nginx -V
nginx version: nginx/1.6.2
built by clang 3.5.0 (tags/RELEASE_350/final)
configure arguments: --with-cc=clang --with-ipv6 --add-module=/home/fooldo/cppfool/workcopy/ngx_pagespeed
Thanks.

If you look on our wiki/Testing page there are a few other modules that we depend on for running tests, and one of those defines set_random.  Could you try the steps there?

If we rename log as ps_log.
I fail to see reason for the following IPRO test FAIL.
TIMEOUT: wget -q   --save-headers -o /tmp/mod_pagespeed_test.root/fetched_directory/wget_output.txt                                                   -O /tmp/mod_pagespeed_test.root/fetched_directory/wget/fetch_until_output.27545 http://localhost:80/mod_pagespeed_test/ipro/test_image_dont_reuse.png output in /tmp/mod_pagespeed_test.root/fetched_directory/wget/fetch_until_output.27545
/home/fooldo/cppfool/buildhelp/mod_pagespeed//src/net/instaweb/system/../automatic/system_test_helpers.sh:476: fetch_until
/home/fooldo/cppfool/buildhelp/mod_pagespeed//src/net/instaweb/system/../automatic/system_test.sh:131: source
/home/fooldo/cppfool/buildhelp/mod_pagespeed//src/net/instaweb/system/system_test.sh:14: source
/home/fooldo/cppfool/workcopy/ngx_pagespeed/test/nginx_system_test.sh:289: main
failure at line 131
in 'In-place resource optimization'
FAIL.
With serf fetcher setup.


Add liveliness probe

Adding liveliness probe #56

PeriodSeconds: 15
FailureThreshold: 5
I decided for longer liveliness probes, so it would be the last resort if application is not responsive for longer(75s here).
Decision was mostly influenced by similar experiences to what is discussed here

@amila-ku Can you run make format.

@objectiser ran make format


SER and WRR return different values among pip and src versions

This is a really nice project! I noticed that WRR and SER return wrong values. I installed asr-evaluation.

asr-evaluation==2.0.2 (pip install)

I have a simple example for reproducing the problem. I also clned this repository, and tested it directly. The returned values looks correct.
Is my usage wrong?  And sorry for the delay.
In the original version of your post the first command was wer  hyp.txt ref.txt (the two files were swapped).  That would account for the difference in WER and WRR, since the denominator is the number of words in the reference file (which has 31 words, not 28).  The difference in SER might be because version 2.0.2 had a bug in computing the SER, which I think is fixed in 2.0.3 (the latest).  Do you want to try again with 2.0.3 and ensuring the files are in the correct order?

Thank you @belambert !
That is true, I wrongly pasted my command.
The correct order is reference, hypothesis, isn't it?
Now I found the both wer and source versions return the same values.
wer hyp.txt ref.txt
Sentence count: 13
WER:    14.286% (         4 /         28)
WRR:    96.429% (        27 /         28)
SER:   100.000% (        13 /         13)

wer ref.txt hyp.txt
Sentence count: 13
WER:    12.903% (         4 /         31)
WRR:    87.097% (        27 /         31)
SER:   100.000% (        13 /         13)

python asr-evaluation/asr_evaluation/__main__.py hyp.txt ref.txt
Sentence count: 13
WER:    14.286% (         4 /         28)
WRR:    96.429% (        27 /         28)
SER:    15.385% (         2 /         13)
python asr-evaluation/asr_evaluation/__main__.py ref.txt hyp.txt
Sentence count: 13
WER:    12.903% (         4 /         31)
WRR:    87.097% (        27 /         31)
SER:    15.385% (         2 /         13)

OK great!  Yes, the reference file has to be the first one.  If you have trouble remembering the order, I think wer --help will print out the options.


Bug fix: allow "_" to appear anywhere in a Prolog variable's name

I WAS NOT ABLE TO RUN THE TESTS AFTER I MODIFIED THEM. Running ERT either interactively or in batch mode failed at (require 'sweeprolog). Any guidance is appreciated!
Some regexes used to detect variable names only allow a single underscore at the beginning, so they incorrectly disallow names like "A_" and "A_b_".
Please make any edits for style and, if the tests are broken, correctness.

Hi @GeoffChurch, thanks for this!
I'm away until next week, so I'll get back to you then with comments if I'll have any :)

@eshelyaron thanks for the awesome package! It's a game-changer for me

Merged, with a few minor tweaks.
I'll do some more testing and release a new version with this fix, hopefully later this week.
Thanks again!
P.S. Regarding (require 'sweeprolog) failing when trying to run the tests, I suspect that this is because Sweep depends on Compat, so that needs to be available when requireing Sweep.

Adding Compat worked! For future reference, I used:
cd swipl-devel/packages/sweep
emacs --eval '(add-to-list (quote load-path) "~/.emacs.d/straight/build/compat")' --eval '(add-to-list (quote load-path) "~/src/swipl-devel/packages/sweep")' --eval '(require (quote compat))' -batch -l ert -l sweeprolog-tests.el -f ert-run-tests-batch-and-exit

BTW, in case this is surprising, two tests failed for me on a fresh pull from master:
Ran 126 tests, 124 results as expected, 2 unexpected (2024-09-02 09:51:36-0400, 6.664919 sec)

2 unexpected results:
   FAILED  sweeprolog-tests-cap-autoloaded-predicate
   FAILED  sweeprolog-tests-complete-predicate

The details are:
Test sweeprolog-tests-cap-autoloaded-predicate backtrace:
  ert-fail(((should (equal '("memberchk(Elem, List)") (all-completions
  (if (unwind-protect (setq value-1447 (apply fn-1445 args-1446)) (set
  (let (form-description-1449) (if (unwind-protect (setq value-1447 (a
  (let ((value-1447 'ert-form-evaluation-aborted-1448)) (let (form-des
  (let* ((fn-1445 #'equal) (args-1446 (condition-case err (let ((signa
  (let ((cap (sweeprolog-completion-at-point))) (let* ((fn-1435 #'=) (
  (progn (let ((cap (sweeprolog-completion-at-point))) (let* ((fn-1435
  (unwind-protect (progn (let ((cap (sweeprolog-completion-at-point)))
  (let ((temp (make-temp-file "sweeprolog-test" nil "pl" "%!  foobar(+
  (closure (t) nil (let ((temp (make-temp-file "sweeprolog-test" nil "
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name sweeprolog-tests-cap-autoloaded-predi
  ert-run-or-rerun-test(#s(ert--stats :selector t :tests ... :test-map
  ert-run-tests(t #f(compiled-function (event-type &rest event-args) #
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  command-line-1(("--eval" "(add-to-list (quote load-path) \"~/.emacs.
  command-line()
  normal-top-level()

Test sweeprolog-tests-cap-autoloaded-predicate condition:
    (ert-test-failed
     ((should
       (equal
        '("memberchk(Elem, List)")
        (all-completions "" ...)))
      :form
      (equal
       ("memberchk(Elem, List)")
       ("memberchk(_, _)"))
      :value nil :explanation
      (list-elt 0
                (arrays-of-different-length 21 15 "memberchk(Elem, List)" "memberchk(_, _)" first-mismatch-at 10))))

   FAILED   21/126  sweeprolog-tests-cap-autoloaded-predicate (0.011793 sec) at sweeprolog-tests.el:1
Test sweeprolog-tests-complete-predicate backtrace:
  ert-fail(((should (string= (buffer-string) "\nbaz(Baz) :- findall(X,
  (if (unwind-protect (setq value-1271 (apply fn-1269 args-1270)) (set
  (let (form-description-1273) (if (unwind-protect (setq value-1271 (a
  (let ((value-1271 'ert-form-evaluation-aborted-1272)) (let (form-des
  (let* ((fn-1269 #'string=) (args-1270 (condition-case err (let ((sig
  (progn (goto-char (point-max)) (backward-char) (call-interactively #
  (unwind-protect (progn (goto-char (point-max)) (backward-char) (call
  (let ((temp (make-temp-file "sweeprolog-test" nil "pl" "\nbaz(Baz) :
  (closure (t) nil (let ((temp (make-temp-file "sweeprolog-test" nil "
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name sweeprolog-tests-complete-predicate :
  ert-run-or-rerun-test(#s(ert--stats :selector t :tests ... :test-map
  ert-run-tests(t #f(compiled-function (event-type &rest event-args) #
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  command-line-1(("--eval" "(add-to-list (quote load-path) \"~/.emacs.
  command-line()
  normal-top-level()

Test sweeprolog-tests-complete-predicate condition:
    (ert-test-failed
     ((should
       (string=
        (buffer-string)
        "\nbaz(Baz) :- findall(X, b_getval(Name, Value)\n"))
      :form
      (string=
       #("\nbaz(Baz) :- findall(X, b_getval(_, _)\n" 0 33
         (font-lock-face ...)
         33 34
         (rear-nonsticky ... sweeprolog-hole t font-lock-face ...)
         34 36
         (font-lock-face ...)
         36 37
         (rear-nonsticky ... sweeprolog-hole t font-lock-face ...)
         37 38
         (font-lock-face ...)
         38 39
         (font-lock-face ...))
       "\nbaz(Baz) :- findall(X, b_getval(Name, Value)\n")
      :value nil :explanation
      (arrays-of-different-length 39 46
                                  #("\nbaz(Baz) :- findall(X, b_getval(_, _)\n" 0 33
                                    (font-lock-face ...)
                                    33 34
                                    (rear-nonsticky ... sweeprolog-hole t font-lock-face ...)
                                    34 36
                                    (font-lock-face ...)
                                    36 37
                                    (rear-nonsticky ... sweeprolog-hole t font-lock-face ...)
                                    37 38
                                    (font-lock-face ...)
                                    38 39
                                    (font-lock-face ...))
                                  "\nbaz(Baz) :- findall(X, b_getval(Name, Value)\n" first-mismatch-at 33)))

   FAILED   39/126  sweeprolog-tests-complete-predicate (0.040532 sec) at sweeprolog-tests.el:1

BTW, in case this is surprising, two tests failed for me on a fresh pull from master:

It's definitely unexpected, tests ought to pass!
Could you please share some more details about the setup where you get these failures?
Namely, have you also built SWI-Prolog from master (or just Sweep)?  And which Emacs version are you seeing this with?

I didn't build either of SWI or Sweep, I just pulled the repo and then ran the tests (with load-path pointing to the cloned Sweep, as shown above). So maybe the versions are just unexpected?
My SWI version is SWI-Prolog (threaded, 64 bits, version 9.2.6)
My Emacs version is GNU Emacs 29.4 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.42, cairo version 1.18.0) of 2024-07-16

I didn't build either of SWI or Sweep, I just pulled the repo and then ran the tests (with load-path pointing to the cloned Sweep, as shown above).

Got it.  Thanks, I'll see if I can reproduce this.


error when trying to use it with shopware 6.4.x

 [ERROR] The file "/var/www/html/custom/plugins/shopware-prod2testing-master/composer.json" is invalid. Errors:
         Plugin composer.json has invalid "type" (must be "shopware-platform-plugin"), or invalid
         "extra/shopware-plugin-class" value, or missing extra.label property

hm...i guess this is dead and not even compatiable with Shopware 6 xD
Nevermind then I guess.

You are right. This is a shopware 5 plugin, which I don't develop and more. Sorry for wasting your time. I will update the Readme next days to clarify this.


buildGoPackage: use installShellFiles, update completions/manpages

Motivation for this change
This reduces the usage of $bin in packages that use buildGopackage.
Should make #85535 a bit easier.
Also moved the "remove inactive maintainer" commit to this PR.
cc @kalbasit @Mic92
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

/cc @lethalman

Result of nixpkgs-review pr 86035 1

17 packages built:
- cockroachdb
- docker-machine
- gitAndTools.git-annex-remote-rclone
- gitAndTools.hub
- gopass
- kind
- kompose
- kops (kops_1_16)
- kops_1_12
- kops_1_13
- kops_1_14
- kops_1_15
- lxd
- prometheus-mail-exporter
- rclone
- stern
- vault


Dev

Add /remove command

Codecov Report

Merging #20 (2c3b98d) into main (b753714) will decrease coverage by 1.23%.
The diff coverage is 27.77%.

@@            Coverage Diff             @@
##             main      #20      +/-   ##
==========================================
- Coverage   75.00%   73.76%   -1.24%
==========================================
  Files          22       23       +1
  Lines         432      446      +14
==========================================
+ Hits          324      329       +5
- Misses        108      117       +9

Impacted Files
Coverage Δ

src/slash_commands/faculty/create.js
30.76% <ø> (+4.10%)
:arrow_up:

src/slash_commands/faculty/remove.js
27.77% <27.77%> (ø)

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 b753714...2c3b98d. Read the comment docs.


Don't output Jacobian if jacobianOutputStepSize==0

Add outputJacobian boolean, which is set to false when jacobianOutputStepSize is set to 0. This commit breaks travis/tests/short/photoRateCalcParameters.output, where lha and cosx are perturbed. I'm not yet sure why this is.
Closes #35

The perturbation of cosx and lha is now fixed, by reordering when the jacobian is output to a more sensible location. Also contains some comment fixes, and a tidy up of the test regime to fix the output of instantaneous rates.

Closes #109


Resolves the casting warning received in NSData+MPBase64.m

This was only an issue in Xcode 6. Using Xcode 7, the good practice is the opposite: removing the superfluous casting.


suggestion: removing disqus from X public pages with an option

@xavijam @saleiva
Hi guys,
Spoke to @iriberri  about this already. We had a query from a user.
Thanks for reaching out. I was concerned about one feature of CartoDB... Comments from random public maps appear at the bottom of my map screen and one of them uses profanity. I plan to use my maps for a professional purpose so this is highly inappropriate and this feature seriously deters me from using it. Is there anything I can do to remove those comments from my map link all together?
We do moderate comments but removing disqus from X sites with a layer could be a good idea
(for professional environments)
Thanks :)

Happy  to add a toggle on the enterpise admin
On May 21, 2015 11:54 AM, "yasharora73"<EMAIL_ADDRESS>wrote:

@xavijam https://github.com/xavijam @saleiva
https://github.com/saleiva
Hi guys,
Spoke to @iriberri https://github.com/iriberri about this already. We
had a query from a user.
Thanks for reaching out. I was concerned about one feature of CartoDB...
Comments from random public maps appear at the bottom of my map screen and
one of them uses profanity. I plan to use my maps for a professional
purpose so this is highly inappropriate and this feature seriously deters
me from using it. Is there anything I can do to remove those comments from
my map link all together?
We do moderate comments but removing disqus from X sites with a layer
could be a good idea
(for professional environments)
Thanks :)
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/cartodb/issues/3721.


"Peers" view shows next button even when user has <20 peers

Expected: "Peers" view should not show next button when there is no next page
Actual: "Peers" view shows next button even when user has <20 peers
Screenshots from my device:

I imagine something like #123 would fix it (not tested, I wasn't able to get the app to compile lol).
Looking at the code though, I think it would make sense to factor out the nextControl and previousControl into its own component. Then you can pass it props based on if it's enabled or not, and it might make the code easier to reason with. (And it can also be reused for other pages, Heros and Matches)

Tested the fix on iOS sim (wasn't compiling on Android for whatever reason), looks ok. There's probably a similar issue with <20 matches though.

@cannawen Merged. Do you want to create a new issue for the nextControl/previousControl refactoring? The same issue exist on Matches page as well.

I'll create some new issues.


Will these ever happen again?

We miss them. :)

Same here, but afaik the person who organized these left Microsoft and I guess no one took over from them.


Add Margin

CURRENT BEHAVIOUR: In the Covid page. There is very less gap between the "Choose a country" field and the icons below.
EXPECTED BEHAVIOUR: Increase the margin between them.

@Pritam0077 Go for it.
Refer to the steps given here in order to work on this issue 👇🏻
https://github.com/skpandey885/HealhUb/blob/main/Documentation/Getting started.pdf

I have solved it but some errors are coming while adding git push origin master

I have solved it but some errors are coming while adding git push origin master

Hey Buddy, This is not how things work 😊 In order to contribute to the issue, you need to comment on the issue and get yourself assigned by the mentor. Then you should follow some steps. Do not clone the repo directly. Please look into some other issues and then I will assign you.

Ok Sir, Actually I am new to this so don't know how it's works.

Ok Sir, Actually I am new to this so don't know how it's works.

Yeah. brother i got it. You can work on this issue.👇🏻 Go and comment here so that i can assign you.
https://github.com/skpandey885/HealhUb/issues/118


How to disable zipkin

I am not using zipkin and I wonder how I can disable it? I get a lot of exceptions looking like this:
ChannelStatsHandler caught an exception java.net.ConnectException: Connection refused: localhost/<IP_ADDRESS>:1463
If you give your finatra app -h I find this:
-com.twitter.finagle.zipkin.host='localhost:1463':
So I am sure it is zipkin causing this.
Thank you in advance

Hi @codeape, do you have an explicit dependency on finagle-zipkin in your build.sbt file? If not, do you know what's bringing it in transitively?

Hi @codeape . I've got same situation in the past.
At that time I put this flag "-com.twitter.finagle.zipkin.initialSampleRate=0" as workaround. Then that message had gone.
I know this is just workaround. But if okay, would you try this?

-com.twitter.finagle.zipkin.initialSampleRate=0

Doh. That sounds like a dependency bug in TwitterServer. I think it should only need a dependency on finagle-zipkin-core. Good find.

Setting the initialSampleRate flag seems like it might be the best option based on the version of Finatra that you are using in your sample. That seems to be from before a time when finagle-zipkin-core existed.

I upgraded to Finatra 2.6.0 removed -com.twitter.finagle.zipkin.initialSampleRate=0 and I do not see the problems any more (as suggested above by @ryanoneill).

Good to know. Thanks for the update @codeape