sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [dynamo] Save/restore system random state more carefully
Labels: triaged,oncall: pt2,module: dynamo

Internal example: [T207752792](https://www.internalfb.com/intern/tasks/?t=207752792)

There are some OSS unittests that are failing internally (e.g. `test/dynamo/test_unspec.py::UnspecTests::test_random_object`) likely because some internal logging code is burning some random numbers, leading to differing resulting random states from compiled vs. eager. In particular, if we skip `record_chromium_event_internal` and `log_chromium_event_internal` in `fb/_utils_internal.py`, then the test no longer fails internally.

Test case:
```python
    def test_random_in_dynamo(self):
        # test that system random calls still work even
        # if Dynamo calls random methods.
        def fn(x):
            # r1 = random.random()
            r1 = random.randint(1, 9)
            y = x + random.uniform(10, 20)
            r2 = random.randint(2, 18)
            return y + r1, r2

        orig_fn = torch._dynamo.eval_frame._maybe_set_eval_frame

        def bad(*args, **kwargs):
            # burn random call within dynamo
            random.random()
            return orig_fn(*args, **kwargs)

        x = torch.tensor([[1.0, 2.0], [3.0, 4.0]])
        random.seed(1)
        res1 = fn(x)
        opt_fn = torch.compile(fn, backend="eager", fullgraph=True)
        random.seed(1)
        with unittest.mock.patch("torch._dynamo.eval_frame._maybe_set_eval_frame", bad):
            res2 = opt_fn(x)
        self.assertTrue(same(res1, res2))
```

Dynamo should save/restore system `random` state more carefully in order to prevent non-user random calls made during tracing to affect the final random state.

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames
Repository: rust
Issue: Failed to capture backtrace when compiling with `--remap-path-prefix=${PWD}=`
Labels: T-compiler,C-bug,A-backtrace,A-path-remapping

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
fn main() {
    panic!("oh no!");
}
```

I expected to see this happen: `backtrace_rs::main` yields correct remapped source info.

```shell
$ RUST_BACKTRACE=1 cargo run
thread 'main' panicked at src/main.rs:2:5:
oh no!
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:662:5
   1: core::panicking::panic_fmt
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panicking.rs:74:14
   2: backtrace_rs::main
             at src/main.rs:2:5
   3: core::ops::function::FnOnce::call_once
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```

Instead, this happened: source info for 2-3 are missing.

```shell
$ RUSTFLAGS="--remap-path-prefix=$(pwd)=" RUST_BACKTRACE=1 cargo run
thread 'main' panicked at src/main.rs:2:5:
oh no!
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:662:5
   1: core::panicking::panic_fmt
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panicking.rs:74:14
   2: backtrace_rs::main
   3: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: aarch64-apple-darwin
release: 1.82.0
LLVM version: 19.1.1
```

also checked:

`rustc +nightly-aarch64-apple-darwin --version --verbose`:
```
rustc 1.86.0-nightly (f3d1d47fd 2025-01-20)
binary: rustc
commit-hash: f3d1d47fd84dfcf7f513be1dbad356e74c8f3b2b
commit-date: 2025-01-20
host: aarch64-apple-darwin
release: 1.86.0-nightly
LLVM version: 19.1.7
```

This is also reported to https://github.com/rust-lang/backtrace-rs/issues/691.
Repository: ui
Issue: MORE MAINTAINERS
Labels: area: request

### Feature description

I am bringing this issue again, there needs to be more maintainers. I love shadcn just as much as the next guy, but there are so many bugs. There are over 835 pull requests. There are a lot of bugs. I request that there be more maintainers, I am also willing to maintain myself.

### Affected component/components

_No response_

### Additional Context

Additional details here...

### Before submitting

- [x] I've made research efforts and searched the documentation
- [x] I've searched for existing issues and PRs
Repository: pytorch
Issue: DISABLED test_warn_on_invalid_torch_function_standalone_class (__main__.TestTorchFunctionWarning)
Labels: triaged,module: flaky-tests,skipped,module: __torch_function__

Platforms: asan, linux, mac, macos, rocm, win, windows, slow



This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_warn_on_invalid_torch_function_standalone_class&suite=TestTorchFunctionWarning&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/35951159764).

Over the past 3 hours, it has been determined flaky in 111 workflow(s) with 222 failures and 111 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_warn_on_invalid_torch_function_standalone_class`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_overrides.py`

cc @clee2000 @wdvr @hameerabbasi @rgommers @ezyang
Repository: pytorch
Issue: DISABLED test_cache_hot_load_device_cuda_bfloat16_dynamic_False (__main__.AOTAutogradCacheTests)
Labels: module: rocm,triaged,module: flaky-tests,skipped,oncall: pt2,module: dynamo

Platforms: rocm

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_cache_hot_load_device_cuda_bfloat16_dynamic_False&suite=AOTAutogradCacheTests&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/35949205522).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 3 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_cache_hot_load_device_cuda_bfloat16_dynamic_False`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/pytorch/test/dynamo/test_aot_autograd_cache.py", line 119, in test_cache_hot_load
    self.assertEqual(len(cache_info.autotune_artifacts), autotune_expect)
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/torch/testing/_internal/common_utils.py", line 4028, in assertEqual
    raise error_metas.pop()[0].to_error(  # type: ignore[index]
AssertionError: Scalars are not equal!

Expected 2 but got 4.
Absolute difference: 2
Relative difference: 1.0

To execute this test, run the following from the base repo dir:
    PYTORCH_TEST_WITH_ROCM=1 python test/dynamo/test_aot_autograd_cache.py AOTAutogradCacheTests.test_cache_hot_load_device_cuda_bfloat16_dynamic_False

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `dynamo/test_aot_autograd_cache.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd @clee2000 @wdvr @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @chauhang @amjames
Repository: pytorch
Issue: DISABLED test_mm_plus_mm (__main__.TestPatternMatcher)
Labels: module: rocm,triaged,module: flaky-tests,skipped,oncall: pt2,module: inductor

Platforms: rocm

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_mm_plus_mm&suite=TestPatternMatcher&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/35949080113).

Over the past 3 hours, it has been determined flaky in 4 workflow(s) with 6 failures and 4 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_mm_plus_mm`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/pytorch/test/inductor/test_pattern_matcher.py", line 113, in test_mm_plus_mm
    self.common(fn, args, 1, 3)
  File "/var/lib/jenkins/pytorch/test/inductor/test_pattern_matcher.py", line 85, in common
    self.assertEqual(
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/torch/testing/_internal/common_utils.py", line 4028, in assertEqual
    raise error_metas.pop()[0].to_error(  # type: ignore[index]
AssertionError: Scalars are not equal!

Expected 1 but got 2.
Absolute difference: 1
Relative difference: 1.0

To execute this test, run the following from the base repo dir:
    PYTORCH_TEST_WITH_ROCM=1 python test/inductor/test_pattern_matcher.py TestPatternMatcher.test_mm_plus_mm

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `inductor/test_pattern_matcher.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd @clee2000 @wdvr @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @chauhang @aakhundov
Repository: pytorch
Issue: DISABLED test_cache_load_function_device_cuda_float32_dynamic_False_bundle_triton_True_grad_True (__main__.TestFxGraphCache)
Labels: module: rocm,triaged,module: flaky-tests,skipped,oncall: pt2,module: inductor

Platforms: rocm

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_cache_load_function_device_cuda_float32_dynamic_False_bundle_triton_True_grad_True&suite=TestFxGraphCache&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/35950279286).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 6 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_cache_load_function_device_cuda_float32_dynamic_False_bundle_triton_True_grad_True`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/pytorch/test/inductor/test_codecache.py", line 146, in test_cache_load_function
    self.assertEqual(
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/torch/testing/_internal/common_utils.py", line 4028, in assertEqual
    raise error_metas.pop()[0].to_error(  # type: ignore[index]
AssertionError: Scalars are not equal!

Expected 14 but got 35.
Absolute difference: 21
Relative difference: 1.5

To execute this test, run the following from the base repo dir:
    PYTORCH_TEST_WITH_ROCM=1 python test/inductor/test_codecache.py TestFxGraphCache.test_cache_load_function_device_cuda_float32_dynamic_False_bundle_triton_True_grad_True

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `inductor/test_codecache.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd @clee2000 @wdvr @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @chauhang @aakhundov
Repository: ant-design
Issue: Option to Always Show removeIcon in Upload Component
Labels: unconfirmed

### What problem does this feature solve?

`removeIcon` in the `Upload` component is visible only on hover. However, on mobile devices where hover is not available, it becomes difficult for users to remove uploaded files.

It would be great if there was an option to make the removeIcon always visible, regardless of the hover state. This would improve the usability of the component on mobile devices.

### What does the proposed API look like?

Introduce a property, such as `alwaysShowRemoveIcon`, which can be set to true to make the removeIcon persistently visible.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: ollama
Issue: how to get English output
Labels: bug

### What is the issue?

M:\AI\ollama>ollama run deepseek-r1:7b
>>> list philosophers
<think>

</think>

Here is a list of some of the most influential and notable philosophers throughout history, organized by era and
region:

### Ancient Philosophy (c. 600–321 BCE)
- **Thales of Miletus** (c. 624–548 BCE):被认为是第一个哲学家，提出“万物源于水”的学说。
- **Anaximander of Miletus** (c. 570–495 BCE): 提出“无限”概念，并认为万物起源于自然。
- **Anaximenes of Mileti** (c. 510–441 BCE): 认为万物来源于某种原始物质，如“air”（空气）。

### OS

Microsoft Windows [Version 10.0.22635.4800]

### GPU

NVIDIA GeForce GTX 1660 SUPER

### CPU

Processor	AMD Ryzen 7 3700X 8-Core Processor, 3600 Mhz, 8 Core(s), 16 Logical Processor(s)


### Ollama version

ollama version is 0.5.7
Repository: next.js
Issue: NextResponse.redirect() behaves incorrectly when redirecting from subdomain route to apex domain route
Labels: Middleware

### Link to the code that reproduces this issue

https://github.com/bentron2000/next-response-bug-report

### To Reproduce

Set `/etc/hosts`:

```
127.0.0.1 example.test
127.0.0.1 foo.example.test
```

Install Packages:

```
npm i
```

Start Server:

```
npm run dev
```

Then Navigate to the following link and observe the result.
'http://foo.example.test:3000/shouldredirect'

### Current vs. Expected behavior

When you navigate to the 'http://foo.example.test:3000/shouldredirect'
Middleware should select for this route and redirect to the apex domain '/login' page

**Expected Result:**
Redirect to : 'http://example.test:3000/login' -> 'Hooray - we redirected properly'

**Actual Result:**
Redirect to : 'http://foo.example.test:3000/login' -> 'Should not be redirected here'


### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.2.0: Fri Dec  6 18:51:28 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T8112
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.10.0
  npm: 10.8.1
  Yarn: 1.22.22
  pnpm: 9.15.0
Relevant Packages:
  next: 15.2.0-canary.19 // Latest available version is detected (15.2.0-canary.19).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A
```

### Which area(s) are affected? (Select all that apply)

Middleware

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

# Minimal demo of possible middleware `NextResponse.redirect()` Bug

Demonstrates that NextResponse.redirect is not obeying explicit urls when redirecting from a subdomain `foo.example.test` to the apex domain `example.test`

In this example, middleware has been set to catch a specific subdomain route and to redirect it to an explicitly set route on the apex domain
'http://foo.example.test:3000/shouldredirect' -> 'http://example.test:3000/login'

This does not happen - it redirects to the same path but on the subdomain.

## To Reproduce

Set `/etc/hosts`:

```
127.0.0.1 example.test
127.0.0.1 foo.example.test
```

Install Packages:

```
npm i
```

Start Server:

```
npm run dev
```

Then Navigate to the following link and observe the result.
'http://foo.example.test:3000/shouldredirect'

Middleware should select for this route and redirect to the apex domain '/login' page

**Expected Result:**
Redirect to : 'http://example.test:3000/login' -> 'Hooray - we redirected properly'

**Actual Result:**
Redirect to : 'http://foo.example.test:3000/login' -> 'Should not be redirected here'
Repository: transformers
Issue: ImportError: cannot import name 'NoneType' from 'types' on main in Python 3.9
Labels: bug

### System Info

Linux

### Who can help?

_No response_

### Information

- [ ] The official example scripts
- [x] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

```
docker run python:3.9 bash -c 'pip install git+https://github.com/huggingface/transformers && python -c "import transformers"'
```

Output:

```
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/transformers/__init__.py", line 26, in <module>
    from . import dependency_versions_check
  File "/usr/local/lib/python3.9/site-packages/transformers/dependency_versions_check.py", line 16, in <module>
    from .utils.versions import require_version, require_version_core
  File "/usr/local/lib/python3.9/site-packages/transformers/utils/__init__.py", line 27, in <module>
    from .chat_template_utils import DocstringParsingException, TypeHintParsingException, get_json_schema
  File "/usr/local/lib/python3.9/site-packages/transformers/utils/chat_template_utils.py", line 22, in <module>
    from types import NoneType
ImportError: cannot import name 'NoneType' from 'types' (/usr/local/lib/python3.9/types.py)
```

### Expected behavior

No import error
Repository: ollama
Issue: Log tracking
Labels: feature request

I have an idea, can I add a traceId when printing the log? This will facilitate the tracking details of subsequent requests.
Repository: PowerToys
Issue: [Quick Accent] Change the font of the interface
Labels: Needs-Triage

### Description of the new feature / enhancement

Add a selection box in the settings menu, which changes the font displaying the Quick Accent interface.

(My English is not very good, please forgive me)

### Scenario when this would be used?

1. Some fonts cannot display all the characters, such as Simplified Chinese font "Microsoft Yahei".Unluckily, some operating systems cannot change the default font (for example, "中国定制版" Windows).
2. Some people have the need to change the font, in order to beautify the computer.
3. Some fonts can distinguish the similar characters. I think they are more proper.

### Supporting information

_No response_
Repository: ollama
Issue: don't show the thinking process
Labels: feature request

When I use DeepSeek-R1, the thinking process shown does not make sense to me, I only want to see the final result.

![Image](https://github.com/user-attachments/assets/d56c95ba-1fbc-4a4a-83e0-4ae1d7899325)
Repository: pytorch
Issue: DISABLED test_cat (__main__.NumBytesMetricTests)
Labels: module: rocm,triaged,module: flaky-tests,skipped,oncall: pt2,module: inductor

Platforms: rocm

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_cat&suite=NumBytesMetricTests&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/35951074517).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 3 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_cat`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/pytorch/test/inductor/test_perf.py", line 207, in test_cat
    self.assertExpectedInline(count_numel(f, *inp), """400""")
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/torch/testing/_internal/common_utils.py", line 3066, in assertExpectedInline
    return super().assertExpectedInline(actual if isinstance(actual, str) else str(actual), expect, skip + 1)
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/expecttest/__init__.py", line 413, in assertExpectedInline
    assert_expected_inline(
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/expecttest/__init__.py", line 378, in assert_expected_inline
    assert_eq(expect, actual, msg=help_text)
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/expecttest/__init__.py", line 450, in assertMultiLineEqualMaybeCppStack
    self.assertMultiLineEqual(expect, actual, *args, **kwargs)
  File "/opt/conda/envs/py_3.10/lib/python3.10/unittest/case.py", line 1226, in assertMultiLineEqual
    self.fail(self._formatMessage(msg, standardMsg))
  File "/opt/conda/envs/py_3.10/lib/python3.10/unittest/case.py", line 675, in fail
    raise self.failureException(msg)
AssertionError: '400' != '1264'
- 400
+ 1264
 : To accept the new output, re-run test with envvar EXPECTTEST_ACCEPT=1 (we recommend staging/committing your changes before doing this)

To execute this test, run the following from the base repo dir:
    PYTORCH_TEST_WITH_ROCM=1 python test/inductor/test_perf.py NumBytesMetricTests.test_cat

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `inductor/test_perf.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd @clee2000 @wdvr @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @chauhang @aakhundov