text:
Approach for extension test

The idea behind the refactoring #323 was to separate internal tests from extension tests. We have at the moment not so many tests. This makes it easy to refactor. Sorry that I did not wrote my idea done for discussion and started immediatly.
Test definitions
The internal tests are tests which use only parts of the extension (like only the kitmanager or the kit scan part). This test are only unit tests for components. This componets may can interact with filesystem, cmake, or other parts.
The extension test are tests in the user view. I would like to use them to check if the complete extension is working correct. All components work correct together. The first one which I have written are more trivial ones no-kits-present.test.ts.
Extension test
My focus is at the moment on the extension tests. I hope we get soon the open pull requests merged.
Test management
I like the approach with CTest in the smoke branch to manage the different test environments.
The batch files make it hard to see which test environment failed.
Test framework technologies
I would avoid to use a new test description language (the yaml-files). The idea of my refactoring was needed to make it possible for testing #290. In this case I need to stub some vscode function.
Its is very easy with the typescript test frameworks (mocha, chi and sinon).
You can see it in the  Kits test ->GUI tests
Structure of tests
The structure in the smoke branch follows the same idea like my refactored extenstion_tests subfolders.
The folder is always structured in:

extension_tests

<name_group_of_tests>

project_folder
test

The project_folder contains a valid or broken CMake project with source files.
The test folder contains the related tests.
Test result verification
I like to use the extension like the users. In this case I need run function of the extension by the test script. The test expectation can be checked against

a executeable which provides a output
cmake generated cache files or message
outputs provided by the extension itself (vscode messages/warning)

I hop you like the plan und hop to get some feedback.
@Randshot I would like to test, the commands you added first by an extension test. The tests on CMakeDriver level would mean we need to write the test twice, because CMake 3.5 and CMake 3.7 work different in the extension.

@KoeMai What do you mean by commands? Which PRs of mine are you talking about?

Sorry, I was wrong you have added settings. The settings are used by the commands. The testing of the settings should work as well.

I pushed my first draft for configure and build test to  feature/add_build_tests (only the build test is active).

The reason I went with the yaml files was to abstract away a lot of the boilerplate with writing the test setup/teardown, making it trivial to add more tests.
@Randshot, what do you think?

TBH, I don't have any idea what yaml files you are talking about :/
My priorities for testing would be easy integration and (modular) extensibility.

We're referring to the test stuff I threw together on the feature/smoke branch.

I will look at it a bit closer after dinner.

@KoeMai What is you reasoning for not using yaml files?
I like the idea of reducing boilerplate as much as possible.

I would like to reduce the complexity of the tests too. In the same way I do not want to loose the flexibility of a testing framework.
I try to find test method's for

manipulate environment variables
forward environment variable to cmake
settings from settings.json
catch error notification like in the ninja bug.
I do not know how I can check them without individual test helpers.

Both ways have their benefits. I like the test scenario views of yaml but I see the same possibilies in a test framework. In both ways I can write helpers. In the one way I have to write them to have access in the scenario and in the other one only if I see the reuseability or to make it more readable.

I guess it's a matter of just eliminating duplication. I chose YAML so that the only thing in those test directories were the steps to run the test (no setup/teardown). I abstracted the setup/teardown into a test runner class you can see in the smoke directory.
Have you looked at writing a test runner class? You might get away with putting all the setup/teardown logic and your helper methods in the single class and keep the individual test directories down in size to just concerning themselves with running the exact test for their own directory.

@KoeMai I have taken a look at your add_build_tests branch and you left a comment asking how to get the path to the executable or the output of the executable.
I don't know the best approach for this, but one that came to my mind is by using custom targets to run the executable. The executable itself would have to write it's output to some file, or we somehow catch the output when CMake runs the custom target.

@KoeMai I have a working CMakeLists.txt file here:
cmake_minimum_required(VERSION 3.0.0)
project(TestBuildProcess VERSION 0.1.0)

add_executable(TestBuildProcess main.cpp)

add_custom_command(
    TARGET TestBuildProcess
    POST_BUILD
    COMMAND $<TARGET_FILE:TestBuildProcess> > output.txt
    WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
    COMMENT "Running in ${CMAKE_CURRENT_BINARY_DIR}"
)

add_definitions(-D_CMAKE_VERSION="${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}")

The output.txt file will be in the build directory.

@vector-of-bool @KoeMai I have a working example for getting the output of a built project executable.
You can find it in the feature/get_output_example branch.

Yes I saw it. What do you think about one of this approachs?

https://www.npmjs.com/package/mocha-shared
https://www.npmjs.com/package/mocha-bdd-extend
Both combines our ideas and keep the tests lean and flexible.

I did some refactoring without the packages from above.
@Randshot I merged your branch into feature/add_build_tests

@KoeMai If I remember right, I pushed some changes to my branch that fixes the appveyor problems.
I didn't manage to fix the travis problems though.

@KoeMai, mocha-shared and mocha-bdd-extend look like what I was hoping for. Nice.
Also, it looks like you're having trouble with driver startup on your branch. My tslint branch did some cleanup of driver startup that might affect what you are doing. The driver startup needs a bit of refinement, as it's very easy to accidentally have driver startup depend on itself.

@KoeMai It seems like appveyor doesn't select a kit and travis just skips both tests.

@KoeMai I think I have fixed the issues with appveyor.
You can find the fix in the appveyor_init_debug branch.
The only problem is, that the test checks for CMake version 3.9, which doesn't always fit the CMake version appveyor uses.

doesn't always

Meaning the CMake version differs between AppVeyor machines? :fearful:
Kit scanning for VS prior to 2017 seems a bit more flakey than I'd like.

Oh you are right, thanks for your help.
At the moment I see this tests as a draft. So it works only on a subset for cmake and compilers + build system.
@vector-of-bool did you took a look at the tests? At the moment I use non of the tool packages,  but I think the style is very clear. Should we try to convert it more in to shared blocks?

I've looked it over a bit. It looks alright, and will be better once we get some of the boilerplate down.
I'd like to say that cmake.stop should not stop the driver process, as I feel it will be a nightmare to debug in the future. I'd go the route of having CTest just start a new VSCode instance for each of the main tests, just to be sure we have a completely clean state, which just stopping the driver won't actually achieve.

Now I have a working draft and travis and appveyor (most parts) are happy.
Next steps:

[ ] Task 1: Extract helper classes from test file into separate helper files.
[ ] Task 2: Make all test available for Linux/MacOs and Windows (see Q1, Q2)
[ ] Task 3: Repair and make pending events available on all plattforms.

For the next steps we need to define some environment settings for travis and appveyor

[ ] Q1. What are our default compilers? CLang? Linux and MacOS.
[ ] Q2. What is our default build system? Linux MacOS and Windows (The older VS versions fail because no build system is prevered)
Q3. Do we want to use this code base or do we want to refactor it to a other style or do we want to use the smoke branch?

I would create a pull request out of the feature/add_build_tests branch if task 1 is finished.

For Q1, I'd like to expand the test matrix as wide as possible. That means running Travis tests against both GCC and Clang for both Linux and macOS. May even multiple versions of each compiler.
For Q2, I'm not sure what you mean? You mean the CMake Generator? Again, I'd like to have a matrix for each backend that the extension supports.
For Q3, I don't feel strongly that my feature/smoke branch be used. If we can get what we need from Mocha, I'll be happy to use that. I'd like to start off a fresh new VSCode instance for each of the big smoke tests, though, just to make sure everything is clean when we start. I was using CTest for this, but it can be anything that can just launch a bunch of processes.
@ytimenkov was doing work in his own fork to make the backend system much more modular and testable. It may be worth looking to adopting aspects of his approach in the future.

I've updated #190 with what I was thinking about and what I've managed to do.
If you like the idea I think it should be possible to drag in my changes firstly putting them under existing functionality (e.g. implement CMakeServerClientDriver in terms of new components), and then gradually remove these wrappers.

Another thought about build matrix and a set of compilers:
After VS code implemented support for task discovery I thought that it might be good if this mechanism was (re)used for building with CMake.
Cons:

No ability to show progress bar during the build, but user will see nice colored output in the terminal.
Hooks? But their absence can be mitigated by watching files for changes.

Pros:

Ability to control and customize build process, including error parsers.
Specify as pre-launch task in debugger.
Similar template can be replicated for multiple tasks and/or more complex scenarios.

This way most interesting cases are:

Makefiles/Ninja on Linux mac with gcc/clang.
Multi-configuration generators like Visual Studio.
Weird generator+compiler combination like ninja + Visual Studio.

What I think is of interest is different versions of CMake itself and VSCode. Something like < 3.7.2, latest released, latest nightly + similar for Code - latest released, latest insiders. However I'm not sure if backward compatibility is needed for VS Code (e.g. pre-multiroot).

I would like to build different levels of testing. At the moment I focus on the testing of the possible user interaction. I think on this level of tests we do not need to test many compilers and cmake versions, the should only check essential cases or issues from the users. The other test I would do it like @ytimenkov  says, more inside the extension by unit testing and integration test. The help us more on development.

I'm open to getting a good baseline as the first step. We can expand the test matrix at a later time.
@ytimenkov, I've looked into using the task-runner as a way to execute the CMake builds, with mixed findings. Last time I looked, it didn't support what I was hoping for. It may be better now (I looked several months ago).
I'd like to switch to the task-runner if possible, if only for using the integrated terminal for nicer output. Here's a wild possibility:

Wrap the CMake build with a script that communicates back to the extension? I'm hesitant to use regex to do error matching since each compiler does something wildly different and sometimes errors are split over multiple lines.

Weird generator+compiler combination like ninja + Visual Studio.

Actually, the reason I've struggled with Visual Studio generators is that I exclusively use the Ninja generator with MSVC :D
As for bringing in your changes: I'd like to phase out the current backend/two-phase init process. I just want to get our testing in order. If it would be simpler to pull in your changes while we add the tests, I'm good with that.

Ok, out of the discussion, I think we should create a new dashboard project with cards for the tasks of this issue (testing issues). This allows that different person could work on it.
I most tests could be done by mocha based test inside of one vscode instance. By reloading the cmaketools class. With this approach we could test the different cmake versions and compiler version. This approach does not support to test the binding of commands, because there is a reload of the extension needed.
For vscode version tests we need for each version a new test runner. For setting them up we could the smoke branch ctest part or by extension of the run_extensions_test.bat. But I see this more on the long term.

[ ] In add_build_test branch I would add additional an example how change settings inside a test. I think it will the cmake install path switch.

I think the main part of this issue is done, could we close it?

I say yes

authors: KoeMai Randshot vector-of-bool ytimenkov

repo: vector-of-bool/vscode-cmake-tools


text:
copy-webpack-plugin error when update to 6.02 version

The error occurs after updating the plugin from version 5.1.1 to the latest version 6.0.2:

It looks like this code:
   new CopyWebpackPlugin([       { from:${PATHS.src}/${PATHS.assets}img, to: ${PATHS.assets}img},       { from:${PATHS.src}/${PATHS.assets}fonts, to: ${PATHS.assets}fonts},       { from:${PATHS.src}/static, to: '' },     ]),
needs to be replaced with the following:
   new CopyWebpackPlugin({       patterns: [         { from:${PATHS.src}/${PATHS.assets}img, to: ${PATHS.assets}img},         { from:${PATHS.src}/${PATHS.assets}fonts, to: ${PATHS.assets}fonts},         { from:${PATHS.src}/static, to: '' },       ],     }),
It worked for me, but you check.

Fixed commit
Stable version: 2.0.0

source: gharchive/issue

authors: Alecto vedees

repo: vedees/webpack-template

license: MIT

license_type: permissive

license_source: github-api


text:
Zq/markicons

Added icons to marktype select using Drop.js.

HTML <select> doesn't support icons in its options so I used <div> tag with ng-repeat to render the marktype options.
Initially the ng-repeat options were not showing up in the pop up menu. I wrapped new Drop() inside $timeout to fix this problem. See this question for details.
These are the icons used:
point

tick
 I'm not sure what's the difference between tick and point. Is tick "-" a shaped point?
bar

line

area

text

Icons for point and tick are custom-made because I couldn't find suitable ones on fontawesome. I put the icon files under "assets/fonts/"

there are some conflict .. so we can't merge.

@kanitw @domoritz
The merge conflicts are in shelves.html and shelves.js, basically the marktype-related lines that I changed. This is because I didn't checkout my zq/markicons branch from the head of the master branch, which I should. However I cannot run the latest version of Pole* on the master branch -- the data and the shelves are not showing up (please see screenshot below):

In my Mac terminal, I see a lot of test cases failed after npm start (please see the log file below):
log.txt
And some errors in my Chrome console:

Could you help me figure out why this is happening? After that I can branch from the head of master, make the icon changes and send a new pull request. Thanks!

FYI, this Pr might still be useful, but we have to re-do it for vega-lite-ui instead.

source: gharchive/pull-request

authors: ZeningQu kanitw

repo: vega/polestar

license_source: bigquery


text:
Create a GitHub issue from the selection

You seem to have everything that is needed in place to add a small but very interesting Feature : from the link created, create an issue in GitHub and dump the link in the description. The title/summary could come from a dialog box.

Hi,
Thanks for suggesting this. I like this idea. I'd need to explore a bit more the feasibility though. I will try to take a look at it in the next few days.
Thanks!

Cool! Let me know if it's possible.

Have you had time to look into it?

authors: ebfortin veler

repo: veler/CopyGitLink


text:
ImportError: dlopen: cannot load any more object with static TLS

Hi:
I just installed velocyto.py and received this error after typing velocyto --help:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/hwfssz4/BC_PUB/Software/07.User-defined/04.Medical/shengyifei/cpdb-venv/lib/python3.6/site-packages/velocyto/__init__.py", line 13, in <module>
    from .estimation import fit_slope, _fit1_slope, clusters_stats
  File "/hwfssz4/BC_PUB/Software/07.User-defined/04.Medical/shengyifei/cpdb-venv/lib/python3.6/site-packages/velocyto/estimation.py", line 7, in <module>
    from .speedboosted import _colDeltaCor, _colDeltaCorLog10, _colDeltaCorSqrt
ImportError: dlopen: cannot load any more object with static TLS

How to fix this error?
Thank you in advance.

I have also encountered this problem. Is there any corresponding solution？

I have the same problem.Hope there is a solution.

Hi! I find a way to solve this problem. It sames like a bug in lower version of glibc; For more information you can see: https://lover.blog.csdn.net/article/details/117623889.
For me, I vim the script init.py, let the code "from .estimation import fit_slope, _fit1_slope, clusters_stats" at line2.
The modified init.py like this:
from .constants import *
from .estimation import fit_slope, _fit1_slope, clusters_stats
from .gene_info import GeneInfo
from .read import Read
from .feature import Feature
from .transcript_model import TranscriptModel
from .segment_match import SegmentMatch
from .indexes import FeatureIndex, TransciptsIndex
from .molitem import Molitem
from .logic import *
from .counter import ExInCounter
from .metadata import MetadataCollection, Metadata
from .neighbors import BalancedKNN, convolve_by_sparse_weights
from .serialization import dump_hdf5, load_hdf5
from .analysis import VelocytoLoom, scatter_viz, ixs_thatsort_a2b, load_velocyto_hdf5
from ._version import __version__

您好，我已收到您的邮件，我会尽快回复。祝生活愉快。

Is there any other way to solve this problem?
I installed the glibc-2.26 on my path, then:
export LD_LIBRARY_PATH=/my_path/glibc-2.26/build/lib:$LD_LIBRARY_PATH
velocyto --help #error info: Segmentation fault (core dumped)

您好，我已收到您的邮件，我会尽快回复。祝生活愉快。


text:
Using in Gatsby with IE11

Hey! Just wondered what the support out the box for this library is? I'm having some issues on IE11 where the entire site isn't rendering with the following console error
Unexpected call to method or property access
It doesn't give me much more to go off other than mentioning Symbol a few times, and the error disappears if i remove flubber.
Any help would be hugely appreciated.
Thanks!

Without more details it's hard to say for sure whether this is Gatsby or something else. If you visit:
https://veltman.github.io/flubber/demos/basic-svg.html
in the same browser, do you see the same error? If so, can you paste the whole thing here?

authors: samuelgoddard veltman

repo: veltman/flubber

license: mit


text:
Vorkasse Icon

Hi könntet Ihr ggf noch ein Vorkasse Icon hinzufügen?
Can you add a Vorkasse Icon (payment in advance)

Hallo, Vorkasse ist in Arbeit ;)

Ich ändere die Labels zu reviewing, weil ich für solche Übersetzungen eine andere ab Version v2 andenke.

repo: vendocrat/PaymentFont


text:
[Test] Investigate navigation timeout for networkidle0

Follow the suggestion from https://github.com/puppeteer/puppeteer/issues/1908#issuecomment-380308269
and add the following tracking code
class InflightRequests {
  constructor(page) {
    this._page = page;
    this._requests = new Set();
    this._onStarted = this._onStarted.bind(this);
    this._onFinished = this._onFinished.bind(this);
    this._page.on('request', this._onStarted);
    this._page.on('requestfinished', this._onFinished);
    this._page.on('requestfailed', this._onFinished);
  }

  _onStarted(request) { this._requests.add(request); }
  _onFinished(request) { this._requests.delete(request); }

  inflightRequests() { return Array.from(this._requests); }

  dispose() {
    this._page.removeListener('request', this._onStarted);
    this._page.removeListener('requestfinished', this._onFinished);
    this._page.removeListener('requestfailed', this._onFinished);
  }
}

received the following reports:
  console.error src/tests/e2e/emailTransferForm.test.e2e.js:119
    Navigation failed: Navigation timeout of 30000 ms exceeded

  console.error src/tests/e2e/emailTransferForm.test.e2e.js:121
      http://172.17.0.3:3000/sockjs-node/092/h5meigsq/xhr_streaming?t=1586976964888

  console.error src/tests/e2e/emailTransferForm.test.e2e.js:119
    Navigation failed: Navigation timeout of 30000 ms exceeded

  console.error src/tests/e2e/emailTransferForm.test.e2e.js:121
      https://api-iam.intercom.io/messenger/web/metrics
      http://172.17.0.3:3000/sockjs-node/820/gm0xzxqp/eventsource

  console.error src/tests/e2e/emailTransferForm.test.e2e.js:119
    Navigation failed: Navigation timeout of 30000 ms exceeded

  console.error src/tests/e2e/emailTransferForm.test.e2e.js:121
      http://172.17.0.3:3000/sockjs-node/779/gqa4csjh/eventsource

seems to be caused by react websocket?

may be related to react hot loading module
https://github.com/facebook/create-react-app/blob/ebebe80383eb15b4759a0cd5ea12015eaac94c0e/packages/react-scripts/config/webpack.config.dev.js#L58

First build then serve -s build disabled hot loading

repo: ventureum/Chainsfr


text:
The cause of runtime traps should be masked in debug mode

Describe the bug
We should check that Veracruz is correctly masking the cause of a runtime trap when raised in debug mode.  Runtime traps are akin to kernel panics and can be caused by a number of reasons, which Veracruz reports for debugging purposes.  However, this reporting can act as a covert channel from the program to the untrusted host of the computation.  As a result, we should either:

Ensure that the causes of runtime traps are completely masked to the untrusted host when the runtime is launched with debug=false (note, this is the expected behaviour at the moment, though we should audit to ensure that this is happening),
Continue reporting the cause of runtime traps, but only provide them to the principals with the ResultReceiver role.

I've realized the ResultReceiver may not be acceptable, since it may be possible for the runtime traps to leak confidential user data in the computation.

authors: dominic-mulligan-arm geky

repo: veracruz-project/veracruz


text:
document the cocli template format

There has to be clear documentation around the template format used by:

CoRIM
Meta
CoMID
(Co)SWID

hey @thomas-fossati
I wanted to check if this issue is still open and if any progress has been made. If the issue is unresolved, I would like to contribute to addressing it. Please let me know if I can start working on this and if there are any specific guidelines or priorities to consider.

@ravjot07 your contributions are welcome and greatly appreciated. This is not actively worked on.

Moved to cocli repo's issues https://github.com/veraison/cocli/issues/18

authors: deeglaze ravjot07 thomas-fossati

repo: veraison/corim


text:
Docs: bun package manager

What is the improvement or update you wish to see?
I would like to see bun in the installation documentation.
Also, I would like it if there were references to Bun because if I hadn't seen a Twitter tweet about Bun support, I would not know if it was compatible.
Is there any context that might help us understand?
.
Does the docs page already exist? Please link to it.
No response

Bun's current workspace support is somewhat buggy, and we're reflecting that in our Support Policy as Beta support. Notably, the Bun team is focusing some effort there to get that support improved.
It's more likely that we would be able to add Bun to the docs code block tabs once Bun's Workspace support work is completed.

Bun's current workspace support is somewhat buggy, and we're reflecting that in our Support Policy as Beta support. Notably, the Bun team is focusing some effort there to get that support improved.
It's more likely that we would be able to add Bun to the docs code block tabs once Bun's Workspace support work is completed.

While I understand this it makes the fact that turbo supports bun basically useless, since there is no documentation on how to set it up.

What setup instructions are you looking for? The interactions between Bun compared to the other package managers should be generally the same.
You'll need to head into the Bun documentation to sort out a few of the flag combinations to re-create the ones that you see for the other package managers. Other than that, I'm not sure what would be different.

What setup instructions are you looking for? The interactions between Bun compared to the other package managers should be generally the same.
You'll need to head into the Bun documentation to sort out a few of the flag combinations to re-create the ones that you see for the other package managers. Other than that, I'm not sure what would be different.

It actually seems to work by just replacing the package manager I use in my scripts, which I was not expecting. I did want to ask however: What is the recommended approach for watch? Do I use Bun's watch or turbos?

I'm not sure what comes with Bun's watch functionality but turbo's is able to track changes across packages in the workspace. If it doesn't look like Bun is watching what you're expecting, I'd give turbo watch a try.
https://turbo.build/repo/docs/reference/watch

authors: anthonyshew huilensolis net-tech

repo: vercel/turborepo


text:
Please provide checksums & Signatures - secure your software

I am starting out with Verge and seeing that it is a secure privacy coin, i dont see any signatures or hashes of your software you provide on github.
Please could you start implementing this so that the average security user can trust that it comes from you?

we will on the next release, thanks

repo: vergecurrency/VERGE


text:
疑似被移动黑名单了，如何证实，如何解决？[Bug]

Verify Steps

[X] Tracker 我已经在 Issue Tracker 中找过我要提出的问题
[X] Latest 我已经使用最新 Dev 版本测试过，问题依旧存在
[X] Core 这是 OpenClash 存在的问题，并非我所使用的 Clash 或 Meta 等内核的特定问题
[X] Meaningful 我提交的不是无意义的 催促更新或修复 请求

OpenClash Version
v0.45.112-beta
Bug on Environment
Lean
Bug on Platform
Linux-amd64(x86-64)
To Reproduce
正常导入就会，打开tun，自定义规则，dns接管，dns缓存不保存
Describe the Bug
昨天因为openwrt崩溃，所以重装了一次，一直都用的esir去年秋天的高大全，按照往常的设置，开始是只连不上谷歌，油管newbing，chatgpt，telegram，bard都行，然后昨天熬夜弄了一天，装了很多版本，固件也换了很多版本，现在变成断断续续所有的都连不上，手机clash和电脑的clash都可以，
OpenClash Log
OpenClash 调试日志
生成时间: 2023-05-13 15:41:22
插件版本: v0.45.112-beta
隐私提示: 上传此日志前请注意检查、屏蔽公网IP、节点、密码等相关敏感信息

#===================== 系统信息 =====================#

主机型号: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz : 4 Core 4 Thread
固件版本: OpenWrt GDQ Winter[2022]
LuCI版本: git-21.335.48743-5f363d9-1
内核版本: 5.10.88
处理器架构: x86_64

#此项有值时,如不使用IPv6,建议到网络-接口-lan的设置中禁用IPV6的DHCP
IPV6-DHCP:

DNS劫持: Dnsmasq 转发
#DNS劫持为Dnsmasq时，此项结果应仅有配置文件的DNS监听地址
Dnsmasq转发设置: 127.0.0.1#7874

#===================== 依赖检查 =====================#

dnsmasq-full: 已安装
coreutils: 已安装
coreutils-nohup: 已安装
bash: 已安装
curl: 已安装
ca-certificates: 已安装
ipset: 已安装
ip-full: 已安装
libcap: 已安装
libcap-bin: 已安装
ruby: 已安装
ruby-yaml: 已安装
ruby-psych: 已安装
ruby-pstore: 已安装
kmod-tun(TUN模式): 已安装
luci-compat(Luci >= 19.07): 已安装
kmod-inet-diag(PROCESS-NAME): 未安装
unzip: 已安装
iptables-mod-tproxy: 已安装
kmod-ipt-tproxy: 已安装
iptables-mod-extra: 未安装
kmod-ipt-extra: 未安装
kmod-ipt-nat: 未安装

#===================== 内核检查 =====================#

运行状态: 运行中
运行内核：TUN
进程pid: 18578
运行权限: 18578: cap_dac_override,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_ptrace,cap_sys_resource=eip
运行用户: nobody
已选择的架构: linux-amd64

#下方无法显示内核版本号时请确认您的内核版本是否正确或者有无权限
Tun内核版本: 2023.04.16
Tun内核文件: 存在
Tun内核运行权限: 正常

Dev内核版本: v1.15.1-7-g6eee226
Dev内核文件: 存在
Dev内核运行权限: 正常

Meta内核版本:
Meta内核文件: 不存在
Meta内核运行权限: 否

#===================== 插件设置 =====================#

当前配置文件: /etc/openclash/config/🤮.yaml
启动配置文件: /etc/openclash/🤮.yaml
运行模式: redir-host-mix
默认代理模式: rule
UDP流量转发(tproxy): 停用
自定义DNS: 启用
IPV6代理: 停用
IPV6-DNS解析: 停用
禁用Dnsmasq缓存: 启用
自定义规则: 启用
仅允许内网: 停用
仅代理命中规则流量: 停用
仅允许常用端口流量: 停用
绕过中国大陆IP: 停用
路由本机代理: 停用

#启动异常时建议关闭此项后重试
混合节点: 停用
保留配置: 停用

#启动异常时建议关闭此项后重试
第三方规则: 停用

#===================== 自定义规则 一 =====================#
script:
##  shortcuts:
##    quic: network == 'udp' and dst_port == 443 and (geoip(resolve_ip(host)) != 'CN' or geoip(dst_ip) != 'CN')
##    time-limit: in_cidr(src_ip,'192.168.1.2/32') and time.now().hour < 20 or time.now().hour > 21
##    time-limit: src_ip == '192.168.1.2' and time.now().hour < 20 or time.now().hour > 21

rules:
##- SCRIPT,quic,REJECT #shortcuts rule
##- SCRIPT,time-limit,REJECT #shortcuts rule
- DOMAIN-KEYWORD,bard,GLOBAL

- DOMAIN-SUFFIX,openai.com,GLOBAL
- DOMAIN-SUFFIX,pay.openai.com,GLOBAL
- DOMAIN-SUFFIX,chat.openai.com,GLOBAL
- DOMAIN-SUFFIX,challenges.cloudflare.com,GLOBAL
- DOMAIN-SUFFIX,auth0.openai.com,GLOBAL
- DOMAIN-SUFFIX,platform.openai.com,GLOBAL
# Add ai.com
- DOMAIN-SUFFIX,ai.com,GLOBAL
# Add stripe.com
- DOMAIN-SUFFIX,invoice.stripe.com,GLOBAL
- DOMAIN-SUFFIX,stripe.com,GLOBAL
- DOMAIN-KEYWORD,xbox,DIRECT #匹配域名关键字(交由Proxy代理服务器组)
- DOMAIN-SUFFIX,mypikpak.com,DIRECT
- DOMAIN-SUFFIX,bing.com,GLOBAL
- DOMAIN-SUFFIX,bing.net,GLOBAL
- DOMAIN-SUFFIX,bingads.com,GLOBAL
- DOMAIN-SUFFIX,bingagencyawards.com,GLOBAL
- DOMAIN-SUFFIX,bingapistatistics.com,GLOBAL
- DOMAIN-SUFFIX,bingsandbox.com,GLOBAL
- DOMAIN-SUFFIX,bingvisualsearch.com,GLOBAL
- DOMAIN-SUFFIX,bingworld.com,GLOBAL
- DOMAIN-SUFFIX,bluehatnights.com,GLOBAL
- DOMAIN-SUFFIX,dictate.ms,GLOBAL
- DOMAIN-SUFFIX,flipwithsurface.com,GLOBAL
- DOMAIN-SUFFIX,masalladeloslimites.com,GLOBAL
- DOMAIN-SUFFIX,microsoft-give.com,GLOBAL
- DOMAIN-SUFFIX,microsoftcloudsummit.com,GLOBAL
- DOMAIN-SUFFIX,microsoftdiplomados.com,GLOBAL
- DOMAIN-SUFFIX,microsoftlatamholiday.com,GLOBAL
- DOMAIN-SUFFIX,microsoftmxfilantropia.com,GLOBAL
- DOMAIN-SUFFIX,microsoftpartnersolutions.com,GLOBAL
- DOMAIN-SUFFIX,msunlimitedcloudsummit.com,GLOBAL
- DOMAIN-SUFFIX,office365love.com,GLOBAL
- DOMAIN-SUFFIX,office365tw.com,GLOBAL
- DOMAIN-SUFFIX,renovacionoffice.com,GLOBAL
- DOMAIN-SUFFIX,sprinklesapp.com,GLOBAL
- DOMAIN-SUFFIX,tgfcer.com,DIRECT
##- DOMAIN-SUFFIX,google.com,Proxy #匹配域名后缀(交由Proxy代理服务器组)
##- DOMAIN-KEYWORD,google,Proxy #匹配域名关键字(交由Proxy代理服务器组)
##- DOMAIN,google.com,Proxy #匹配域名(交由Proxy代理服务器组)
##- DOMAIN-SUFFIX,ad.com,REJECT #匹配域名后缀(拒绝)
##- IP-CIDR,127.0.0.0/8,DIRECT #匹配数据目标IP(直连)
##- SRC-IP-CIDR,192.168.1.201/32,DIRECT #匹配数据发起IP(直连)
##- DST-PORT,80,DIRECT #匹配数据目标端口(直连)
##- SRC-PORT,7777,DIRECT #匹配数据源端口(直连)

##排序在上的规则优先生效,如添加（去除规则前的#号）：
##IP段：192.168.1.2-192.168.1.200 直连
##- SRC-IP-CIDR,192.168.1.2/31,DIRECT
##- SRC-IP-CIDR,192.168.1.4/30,DIRECT
##- SRC-IP-CIDR,192.168.1.8/29,DIRECT
##- SRC-IP-CIDR,192.168.1.16/28,DIRECT
##- SRC-IP-CIDR,192.168.1.32/27,DIRECT
##- SRC-IP-CIDR,192.168.1.64/26,DIRECT
##- SRC-IP-CIDR,192.168.1.128/26,DIRECT
##- SRC-IP-CIDR,192.168.1.192/29,DIRECT
##- SRC-IP-CIDR,192.168.1.200/32,DIRECT

##IP段：192.168.1.202-192.168.1.255 直连
##- SRC-IP-CIDR,192.168.1.202/31,DIRECT
##- SRC-IP-CIDR,192.168.1.204/30,DIRECT
##- SRC-IP-CIDR,192.168.1.208/28,DIRECT
##- SRC-IP-CIDR,192.168.1.224/27,DIRECT

##此时IP为192.168.1.1和192.168.1.201的客户端流量走代理（策略），其余客户端不走代理
##因为Fake-IP模式下，IP地址为192.168.1.1的路由器自身流量可走代理（策略），所以需要排除

##仅设置路由器自身直连：
##- SRC-IP-CIDR,192.168.1.1/32,DIRECT
##- SRC-IP-CIDR,198.18.0.1/32,DIRECT

##DDNS
##- DOMAIN-SUFFIX,checkip.dyndns.org,DIRECT
##- DOMAIN-SUFFIX,checkipv6.dyndns.org,DIRECT
##- DOMAIN-SUFFIX,checkip.synology.com,DIRECT
##- DOMAIN-SUFFIX,ifconfig.co,DIRECT
##- DOMAIN-SUFFIX,api.myip.com,DIRECT
##- DOMAIN-SUFFIX,ip-api.com,DIRECT
##- DOMAIN-SUFFIX,ipapi.co,DIRECT
##- DOMAIN-SUFFIX,ip6.seeip.org,DIRECT
##- DOMAIN-SUFFIX,members.3322.org,DIRECT

##在线IP段转CIDR地址：http://ip2cidr.com
#===================== 自定义规则 二 =====================#
script:
##  shortcuts:
##    common_port: dst_port not in [21, 22, 23, 53, 80, 123, 143, 194, 443, 465, 587, 853, 993, 995, 998, 2052, 2053, 2082, 2083, 2086, 2095, 2096, 5222, 5228, 5229, 5230, 8080, 8443, 8880, 8888, 8889]

rules:
##- SCRIPT,common_port,DIRECT #shortcuts rule

##- DOMAIN-SUFFIX,google.com,Proxy #匹配域名后缀(交由Proxy代理服务器组)
##- DOMAIN-KEYWORD,google,Proxy #匹配域名关键字(交由Proxy代理服务器组)
##- DOMAIN,google.com,Proxy #匹配域名(交由Proxy代理服务器组)
##- DOMAIN-SUFFIX,ad.com,REJECT #匹配域名后缀(拒绝)
##- IP-CIDR,127.0.0.0/8,DIRECT #匹配数据目标IP(直连)
##- SRC-IP-CIDR,192.168.1.201/32,DIRECT #匹配数据发起IP(直连)
##- DST-PORT,80,DIRECT #匹配数据目标端口(直连)
##- SRC-PORT,7777,DIRECT #匹配数据源端口(直连)

#===================== 配置文件 =====================#

port: 7890
socks-port: 7891
allow-lan: true
mode: rule
log-level: silent
external-controller: 0.0.0.0:9090
proxy-groups:
- name: "\U0001F680 节点选择"
  type: select
  proxies:
  - "♻ 自动选择"
  - "\U0001F1ED\U0001F1F0 香港节点"
  - "\U0001F1E8\U0001F1F3 台湾节点"

- "IP-CIDR,103.196.64.0/22,\U0001F3AF 全球直连,no-resolve"

COMMIT
# Completed on Sat May 13 15:41:25 2023

#===================== IPSET状态 =====================#

Name: cn
Name: ct
Name: cnc
Name: cmcc
Name: crtc
Name: cernet
Name: gwbn
Name: othernet
Name: music
Name: mwan3_connected_v4
Name: mwan3_connected_v6
Name: mwan3_source_v6
Name: mwan3_dynamic_v4
Name: mwan3_dynamic_v6
Name: mwan3_custom_v4
Name: mwan3_custom_v6
Name: localnetwork
Name: china_ip_route
Name: china_ip_route_pass
Name: mwan3_connected

#===================== 路由表状态 =====================#

#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    64     0        0 eth1
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     64     0        0 eth1
192.168.5.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
198.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 utun
#ip route list
default via 192.168.0.1 dev eth1 proto static src 192.168.0.100 metric 64
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev eth1 proto static scope link metric 64
192.168.5.0/24 dev br-lan proto kernel scope link src 192.168.5.1
198.18.0.0/16 dev utun proto kernel scope link src 198.18.0.1
#ip rule show
0:	from all lookup local
32765:	from all fwmark 0x162 lookup 354
32766:	from all lookup main
32767:	from all lookup default

#===================== Tun设备状态 =====================#

utun: tun pi multi_queue filter

#===================== 端口占用状态 =====================#

tcp        0      0 198.18.0.1:7777         0.0.0.0:*               LISTEN      18578/clash
tcp        0      0 :::9090                 :::*                    LISTEN      18578/clash
tcp        0      0 :::7890                 :::*                    LISTEN      18578/clash
tcp        0      0 :::7891                 :::*                    LISTEN      18578/clash
tcp        0      0 :::7892                 :::*                    LISTEN      18578/clash
tcp        0      0 :::7893                 :::*                    LISTEN      18578/clash
tcp        0      0 :::7895                 :::*                    LISTEN      18578/clash
udp        0      0 :::7874                 :::*                                18578/clash
udp        0      0 :::7891                 :::*                                18578/clash
udp        0      0 :::7892                 :::*                                18578/clash
udp        0      0 :::7893                 :::*                                18578/clash
udp        0      0 :::7895                 :::*                                18578/clash

#===================== 测试本机DNS查询(www.baidu.com) =====================#

Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	www.baidu.com
Address: 120.232.145.144
Name:	www.baidu.com
Address: 120.232.145.185

#===================== 测试内核DNS查询(www.instagram.com) =====================#

Status: 0
TC: false
RD: true
RA: true
AD: false
CD: false

Question:
  Name: www.instagram.com.
  Qtype: 1
  Qclass: 1

Answer:
  TTL: 1427
  data: geo-p42.instagram.com.
  name: www.instagram.com.
  type: 5

  TTL: 1427
  data: z-p42-instagram.c10r.instagram.com.
  name: geo-p42.instagram.com.
  type: 5

  TTL: 60
  data: 31.13.82.174
  name: z-p42-instagram.c10r.instagram.com.
  type: 1

#===================== resolv.conf.d =====================#

# Interface wan
nameserver 192.168.1.1
nameserver 192.168.0.1

#===================== 测试本机网络连接(www.baidu.com) =====================#

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Connection: keep-alive
Content-Length: 277
Content-Type: text/html
Date: Sat, 13 May 2023 07:41:26 GMT
Etag: "575e1f6f-115"
Last-Modified: Mon, 13 Jun 2016 02:50:23 GMT
Pragma: no-cache
Server: bfe/1.0.8.18

#===================== 测试本机网络下载(raw.githubusercontent.com) =====================#

HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 83
Cache-Control: max-age=300
Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; sandbox
Content-Type: text/plain; charset=utf-8
ETag: "c4bb90ae438326968603faec1fb27380615fa6040485f63636e70d4cbfae644b"
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
X-GitHub-Request-Id: 9B08:4BE9:E5241C:1055ACE:645EDF98
Accept-Ranges: bytes
Date: Sat, 13 May 2023 07:41:28 GMT
Via: 1.1 varnish
X-Served-By: cache-sjc1000128-SJC
X-Cache: HIT
X-Cache-Hits: 1
X-Timer: S1683963688.172209,VS0,VE180
Vary: Authorization,Accept-Encoding,Origin
Access-Control-Allow-Origin: *
X-Fastly-Request-ID: f311201e57653467973941c4b6b101afc9fec75b
Expires: Sat, 13 May 2023 07:46:28 GMT
Source-Age: 0

#===================== 最近运行日志(自动切换为Debug模式) =====================#

15:36:10 INF [Config] initial compatible provider name=🚀 节点选择
15:36:10 INF [Config] initial compatible provider name=📢 谷歌FCM
15:36:10 INF [Config] initial compatible provider name=Ⓜ 微软云盘
15:36:10 INF [Config] initial compatible provider name=🍃 应用净化
15:36:10 INF [Config] initial compatible provider name=🇰🇷 韩国节点
15:36:10 INF [Config] initial compatible provider name=🇯🇵 日本节点
15:36:10 INF [Config] initial compatible provider name=🇨🇳 台湾节点
15:36:10 INF [Config] initial compatible provider name=📲 电报消息
15:36:10 INF [Config] initial compatible provider name=Ⓜ 微软服务
15:36:10 INF [Config] initial compatible provider name=🚀 手动切换
15:36:10 INF [Config] initial compatible provider name=🐟 漏网之鱼
15:36:10 INF [Config] initial compatible provider name=🌍 国外媒体
15:36:10 INF [Config] initial compatible provider name=🎮 游戏平台
15:36:10 INF [Config] initial compatible provider name=🇸🇬 狮城节点
15:36:10 INF [Config] initial compatible provider name=📹 油管视频
15:36:10 INF [Config] initial compatible provider name=🍎 苹果服务
15:36:10 INF [Config] initial compatible provider name=📺 巴哈姆特
15:36:10 INF [Config] initial compatible provider name=🎥 奈飞视频
15:36:10 INF [Config] initial compatible provider name=📺 哔哩哔哩
15:36:10 INF [Config] initial compatible provider name=🎶 网易音乐
15:36:10 INF [Config] initial compatible provider name=🇺🇲 美国节点
15:36:10 INF [Config] initial compatible provider name=🇭🇰 香港节点
2023-05-13 15:36:13 Step 6: Wait For The File Downloading...
2023-05-13 15:36:14 Step 7: Set Firewall Rules...
2023-05-13 15:36:14 Tip: DNS Hijacking Mode is Dnsmasq Redirect...
2023-05-13 15:36:14 Tip: Waiting for TUN Interface Start...
2023-05-13 15:36:14 Tip: Start Add Port Bypassing Rules For Firewall Redirect and Firewall Rules...
2023-05-13 15:36:14 Tip: Start Add Custom Firewall Rules...
2023-05-13 15:36:14 Step 8: Restart Dnsmasq...
2023-05-13 15:36:15 Step 9: Add Cron Rules, Start Daemons...
2023-05-13 15:36:15 OpenClash Start Successful!
2023-05-13 15:40:56 OpenClash Restart...
2023-05-13 15:40:56 OpenClash Stoping...
2023-05-13 15:40:56 Step 1: Backup The Current Groups State...
2023-05-13 15:40:56 Step 2: Delete OpenClash Firewall Rules...
2023-05-13 15:40:58 Step 3: Close The OpenClash Daemons...
2023-05-13 15:40:58 Step 4: Close The Clash Core Process...
2023-05-13 15:40:58 Step 5: Restart Dnsmasq...
2023-05-13 15:41:04 Step 6: Delete OpenClash Residue File...
2023-05-13 15:41:04 OpenClash Start Running...
2023-05-13 15:41:04 Step 1: Get The Configuration...
2023-05-13 15:41:04 Step 2: Check The Components...
2023-05-13 15:41:05 Tip: Because of the file【 /etc/config/openclash 】modificated, Pause quick start...
2023-05-13 15:41:05 Step 3: Modify The Config File...
2023-05-13 15:41:07 Tip: You have seted the authentication of SOCKS5/HTTP(S) proxy with【】
2023-05-13 15:41:11 Tip: Start Running Custom Overwrite Scripts...
2023-05-13 15:41:11 Step 4: Start Running The Clash Core...
2023-05-13 15:41:11 Tip: Detected The Exclusive Function of The TUN Core, Use TUN Core to Start...
2023-05-13 15:41:12 Step 5: Check The Core Status...
15:41:12 INF [Config] initial compatible provider name=🎶 网易音乐
15:41:12 INF [Config] initial compatible provider name=🎥 奈飞节点
15:41:12 INF [Config] initial compatible provider name=🌍 国外媒体
15:41:12 INF [Config] initial compatible provider name=🛑 广告拦截
15:41:12 INF [Config] initial compatible provider name=🎮 游戏平台
15:41:12 INF [Config] initial compatible provider name=Ⓜ 微软云盘
15:41:12 INF [Config] initial compatible provider name=🍃 应用净化
15:41:12 INF [Config] initial compatible provider name=🍎 苹果服务
15:41:12 INF [Config] initial compatible provider name=📺 巴哈姆特
15:41:12 INF [Config] initial compatible provider name=📹 油管视频
15:41:12 INF [Config] initial compatible provider name=🇰🇷 韩国节点
15:41:12 INF [Config] initial compatible provider name=🇸🇬 狮城节点
15:41:12 INF [Config] initial compatible provider name=📲 电报消息
15:41:12 INF [Config] initial compatible provider name=🌏 国内媒体
15:41:12 INF [Config] initial compatible provider name=🇺🇲 美国节点
15:41:12 INF [Config] initial compatible provider name=🇨🇳 台湾节点
15:41:12 INF [Config] initial compatible provider name=🚀 手动切换
15:41:12 INF [Config] initial compatible provider name=🎥 奈飞视频
15:41:12 INF [Config] initial compatible provider name=📺 哔哩哔哩
15:41:12 INF [Config] initial compatible provider name=🚀 节点选择
15:41:12 INF [Config] initial compatible provider name=🐟 漏网之鱼
15:41:12 INF [Config] initial compatible provider name=Ⓜ 微软服务
15:41:12 INF [Config] initial compatible provider name=📢 谷歌FCM
15:41:12 INF [Config] initial compatible provider name=🇯🇵 日本节点
15:41:12 INF [Config] initial compatible provider name=🇭🇰 香港节点
15:41:12 INF [Config] initial compatible provider name=♻ 自动选择
15:41:12 INF [Config] initial compatible provider name=🎯 全球直连
2023-05-13 15:41:15 Step 6: Wait For The File Downloading...
2023-05-13 15:41:16 Step 7: Set Firewall Rules...
2023-05-13 15:41:16 Tip: DNS Hijacking Mode is Dnsmasq Redirect...
2023-05-13 15:41:16 Tip: Waiting for TUN Interface Start...
2023-05-13 15:41:16 Tip: Start Add Port Bypassing Rules For Firewall Redirect and Firewall Rules...
2023-05-13 15:41:16 Tip: Start Add Custom Firewall Rules...
2023-05-13 15:41:16 Step 8: Restart Dnsmasq...
2023-05-13 15:41:17 Step 9: Add Cron Rules, Start Daemons...
2023-05-13 15:41:17 OpenClash Start Successful!
15:41:28 DBG [TCP] accept connection lAddr=192.168.5.210:3951 rAddr=sydney.bing.com:443 inbound=Redir
15:41:29 INF [TCP] connected lAddr=192.168.5.210:3951 rAddr=sydney.bing.com:443 mode=rule rule=DomainSuffix(bing.com) proxy=GLOBAL[🇺🇸 美国·3]
15:41:30 DBG [DNS] dns response source=https://public.dns.iij.jp/dns-query qType=A name=clients4.google.com. answer=["142.250.207.14"]
15:41:30 DBG [TCP] accept connection lAddr=192.168.5.210:3952 rAddr=clients4.google.com:443 inbound=Redir
15:41:30 DBG [Matcher] find process failed error=socket: protocol not supported addr=clients4.google.com
15:41:31 INF [TCP] connected lAddr=192.168.5.210:3952 rAddr=clients4.google.com:443 mode=rule rule=DomainKeyword(google) proxy=🚀 节点选择[🇺🇸 美国·3]
15:41:33 DBG [TCP] accept connection lAddr=192.168.5.210:3953 rAddr=instantmessaging-pa.googleapis.com:443 inbound=Redir
15:41:33 DBG [Matcher] find process failed error=socket: protocol not supported addr=instantmessaging-pa.googleapis.com
15:41:33 DBG [TCP] accept connection lAddr=192.168.5.210:3954 rAddr=instantmessaging-pa.googleapis.com:443 inbound=Redir
15:41:33 DBG [Matcher] find process failed error=socket: protocol not supported addr=instantmessaging-pa.googleapis.com
15:41:33 INF [TCP] connected lAddr=192.168.5.210:3953 rAddr=instantmessaging-pa.googleapis.com:443 mode=rule rule=DomainKeyword(google) proxy=🚀 节点选择[🇺🇸 美国·3]
15:41:34 INF [TCP] connected lAddr=192.168.5.210:3954 rAddr=instantmessaging-pa.googleapis.com:443 mode=rule rule=DomainKeyword(google) proxy=🚀 节点选择[🇺🇸 美国·3]
15:41:34 DBG [TCP] accept connection lAddr=192.168.5.210:3955 rAddr=remotedesktop-pa.googleapis.com:443 inbound=Redir
15:41:35 DBG [Matcher] find process failed error=socket: protocol not supported addr=remotedesktop-pa.googleapis.com
15:41:35 INF [TCP] connected lAddr=192.168.5.210:3955 rAddr=remotedesktop-pa.googleapis.com:443 mode=rule rule=DomainKeyword(google) proxy=🚀 节点选择[🇺🇸 美国·3]

#===================== 最近运行日志获取完成(自动切换为silent模式) =====================#

#===================== 活动连接信息 =====================#

1. SourceIP:【192.168.5.210】 - Host:【sydney.bing.com】 - DestinationIP:【13.107.21.237】 - Network:【tcp】 - RulePayload:【bing.com】 - Lastchain:【🇺🇸 美国·3】
2. SourceIP:【192.168.5.210】 - Host:【clients4.google.com】 - DestinationIP:【】 - Network:【tcp】 - RulePayload:【google】 - Lastchain:【🇺🇸 美国·3】
3. SourceIP:【192.168.5.210】 - Host:【api-ipv4.ip.sb】 - DestinationIP:【104.26.13.31】 - Network:【tcp】 - RulePayload:【】 - Lastchain:【🇻🇳 越南优化·4】
4. SourceIP:【192.168.5.210】 - Host:【watson.events.data.microsoft.com】 - DestinationIP:【20.189.173.21】 - Network:【tcp】 - RulePayload:【microsoft】 - Lastchain:【🇺🇸 美国·2】
5. SourceIP:【192.168.5.210】 - Host:【qqwry.api.skk.moe】 - DestinationIP:【172.67.148.227】 - Network:【tcp】 - RulePayload:【skk.moe】 - Lastchain:【🇺🇸 美国·2】
6. SourceIP:【192.168.5.210】 - Host:【instantmessaging-pa.googleapis.com】 - DestinationIP:【172.217.163.42】 - Network:【tcp】 - RulePayload:【google】 - Lastchain:【🇺🇸 美国·3】
7. SourceIP:【192.168.5.210】 - Host:【remotedesktop-pa.googleapis.com】 - DestinationIP:【216.58.220.106】 - Network:【tcp】 - RulePayload:【google】 - Lastchain:【🇺🇸 美国·3】
8. SourceIP:【192.168.5.210】 - Host:【d.skk.moe】 - DestinationIP:【104.16.20.35】 - Network:【tcp】 - RulePayload:【skk.moe】 - Lastchain:【🇺🇸 美国·2】
9. SourceIP:【192.168.5.210】 - Host:【content-autofill.googleapis.com】 - DestinationIP:【172.217.174.106】 - Network:【tcp】 - RulePayload:【google】 - Lastchain:【🇺🇸 美国·2】
10. SourceIP:【192.168.5.210】 - Host:【instantmessaging-pa.googleapis.com】 - DestinationIP:【172.217.163.42】 - Network:【tcp】 - RulePayload:【google】 - Lastchain:【🇺🇸 美国·3】

OpenClash Config
No response
Expected Behavior
就是希望能跟以前一样，不要再短短徐徐连不上了，用了一年多第一次出现这么严重的问题
Screenshots

我试过更新内核，更新依赖，重装clash，但是重装后又会出现诡异的ruby依赖问题，卸载后直接没网，覆写ruby后也会出现ruby依赖问题
实在是没办法了，希望各位大哥帮帮忙

安装了USB tether以后，使用手机联通网络出口，设置不变，网络畅通，墙线接口是移动的，是否说明我被移动“黑名单”？能否说说这种情况如何解决？

#3249 最近新刷机的，如果发现卸载/关闭openclash后直接没网，参考这个issue里给的解决方案。
如果看不懂的话，建议直接回退openwrt的版本，比如21.02就挺好
解决了没网的问题后，再排查代理不工作的问题。
至于你说的这个所谓黑名单。。“熬夜弄了一天，装了很多版本，固件也换了很多版本”并不说明什么问题，只表明你完全不知道该如何排错。
可以考虑这样测试：
在软路由上把openclash跑起来，假设软路由ip是192.168.1.1，电脑就把系统代理指向192.168.1.1:7890（方法自行百度）然后用浏览器测试能否正常翻墙。
如果可以的话，说明clash内核正常工作，但你使用openwrt时把透明代理环境给玩炸了。建议老老实实把整个openwrt和openclash重置，再从头设置一遍。
如果还是不能翻墙，说明clash内核也没正常工作，这个原因可能就太多了，懒得写了。

#3249 最近新刷机的，如果发现卸载/关闭openclash后直接没网，参考这个issue里给的解决方案。 如果看不懂的话，建议直接回退openwrt的版本，比如21.02就挺好
解决了没网的问题后，再排查代理不工作的问题。 至于你说的这个所谓黑名单。。“熬夜弄了一天，装了很多版本，固件也换了很多版本”并不说明什么问题，只表明你完全不知道该如何排错。
可以考虑这样测试： 在软路由上把openclash跑起来，假设软路由ip是192.168.1.1，电脑就把系统代理指向192.168.1.1:7890（方法自行百度）然后用浏览器测试能否正常翻墙。 如果可以的话，说明clash内核正常工作，但你使用openwrt时把透明代理环境给玩炸了。建议老老实实把整个openwrt和openclash重置，再从头设置一遍。 如果还是不能翻墙，说明clash内核也没正常工作，这个原因可能就太多了，懒得写了。

根本不是这个问题，我重装dnsmsq和更改解析文件都试过了，另外openwrt 22的这个版本我是去年用到现在的，一直都没问题，我openclash卸载和重装依赖升级内核做过很多次了，另外设置系统代理以后上网需要输入用户名和密码，而且依旧上不了网。至于你说的排错，我是按照openclashwiki里的排错步骤来的，截图也都在上面，另外我说的很清楚了我用手机的网络Open WRT是没问题的证明它的设置是没问题的。

调试日志发全一点，防火墙都没了，你试试绑定接口

authors: PolymorphismException deuteros-gex hong954701693 vernesong

repo: vernesong/OpenClash


text:
Update parent version

Update the version of the used parents (vertx-parent and vertx-ext-parent).

Waiting for a new release of vertx-ext-parent.

Have updated most of the project.
Are still not updated (no commit right):
[ ] - vertx-dropwizard-metrics
[ ] - vertx-embedded-mongo-db
[ ] - vertx-hazelcast
[ ] - vertx-sql-common
[ ] - vertx-core
@purplefox - I let you handle vertx-core
@vietj @purplefox - can you add me as committer to the other repositories

@purplefox here is the parent definitino for vertx-core:
  <parent>
    <groupId>io.vertx</groupId>
    <artifactId>vertx-parent</artifactId>
    <version>8</version>
  </parent>

The parent version update is part of the PR: https://github.com/eclipse/vert.x/pull/1098


text:
[ISSUE] Cannot build CardIO module with CocoaPods on Xcode 12

Describe the bug
When including the VGSCollectSDK in an iOS build on Xcode 12 the pod will not link correctly without forcing exclude arm64 architecture for simulator builds.
The following build error occurs in our circleci build:
▸ Linking VGSCollectSDK
❌  ld: building for iOS Simulator, but linking in dylib built for iOS, file '/Users/distiller/project/Pods/CardIOSDK/Carthage/Build/iOS/CardIO.framework/CardIO' for architecture arm64

To Reproduce
Steps to reproduce the behavior:

Include VGSCollecSDK pod 1.6.1 or 1.6.2
Build for iOS simulator in circleci env with Xcode 12.x

Expected behavior
Build completes successfully.
Possible Solution
Exclude arm64 for iOS simulator SDK builds in the VGSCollect SDK pod build settings.

Thanks @isimpson, we will check it.

@isimpson I did few tests, but could reproduce the issue.
Here are CircleCI config where I did tests:

Xcode: "12.0" and "12.2.0"
VGSCollectSDK: 1.6.1 and 1.6.2
CocoaPods: 1.9.3
SCAN_DEVICE: iPhone 11

Also didn't see issue when integrating SDK locally on my working machine with Xcode12.
Could you provide more details, probably some specific version of Xcode or Cocoapods.

@dmytrokhl I was using pretty much the same environment you have, does your project exclude the arm64 architecture for simulator builds?

I use Standard Architecture - $(ARCHS_STANDARD) only. Similar as in our sample app - https://github.com/vgs-samples/very-spacy-food

I wonder is it more related to VGSCollectSDK/CardIO do you have that included?

I did UI tests with VGSCollectSDK/CardIO included. After adding arm64  to  Excluded Architectures  in test app didn't see any issue.
I suppose the issue could be in CardIO SDK since it not supported and pretty old, will check it.

Thanks for investigating, it only occurs when arm64 is NOT in excluded architectures.

Hi @isimpson, some updates here!
We released v1.6.3, where we excluded arm64 architectures in CardIO Dynamic Wrapper.
But it seems that the issue is mostly related to CardIO build and Carthage-Xcode 12 issue described here.
Since CardIO is static library and not supported for few years already, we made CardIO Dynamic wrapper to make it possible to integrate CardIO into Swift framework via CocoaPods. This wrapper is actually using CardIO build made with Carthage(Xcode 11), and now Carthage doesn't work properly with Xcode 12.
Currently I'm checking for workarounds how to rebuild CardIO with Carthage in Xcode 12 and release a new version of CardIO Dynamic wrapper.
The other possible issue could be that CocoaPods don't have yet full support of Xcode 12. Xcode 12 support is released only in v1.10.0-beta.
By the way I still couldn't reproduce your issue in CircleCI.

@isimpson we create a new CardIOSDK version, that is built in Xcode12, and add it to VGSCollectSDK/CardIO subspec.
The update is still in testing branch, so if you would like to test it, you should point VGSCollectSDK pods to that branch:
 pod 'VGSCollectSDK', :git => 'https://github.com/verygoodsecurity/vgs-collect-ios.git', :branch => 'feature/update_cardio_sdk_version'
 pod 'VGSCollectSDK/CardIO', :git => 'https://github.com/verygoodsecurity/vgs-collect-ios.git', :branch => 'feature/update_cardio_sdk_version'

Let us know it that fixed your issue.

This is fixed in VGSCollectSDK v1.7.0.

@dmytrokhl thanks we'll update soon 🙏

@dmytrokhl I dont think this has fixed the issue we still see the following issue in our builds with the latest 1.7.0 sdk:
[10:52:24]: ▸ Processing VGSCollectSDK-Info.plist
[10:52:24]: ▸ Linking VGSCollectSDK
[10:52:24]: ▸ Linking VGSCollectSDK
[10:52:24]: ▸ ❌  ld: building for iOS Simulator, but linking in dylib built for iOS, file '/Users/distiller/project/Pods/CardIOSDK/Carthage/Build/iOS/CardIO.framework/CardIO' for architecture arm64
[10:52:24]: ▸ ❌  clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hi @isimpson , do you see same issue when testing your Demo App ?
I'm curious about the issue because we did tests on multiple machines here, as well as our customers also test this version and didn't see the issue.
To investigate it deeper could you provide us specific version of Xcode and CocoaPods that you use. Also do you see any difference in Build Setting section between your project and our Demo App that could cause the issue? That could help us to reproduce it.

At least we use:
    platform :ios, '11.0'
Your demo app is using iOS 10.1.
I'll also dig when I have time and see if I can find the issue.

Ok I managed to reproduce this in your demoapp by updating the CardIOSSDK target iOS Deployment Target to iOS 9.0 and then running the following command to build the scheme:
xcodebuild -workspace "demoapp.xcworkspace" -scheme "demoapp" -configuration "Debug" -sdk "iphonesimulator" clean build
Error:
ld: building for iOS Simulator, but linking in dylib built for iOS, file '/vgs-collect-ios/demoapp/Pods/CardIOSDK/Carthage/Build/iOS/CardIO.framework/CardIO' for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Thanks @isimpson . We support iOS10+, but will try to reproduce the issues.

@dmytrokhl Hi, we are seeing this issue again when running on M1 devices, the CardIO dependency fails, is there any update on it?

Hi @MikeFynes , could you provide us more details with this issue:

VGSCollectSDK version
Cocoapods version
Xcode version
Error logs(if possible)

Also does this issue reproduced only on M1 devices?

We were using 1.6.3, but I updated to 1.7.6 and the issue is still present.
Latest Cocoapods
Latest Xcode

This is the build output showing the issue:
    cd /Users/dag/Code/Wolt-iOS/Pods
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target arm64-apple-ios11.0-simulator -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.4.sdk -L/Users/dag/Library/Developer/Xcode/DerivedData/WoltClient-ehprrlmkemhfagarjcghjowbksfw/Build/Products/Debug-iphonesimulator/VGSCollectSDK -F/Users/dag/Library/Developer/Xcode/DerivedData/WoltClient-ehprrlmkemhfagarjcghjowbksfw/Build/Products/Debug-iphonesimulator/VGSCollectSDK -F/Users/dag/Code/Wolt-iOS/Pods/CardIOSDK/Carthage/Build/iOS -filelist /Users/dag/Library/Developer/Xcode/DerivedData/WoltClient-ehprrlmkemhfagarjcghjowbksfw/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/VGSCollectSDK.build/Objects-normal/arm64/VGSCollectSDK.LinkFileList -install_name @rpath/VGSCollectSDK.framework/VGSCollectSDK -Xlinker -rpath -Xlinker /usr/lib/swift -Xlinker -rpath -Xlinker @executable_path/Frameworks -Xlinker -rpath -Xlinker @loader_path/Frameworks -dead_strip -Xlinker -object_path_lto -Xlinker /Users/dag/Library/Developer/Xcode/DerivedData/WoltClient-ehprrlmkemhfagarjcghjowbksfw/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/VGSCollectSDK.build/Objects-normal/arm64/VGSCollectSDK_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -Xlinker -objc_abi_version -Xlinker 2 -fobjc-arc -fobjc-link-runtime -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /Users/dag/Library/Developer/Xcode/DerivedData/WoltClient-ehprrlmkemhfagarjcghjowbksfw/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/VGSCollectSDK.build/Objects-normal/arm64/VGSCollectSDK.swiftmodule -framework CardIO -framework Foundation -Xlinker -no_adhoc_codesign -compatibility_version 1 -current_version 1 -Xlinker -dependency_info -Xlinker /Users/dag/Library/Developer/Xcode/DerivedData/WoltClient-ehprrlmkemhfagarjcghjowbksfw/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/VGSCollectSDK.build/Objects-normal/arm64/VGSCollectSDK_dependency_info.dat -o /Users/dag/Library/Developer/Xcode/DerivedData/WoltClient-ehprrlmkemhfagarjcghjowbksfw/Build/Products/Debug-iphonesimulator/VGSCollectSDK/VGSCollectSDK.framework/VGSCollectSDK

ld: building for iOS Simulator, but linking in dylib built for iOS, file '/Users/dag/Code/Wolt-iOS/Pods/CardIOSDK/Carthage/Build/iOS/CardIO.framework/CardIO' for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)```

To work around this, we disable arm64 for all targets by editing the Podfile and out xcodeproj, but, this prevents us from adding standalone test targets to our project, as those have to be built for the native architecture, and on an M1 Mac, this is arm64.

The secondary issue with test targets only happens on M1 machines, and not sure about the core issue with the linking error, as I am testing this on M1 right now, but we added this workaround before M1 machines existed so I assume it happens on Intel as well.

Thanks @DagAgren . I'm worry the issue could be with new architectures support in Card.io SDK, since it's not maintained anymore by PayPal. We will check what we can do from our side, as for now we couldn't reproduce the issue.
I also can recommend you to check the other scan module that could be integrated with VGSCollectSDK.

Switching to CardScan does indeed fix the issue, but CardScan is a paid service so this is far from an ideal solution.
I thought you were building CardIO yourselves? It needs to have a proper arm64 build to work.

We will schedule some time next week to test if it could be fixed with building card.io as xcframework.
Generally, we don't maintain card.io, since it’s owned by PayPal. We only did create a dynamic wrapper to make it possible to use in Swift SDK and descope users from PCI scope.
The long-term perspective will be to get rid of Card.io since it takes a lot of effort to main it with each Apple/Xcode/CocoaPods updates. Probably we will find some other free Card Scanning solution to replace it.

@DagAgren @MikeFynes @isimpson we did rebuild Card.io framework and release a new version that should allow to integrate CardIO module  with CocoaPods on Apple Silicon. Please check VGSCollectSDK v1.7.13.

authors: DagAgren MikeFynes dmytrokhl isimpson

repo: verygoodsecurity/vgs-collect-ios


text:
Fix: dnSpy is opened with reference assemblies for .net framework code

How about this to fix #2
Testet with mscorlib 4.0 on Windows 10 with VS2017

Thanks for contributing
I will test on my machine and then pull request will be merged.

@medoni , I've prettified your solution and merge it into a master.
Thanks for your contribution.

authors: medoni verysimplenick

repo: verysimplenick/GoToDnSpy


text:
🛑 WFS INSPIRE CPc is down

In a95cd4b, WFS INSPIRE CPc (https://services.cuzk.cz/wfs/cp/epsg-5514/CP.2235132101) was down:

HTTP code: 0
Response time: 0 ms

Resolved: WFS INSPIRE CPc is back up in d260870 after 11 minutes.

repo: veselyjiri/uptime


text:
feat: add conditional rendering

Render content according to the database_edition in mkdocs.yml.
Added two scripts to process markdown files and the mkdocs.yml separately.
Rules for processing the mkdocs.yml file (here keeping something means hiding it with the exclude plugin, while deleting something means releasing it):

When database_edition is community, keep all content between tags # ent.begin and # ent.end, and delete all content between tags # comm.begin and # comm.end.
When database_edition is enterprise, keep all content between # comm.begin and # comm.end, and delete all content between # ent.begin and # ent.end
When database_edition is both, delete all content between # ent.begin and # ent.end, and between # comm.begin and # comm.end.
Always keep the tags.

Rules for processing the markdown files in the docs-2.0 directory (here deleting something means don't show it, and keeping means show it):

If database_edition is enterprise, the content between {{ ent.ent_begin }} and {{ ent.ent_end }} is kept and the content between {{ comm.comm_begin }} and {{ comm.comm_end }} is removed.
If database_edition is community, the content between {{ comm.comm_begin }} and {{ comm.comm_end }} is kept and the content between {{ ent.ent_begin }} and {{ ent.ent_end }} is removed.
If database_edition is both, both types of content are kept.
Deletes all the tags once the script is run.

The scripts are run in the prepare.sh script before building the docs.
REMEMBER: Write enterprise-only content between {{ ent.ent_begin }} and {{ ent.ent_end }} in markdown files, and community-only content between {{ comm.comm_begin }} and {{ comm.comm_end }}.

You could do more (if you want)
Change the action file. If database_version == all is set, you can run the build process twice to make two separate packages.

repo: vesoft-inc/nebula-docs-cn


text:
Prevent errors from being raised when calling APIs

Summary
This PR prevents errors from being raised when calling Vespa APIs.
It is just one of the possible options for the problems I have encountered.
Context
I'm new to Vespa. I attempted to call the search API, but the following code resulted in the error below.
body = {
    "yql": "select * from sources typo where userQuery()",
    "query": "hello",
    "type": "any",
    "ranking": "random",
    "hits": 10,
}
vespa_app.query(body)

requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: http://localhost:8080/search/

I was struggling with debugging because the error message didn't provide enough details, but I managed to find out that there was a typo in sources typo.
Issue
Reading the code, raise_for_status is called to raise an error when the HTTP status code is not successful.
# vespa/application.py
    def query(
        self,
        body: Optional[Dict] = None,
    ) -> VespaQueryResponse:
        ...
        response = self.http_session.post(self.app.search_end_point, json=body, cert=self.cert)
        response.raise_for_status()
        return VespaQueryResponse(
            json=response.json(), status_code=response.status_code, url=str(response.url)
        )

It seems that this was added in https://github.com/vespa-engine/pyvespa/pull/466 This PR enabled us to receive a forced notification when an error occurred.

# requests/models.py
    def raise_for_status(self):
        """Raises :class:`HTTPError`, if one occurred."""

        http_error_msg = ""
        if isinstance(self.reason, bytes):
            # We attempt to decode utf-8 first because some servers
            # choose to localize their reason strings. If the string
            # isn't utf-8, we fall back to iso-8859-1 for all other
            # encodings. (See PR #3538)
            try:
                reason = self.reason.decode("utf-8")
            except UnicodeDecodeError:
                reason = self.reason.decode("iso-8859-1")
        else:
            reason = self.reason

        if 400 <= self.status_code < 500:
            http_error_msg = (
                f"{self.status_code} Client Error: {reason} for url: {self.url}"
            )

        elif 500 <= self.status_code < 600:
            http_error_msg = (
                f"{self.status_code} Server Error: {reason} for url: {self.url}"
            )

        if http_error_msg:
            raise HTTPError(http_error_msg, response=self)

However, the error doesn't include a message from Vespa. The message that should have been returned was as follows:
{
  'root': {
    'id': 'toplevel',
    'relevance': 1.0,
    'fields': {
      'totalCount': 0
    },
    'errors': [
      {
        'code': 4,
        'summary': 'Invalid query parameter',
        'message': "Could not resolve source ref 'typo'. Valid source refs are amazon_content."
      }
    ]
  }
}

I would be able to identify the cause instantly if I could see the message.
Options
There are several approaches that I think we can resolve this issue.
1. Stop calling raise_for_status
This is the approach I took in this PR. Errors are no longer raised, and it is now the responsibility of the caller to decide how to handle errors by checking the status code.
2. Raise a custom error
If we want to raise an error and include a message from Vespa, it would be better to create a custom error rather than raising HTTPError.
Example of elasticsearch-py
The Bulk API has the raise_on_error param. If True, an error is raised.

This is great feedback! Yes, we added the exception to avoid silent failures (a lot of the examples have little error checking for brevity), but I agree this is quite coarse - I suggest we improve it instead :-) It is much better if the Vespa error message is printed
https://docs.vespa.ai/en/reference/query-api-reference.html#http-status-codes
I suggest we create a little utility function to check for errors, emit a more meaningful error message - and raise a proper error (HTTP or Vespa error)

@kkraune Thank you for your feedback! In fact, I would prefer to raise an error with an appropriate message.
I think we need to consider how to merge the information from different sources:

requests.HTTPError, which contains status_code, reason, and url
vespa.exceptions.VespaError (tentative), which can have multiple errors and each error has its own code (!= status code), summary, and message.

I will create another PR to keep things organized.

Here is the PR: https://github.com/vespa-engine/pyvespa/pull/498 I think they each have their own advantages and disadvantages. In particular, there are differences in error handling as shown below.
Prevent errors from being raised when calling APIs
It's now up to the caller to decide how to handle it. They can either choose to ignore the errors or handle them appropriately.
# In my app
response = vespa_app.query(body)
match response.status_code:
    case 200:
        pass
    case 408:  # Request Timeout
        # We may want to retry
    case 429:  # Too Many Requests
        # We may want to retry later...
    case _:
        # We probably won't be able to recover from the error, raise an error?

Raise a custom error
As API calls can raise errors, they need to be handled on the caller's side by catching them.
# In my app
try:
    response = vespa_app.query(body)
except HTTPError as e:
    # Do we want to something for 408 or 429?
except VespaError as e:
    # Do we want to read the error message to decide how to handle the error?

# or we simply let the error be raised when it occurred.
response = vespa_app.query(body)

The former approach is more flexible, while the latter takes a more error-agnostic approach.

I merged #498 for release today. I supposed we can close this then?

@kkraune Yes, thank you for your review 👍 🍺

Awesome! We appreciate the improvements in usability and error handling, keep the PRs coming :-)

authors: kkraune rejasupotaro

repo: vespa-engine/pyvespa


text:
set vespa version

@tokle please merge - this works, tested from a blank laptop

I've added the same version on all samples.

authors: kkraune tokle

repo: vespa-engine/sample-apps


text:
Support of different languages in vespa

Is there any feature to get same document in different languages?
Here is my use case : If I am in USA then I should get data in english language and if I am in China I should get data in chinese language.
I don't want to feed different documents for different languages.

you mean an auto-translation of document content?

Not auto translation, Just I want to feed store data in different languages but in same document, But If I query I should get data according to my country ie en or ch

I notice you published on https://stackoverflow.com/questions/53648187/support-of-different-languages-in-vespa as well - closing this

repo: vespa-engine/vespa


text:
odgi viz can visualize a subset of the graph, taking a path range in input

This PR introduces a very basic (unmagic) way to take a look at pangenome's regions, without being forced to put the whole graph in the output image.
yeast dataset
odgi stats -i cerevisiae.pan.fa.og -S

#length	nodes	edges	paths
16435869	405965	546636	112

time odgi viz -i cerevisiae.pan.og -o cerevisiae.pan.png

real	0m0,811s

First 50kbps in the pangenome's sequence:
odgi viz -i cerevisiae.pan.fa.og -o cerevisiae.pan.fa.png -r 0-50000
or
odgi viz -i cerevisiae.pan.fa.og -o cerevisiae.pan.fa.png -r *-50000
real	0m0,805s

In the middle:
odgi viz -i cerevisiae.pan.fa.og -o cerevisiae.pan.fa.png -r 7000000-9000000

real	0m0,749s

At the end:
odgi viz -i cerevisiae.pan.fa.og -o cerevisiae.pan.fa.png -r 14000000-*

real	0m0,736s

A closer look at the middle of the yeast pangenome:
odgi viz -i cerevisiae.pan.fa.og -o cerevisiae.pan.fa.png -r 7800000-8300000 -x 3000

Human chr20 dataset
odgi stats -i chr20.pan+refs.fa.pggb-E-s4000-l200000-p98-n7-a0-K16-k27.seqwish-w500000-j12000-e12000-I0.6.smooth.og -S
#length	nodes	edges	paths
397630652	6520936	11209105	55655

On the left:
odgi viz -i chr20.pan+refs.fa.pggb-E-s4000-l200000-p98-n7-a0-K16-k27.seqwish-w500000-j12000-e12000-I0.6.smooth.og -o x.all.png -p original_paths.txt

On the right:
time /home/andrea/odgi/bin/odgi viz -i chr20.pan+refs.fa.pggb-E-s4000-l200000-p98-n7-a0-K16-k27.seqwish-w500000-j12000-e12000-I0.6.smooth.og -o x.png -p original_paths.txt -r 199907663-200000000

Now odgi viz can take in input also a nucleotide path range.
Centromeric region of the Human chr20 pangenome (grch38#chr20:25634924-30560593)
odgi viz -i chr20.pan+refs.fa.pggb-E-s4000-l200000-p98-n7-a0-K16-k27.seqwish-w500000-j12000-e12000-I0.6.smooth.og -o centromeric_region.png -p original_paths.txt -r grch38#chr20:25634924-30560593

Nice.
With a better sort like a pure path guided one you'd probably be able to slice out just the centromere this way.

:fire:

After a (maybe too) heavy run of path-guided sorting:
odgi sort -i chr20.pan+refs.fa.pggb-E-s4000-l200000-p98-n7-a0-K16-k27.seqwish-w500000-j12000-e12000-I0.6.smooth.og -o chr20.pan+refs.fa.pggb-E-s4000-l200000-p98-n7-a0-K16-k27.seqwish-w500000-j12000-e12000-I0.6.smooth.Y.G20.x100.og -t 20 -Y -G 20 -x 100 -I 5000 -l 5000

odgi viz -i chr20.pan+refs.fa.pggb-E-s4000-l200000-p98-n7-a0-K16-k27.seqwish-w500000-j12000-e12000-I0.6.smooth.og -o centromeric_region.png -p original_paths.txt -r grch38#chr20:25634924-30560593

authors: AndreaGuarracino ekg subwaystation

repo: vgteam/odgi


text:
Fix #13 by inlining base 64 image for secret user

So the whole fa-* doesn't have to be downloaded.
This is retina ready, the generated base64 is 24px wide and the width attribute is only 12px

Should be good. Apologize again

@RomainSauvaire no need to apologize, typos happen 😄

Just to let you know, I've still got this on my to-do list! Super hectic at work. I'll look ASAP, I promise!

authors: RomainSauvaire krve mrterryh

repo: viacreative/sudo-su


text:
🛑 OAplus - Developers is down

In 949db47, OAplus - Developers (https://developers-oaplus.line.biz/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: OAplus - Developers is back up in 7bfd108 after 4 minutes.

repo: vichaos/upptime


text:
research authentication in React and Express

As a [role]
I need [function]
So that [benefit]
Details and Assumptions
* [document what you know]

Acceptance Criteria
gherkin
Given [some context]
When [certain action is taken]
Then [the outcome of action is observed]

research authentication in React and Express issues


text:
Login not validating username properly

Login page is considering every entry in input fields.
The validation error only appear when ou try to submit the form without any values.
The bug in, probably, in controllers/Login.php between lines 31 and 49.

This issue is happening due to and else statement problem in controllers/Login.php
the else is in line 43
it is necessay to remove the login feature from this else

In observation, it seem to not call the model fuction that validates form entry

Fixed issue with the code below /
$this->db->select('login');
$this->db->from('usuario');
$this->db->where("login", $this->input->post('username'));
$this->db->where("password", $this->input->post('password'));
$query = $this->db->get();
if($query->num_rows()==1){
return true;
}else
{
return false;
}
using this as Usuarios_model, it works.

repo: victoradmc/storeCore


text:
Rc 0.0.5

Description
Finish 0.0.5 release
Type of change
Please delete options that are not relevant.

This change requires a documentation update

How Has This Been Tested?
Ran CI tests
Test Configuration:

Operating system: GHA
Version number: Python 3.9-11
Any details about your local setup that are relevant

Checklist:

[x] Make sure you are merging into the develop (not main) branch
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] Add a note to CHANGELOG.md, summarizing the changes
[x] Update zenodo.json file for new code contributors

@victoriyaforsythe go ahead and merge this in, then delete the branch.

authors: aburrell victoriyaforsythe

repo: victoriyaforsythe/PyIRTAM


text:
Project Inicialization

Set up the initial project Kanban in GitHub.

[ ] Create the project on GitHub.
[ ] Edit Labels
[ ] Edit Milestones
[ ] Edit Size
[ ] Create the issues for the project.
[ ] Assign the issues to the repository.
[ ] Assign the issues to different milestones.


text:
Pick return array

Pick returns an array when count argument is passed.
https://github.com/victorquinn/chancejs/issues/205
Some error checking borrowed from
https://github.com/victorquinn/chancejs/pull/174

Why is this PR closed?

I see this is replaced by pickone() and pickset().

authors: leesei theusualcoder

repo: victorquinn/chancejs


text:
Too many failing dependencies on VenusOS

Super pleased development is taking place but unable to make it work. On the latest standard VenusOS (2.94) I have cloned the module and submodules only to start the journey of installing dependencies:

change root filesystem to writeable
install opkg / pip
install websockets

After that, all stopped. Installing secrets failed on the freshly installed dataclasses. To be more precise, the python-ldap dependency for secrets failed. Using make also fails as the required variables are not set.
As this concerns a fresh load of the latest VenosOS I was kind of hoping you can either elaborate a little in the readme or script the install in such a way that non-guru's can make it work on a Cerbo GX. To be able to use a shelly as a grid meter is a truly great feature!

Hi, i have been there, i know the problem with python-ldap, but please be assured, that you are on the wrong path.. I wrote a litte "documentation" on how to "resolve" the dependencies. Please have a look here:
https://github.com/victronenergy/dbus-shelly/issues/2#issuecomment-1371472831
Please replace the first step (cloning the repo) with the following:
git submodule update --init
this makes the step with pulling the aiovelib (referenced git repo) obsolete. Reference: https://github.com/victronenergy/dbus-shelly/issues/2#issuecomment-1463956415

Many thanks. I did clone the module and submodules so that was never the issue. It's probably the copy or link action of the py files after installing the packages that's the issue. Very grateful.
But I would still love to see something that survives a firmware update like the shelly integration I'm using now.

My advice is simply to stop hurting yourself and install a Venus 3.00 beta. It has everything you need. Closing this.

authors: Kudos50 izak stenub

repo: victronenergy/dbus-shelly


text:
What is the roadmap?

We need some kind of roadmap document to guide contribution.

[ ] What is the roadmap? (add to project README)
[ ] Add roadmap reference to site
[ ] Add roadmap reference to CONTRIBUTING.md

I laid out some thoughts here:
https://github.com/vigetlabs/microcosm/issues/281

authors: leobauza nhunzaker

repo: vigetlabs/microcosm


text:
Implement Shaders and Buffers.

Restructures graphics a bit to make sense of the flow of code.

Tests should fail. Will get them fixed in the next PR that restructures the project folders as discussed previously.

repo: vignetteapp/sekai


text:
Can this addon be updated to the latest version of simpleicons?

This addon is now very far behind on the latest icons.
https://github.com/simple-icons/simple-icons/releases/tag/11.13.0
@adamrusted offered help in this issue post.

If you're in need of any support in implementing one of the above - please feel free to start a discussion or ask us on Discord.

https://github.com/vigonotion/hass-simpleicons/issues/250

Yes, please update!

The integration depends on the simpleicons python package which hasn't been updated. That package would need continuous updates or I have to use another library but I haven't found one that's maintained.
If a library(-update) is available, I can update the integration

Following the suggestion  of @Kilill I've created https://github.com/vigonotion/hass-simpleicons/pull/259
Works successfully on my setup

authors: QuickSwitchLK RK62 dgomes vigonotion

repo: vigonotion/hass-simpleicons


text:
Todo List using React

Todo List using React

don't forget to add a star to this repo


text:
Is there a version of pr2 xml with actuators?

Is there a version of pr2.xml with the actuators defined? I am trying to use mujoco to simulate joint position control for PR2, but I noticed that there are no actuators defined in the pr2.xml file. So, currently the only way I can control is using force control on the joints.

Hi, I was wondering about the same thing. Did you ever find a file with actuator or added by yourself? I am not sure while adding by myself what limits should I put on the joint rotations.


text:
Update +Page.mdx: Optional SSR

Update NextJS from 'No' to 'Limited' with references to the relevant issues.

I think we'd do well to make the table as accurate as possible. Otherwise, when people discover that a 'No' doesn't actually mean it's not possible (which you'd assume from a 'No'), but that more or less common workarounds exist, then the credibility of the table (and other claims) as a whole would suffer.
Besides, my impression is that actually seeing the intricacies of the workarounds is a pretty good argument for Vike in themselves.
I think providing a few footnote-ish links strikes a good balance between backing the claims made and being succinct. It was the most succinct I could get it, while still achieving the goal of being helpful.

Ok makes sense 👍

repo: vikejs/vike


text:
new version without Google Play Services

Does this new version(2.x.x) work on devices without google play services?

No it does not unfortunately

yeah, most devices in China do not shipped with google play services.

Right, that's unfortuntate. Our app is initially only targeting Europe though so for me it made more sense to use the Play Services version. The 1.2.x version was still working though. And I could patch it and release bug fixes if PR's come in targeting that branch.

thanks~ @vikeri

authors: cbjs vikeri

repo: vikeri/react-native-background-job


text:
The window should be initialized with the current size.

The window should be initialized with the current size, in the Windows version.
return SetSize(m_saveInfo.dwMaximumWindowSize.X, m_saveInfo.dwMaximumWindowSize.Y);
==>
return SetSize(m_saveInfo.srWindow.Right + 1, m_saveInfo.srWindow.Bottom + 1);

Ok, let me think.

authors: cmcpp vikonix

repo: vikonix/multitextor


text:
NaI implementation and ROOT output

New files:
k100_ROOTOut.* : Produces output file in ROOT tree formatk100_NaIParametrization.* : for NaI array detector placement
k100_nrCascadeTree.* : Reads inputs from nrCascadeSim file
k100_SteppingAction.* : Does nothing at the moment but can be used for debugging
spandey_nCap.mac : Macro for PuBe source (placed outside the shielding) with NaIArray
spandey_nCap_cylinder_source.mac : Macro for thermal neutron source in the silicon crystal
neutron_capture.dat : energy spectrum for thermal neutrons
Changes:
k100Sim.cc : Updated to accept nrCascadeSim file name as input argument (if required)
k100_PrimaryGeneratorAction.* : Added code snippet to read nrCascadeSim file and generate corresponding photons
k100_DetectorConstruction.* : Implement NaI array
k100_DetectorConstructionMessenger.* : Activate/deactivate NaI array using macro command (/CDMS/detector/activate NaIArray)
k100_DataStorage.* : Store output in ROOT tree format
k100_ZipSD.* : Using this code base to include NaI simHits in the output collection
CMakeLists.txt : Extended cmake version dependence to run on cdms2 machine

This is great, let's make the target branch develop though--this way we can test and then release a new version number.

Also, open up an issue detailing the enhancements requested--that this PR will solve.

I have changed the base branch to "dev". Does it look okay now? If yes, then I will create an issue documenting the enhancements.

As mentioned in meeting: before merging this we have to restore the text file output @spandeyehep let me know when that's done.

I have added a flag (-t) in the code to switch from root output format to text format.
./k00sim <macro.mac> : produces ROOT file.
./k00sim -t <macro.mac>: produces text file.
@villaa

@spandeyehep good update! I would like the text file to be the default behavior so that it is compatible with previous runs. So please change it so that the -R flag (or similar) writes to a root file instead.

Hi @villaa . Done!!
I have removed -t flag, and added -r flag. The behavior is now swapped.
./k00sim <macro.mac> : produces text file.
./k00sim -r <macro.mac>: produces ROOT file.

@spandeyehep I did a review of the code changes and there are some things I don't understand; you should be able to see the comments.
The key thing I don't understand is in PrimaryGeneratorAction--it seems to me that it only allows running where nrCascadeTree is supplied, but what about just the PuBe source with gammas?

@villaa where can I find the comments? I don't see it.
The code requires nrCascadeTree file only when -cutomgen flag is supplied [1]-[2] , otherwise the behavior is default, i.e. use source provided in macro as input and do PuBe gammas if it has been set to True as macro-command [3].
[1] https://github.com/spandeyehep/k100Sim-1/blob/k100sim_NaIArray/k100Sim.cc#L197-L200
[2] https://github.com/spandeyehep/k100Sim-1/blob/k100sim_NaIArray/src/k100_PrimaryGeneratorAction.cc#L103-L158
[3] https://github.com/spandeyehep/k100Sim-1/blob/k100sim_NaIArray/src/k100_PrimaryGeneratorAction.cc#L159-L231

@villaa where can I find the comments? I don't see it.
The code requires nrCascadeTree file only when -cutomgen flag is supplied [1]-[2] , otherwise the behavior is default, i.e. use source provided in macro as input and do PuBe gammas if it has been set to True as macro-command [3].
[1] https://github.com/spandeyehep/k100Sim-1/blob/k100sim_NaIArray/k100Sim.cc#L197-L200 [2] https://github.com/spandeyehep/k100Sim-1/blob/k100sim_NaIArray/src/k100_PrimaryGeneratorAction.cc#L103-L158 [3] https://github.com/spandeyehep/k100Sim-1/blob/k100sim_NaIArray/src/k100_PrimaryGeneratorAction.cc#L159-L231

So, sourceGun==True means we are using a capture file?

@spandeyehep I think I see now--what was confusing me is that I had the sourceGun variable before; but it did something useless: threw isotropic 8 MeV neutron. So you just removed that functionality and made it the nrCascadeTree input.
That's fine, but I might suggest changing the name of sourceGun and useGun to something more obvious, like throwCaptures or something...

@villaa Sure, I will update the flag name to make it less confusing.
I will probably push the changes once I have also implemented and validated boron shield. Let me know if that sounds good to you.

Hi @villaa , unfortunately I couldn't get much time to work on boron shield. I hope to implement that in a couple of days.
I agree with your recommendation. You can go ahead and merge the PR. I will open another request once boron shield is implemented.

Hi @villaa , unfortunately I couldn't get much time to work on boron shield. I hope to implement that in a couple of days. I agree with your recommendation. You can go ahead and merge the PR. I will open another request once boron shield is implemented.

@spandeyehep did you update the names of sourceGun and useGun as per above? That I would like to do before merging this PR.

@villaa I have updated the variable names sourceGun and useGun to throwCaptures and useCapture, resp.

authors: spandeyehep villaa


text:
🛑 Booking is down

In b1d8a83, Booking ($SITE_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Booking is back up in 5856c46 after 7 minutes.

repo: villekulla-nma/monitor-booking


text:
Error on call denops_shared_server#install()

Error on call denops_shared_server#install()
function denops_shared_server#install の処理中にエラーが検出されました:
行    6:
E117: 未知の関数です: denops#util#script_path
行   15:
E121: Undefined variable: options
E116: 関数の無効な引数です: denops_shared_server#launchctl#install
行   22:
E117: 未知の関数です: denops#util#info

Those functions are removed from v4.0.0 due to deprecation (https://github.com/vim-denops/denops.vim/pull/207) so denops-shared-server.vim must be fixed to support v4.0.0

Fixed by https://github.com/vim-denops/denops-shared-server.vim/pull/10

authors: lambdalisue yukimemi


text:
Vim Magazine 2017 年 6 月号

Vim Magazine 2017 年 6 月号のPRです。
2017/06/30 に以下を実施して、パッチなどの情報を追加 commit してからマージしてください。
2017/06/30 は金曜日(プレミアムフライデー)です。作業忘れに気をつけてください。
ruby scripts/vimmagazinetools.rb generate --update scripts/vimmagazinestate.json >> _posts/vimmagazine/2017-06-30-vimmagazine.md

作業時の注意点
今月の新機能 のフォーマット
今月の新機能 は以下のフォーマットに従う。
*   {パッチ番号}: {新機能についての簡潔な説明。可能な限り一文であることが好ましい}

各新機能のパッチについて特に重要な関連パッチが存在する場合、末尾に以下のように追加する。
*   {パッチ番号}: {新機能についての簡潔な説明} (関連パッチ: {パッチ番号1}, {パッチ番号2})

その他のルール

{パッチ番号} は 8.0.0999 のように完全な記述とする(暫定)
英数字と日本語の境界にはスペースを開ける(github-pagesのmarkdown engineの不具合を避けるため)
オプションや関数は原則として `` で囲む

以上はあくまでも基本形であり、必要であれば例外を許容する。

その他、資料
資料

先月: 2017/05 号のPR

日本語と英語の間にスペースを空けるためのコマンド
%s/[!-',0-~]\zs\ze[^ -~]\|[^ -~]\zs\ze[!-',0-~]/ /g

Circle CI 上でプレビューするためのURL
https://circleci.com/api/v1/project/vim-jp/vim-jp.github.io/{BUILD_NUMBER}/artifacts/0/$CIRCLE_ARTIFACTS/vimmagazine/2017/06/30/vimmagazine.html

このURL簡単に生成する方法はないだろうか?

今月の新機能

Patch 8.0.0630: range が1行の時に限り :g[lobal] コマンドがネスト可能になりました。

今月の新機能

Patch 8.0.0634: getqflist() と setqflist() の引数 "nr" に最後の quickfix list を取得する "$" を指定できるようになりました。

今月の新機能

Patch 8.0.0641: quickfix window で選択された行のハイライトグループ QuickFixLine が追加されました。

注：コミットメッセージでは "Cannot set a separate highlighting for the current line in the
quickfix window." となっていますが、current line ではなく（quickfix window で <CR> を押して）選択された行です。
関連：https://github.com/vim/vim/commit/2102035488e80ef6fd5038ed15d21672712ba0f6 , https://github.com/vim/vim/pull/1755

見逃してました。 http://qiita.com/h_east/items/81b1cda85899b2bf2c35

Patch 8.0.0613: :setfiletypeにFALLBACK引数を追加しました。

あとこれも確かに新機能ですね。

runtimeファイル更新: 各ファイルタイプindent設定ファイルで&swの代わりにshiftwidth()を使用するようにしました。

今月の新機能

Patch 8.0.0652: Unicode 10 がサポートされました。

今月の新機能

Patch 8.0.0655: :delf[unction] コマンドが ! に対応しました（存在しない関数を指定してもエラーが出なくなります）。
Patch 8.0.0657: getqflist() と setqflist() の引数に items が指定できるようになりました。
Patch 8.0.0661:（urxvt のマウス用エスケープシーケンス？）Esc[*M と Esc[*m を認識するようになりました。

今から編集作業を始めます～

取り急ぎリンクだけペタリ

Meguro.vim #4
https://megurovim.connpass.com/event/57955/
Fablic.vim #2
https://fablicvim.connpass.com/event/60339/

今月の新機能

Patch 8.0.0689: 検索時、CTRL-L でコマンドラインにテキストを挿入する時、~ が自動的にエスケープされるようになりました。

https://github.com/vim/vim/commit/3e54569b17683318e0cb6693ab0024c2ad1e3e8f#diff-44a099e40ae628aef90a28c6408a4c61R2804

この setf FALLBACK ってなんだろ?

packages に含まれる ftdetect が動かなかったのを、8.0.0613 で直した時に追加された引数ですね。

以下のように追加する予定です。

8.0.0613: :setfiletype コマンドに FALLBACK オプションが追加されました。これはファイルタイプの推測のために使用され、具体的には did_filetype() が true ではなく false を返します。

とりあえず 0628 までの新機能をチェックした。

一般ユーザーにとっては、FALLBACKオプションが追加されたということより、パッケージでftdetectが使えるようになったことの方が重要ではないでしょうか。

@k-takata ありがとうございます。それいただきます。

8.0.0613: パッケージで ftdetect が使えるようになりました

@tyru

あとこれも確かに新機能ですね。

runtimeファイル更新: 各ファイルタイプindent設定ファイルで&swの代わりにshiftwidth()を使用するようにしました。

これはユーザー的には気にしなくて良い度合いが強いってことで落とします。

ユーザー的には、'shiftwidth' に 0 を設定してもすべてのindentファイルが問題なく使えるようになったという点がポイントだと思います。

0664 までチェック済み。

以上 0691 までチェックおわりました。ひとまずこれで新機能のチェックは〆ます。
あとはスクリプト実行して、ちょっと寝かせますのでその間にご意見があればお願いします。

マージしました～

今月も編集にご協力をいただきありがとうございました。
来月 もよろしくお願いいたします 🙇

Osaka.vim もあったらしいです。
https://anond.hatelabo.jp/20170701171103

追加しておきました。 e0f6a380fab2d6de1a2ae345d16fb891bcefc0b7

すみません、ありがとうございます。
（ちょっと時間が取れず…今度からできるだけ自分で追加します）

👍

authors: k-takata koron thinca tyru


text:
There is always show "Vdebug is not running" when I quit vim

I just upgrade my Vdebug to master branch and without any configurations. When I quit vim, it always shows "Vdebug is not running" message, can I get rid of it?
Weird, this message never shows ii Vdebug v1.
I tried Vdebug master branch inside macvim/neovim, all of them have this issue.

This ca be removed but its not really a bug. The output is given because if you close vim we must make sure everything is shut down.

Ah, I see. Thanks. Since it is not a bug, the message is okay for me, just a little annoying.

I'll check if this could be handled more properly

Weird, this issue seems come back again. After recent update, I see Vdebug is not running again on vim exit.

authors: BlackIkeEagle markwu

repo: vim-vdebug/vdebug


text:
Test_fuzzy_completion_bufname fails if the working directory contains the substring "SF"

Steps to reproduce
Run testsuite when working directory contains SF as a substring.
Debian's builds run in a temporary directory, so the path has randomly generated strings.  One of those builds happened to have "SF" in the directory name, and thus failed test_cmdline.vim's Test_fuzzy_completion_bufname test.
Expected behaviour
Test suite passes.
Version of Vim
9.0.0135
Environment
Debian
Logs and stack traces
Failures:
	From test_cmdline.vim:
	Found errors in Test_fuzzy_completion_bufname():
	command line..script /<<PKGBUILDDIR>>/src/vim-gtk3/testdir/runtest.vim[468]..function RunTheTest[44]..Test_fuzzy_completion_bufname line 5: Expected '"b SF' but got '"b /build/vim-RSFt5j/vim-9.0.0135/src/vim-gtk3/testdir/SomeFile.txt'

Steps to reproduce
Run testsuite when working directory contains SF as a substring.
Expected behaviour
Test suite passes.
Version of Vim
9.0.0135
Environment
Debian
Logs and stack traces
Debian's builds run in a temporary directory, so the path has randomly
generated strings.  One of those builds happened to have "SF" in the
directory name, and thus failed test_cmdline.vim's
Test_fuzzy_completion_bufname test:

Failures:
	From test_cmdline.vim:
	Found errors in Test_fuzzy_completion_bufname():
	command line..script /<<PKGBUILDDIR>>/src/vim-gtk3/testdir/runtest.vim[468]..function RunTheTest[44]..Test_fuzzy_completion_bufname line 5: Expected '"b SF' but got '"b /build/vim-RSFt5j/vim-9.0.0135/src/vim-gtk3/testdir/SomeFile.txt'

Hmm, I think the simplest solution is to use a long file name.  Then the
match will almost never happen.
--
hundred-and-one symptoms of being an internet addict:
249. You've forgotten what the outside looks like.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

authors: brammool jamessan

repo: vim/vim

license: Vim


text:
[vim9] Type mismatch and numerical errors

Steps to reproduce
Source the following script:
vim9script

def Scan(rel: list<dict<any>>): func(func(dict<any>))
  return (Emit: func(dict<any>)) => {
    for t in rel
      Emit(t)
    endfor
  }
enddef

def Sum(Cont: func(func(dict<any>)), attr: string): any
  var sum = 0.0
  Cont((t: dict<any>) => {
    sum += t[attr]
  })
  return sum
enddef

const r = [{A: 3}, {A: 2}, {A: 7}]

echo Scan(r)->Sum('A')

This results in:
E1012: Type mismatch; expected float but got number

Besides, if I change the argument type of the lambda from dict<any> to dict<float> (second line of Sum's body), instead of an error I get this result:
5.928788e-323

If the values of r are changed to float, e.g.:
const r = [{A: 3.0}, {A: 2.0}, {A: 7.0}]

then the result (12.0) is computed correctly, even with the weaker typing  of the lambda.
Expected behaviour
The result should always be 12.0.
Version of Vim
9.0.1103
Environment
macOS 13.1
Apple Terminal
xterm-256color
ZSH 5.8.1
Logs and stack traces
No response

This is a simplified script that reproduces the type mismatch error:
vim9script

def Sum(v: any): float
  var sum = 0.0
  sum += <float>v
  return sum
enddef

const kk = 1

echo Sum(kk)

I am wondering whether my assumptions on how Vim 9 script is supposed to deal with casting from integer to float are correct. My expectation is that a value of type number can always be cast into a value of type float.

This is a simplified script that reproduces the type mismatch error:
vim9script

def Sum(v: any): float
  var sum = 0.0
  sum += <float>v
  return sum
enddef

const kk = 1

echo Sum(kk)

I am wondering whether my assumptions on how Vim 9 script is supposed
to deal with casting from integer to float are correct. My expectation
is that a value of type number can always be cast into a value of
type float.

A type cast changes the type but not the value.  This is mentioned in
the help at ":help type-casting".
In this example it actually does the opposite of what you wanted.  But
there also is a bug.
This should work:
var sum = 0.0
sum += v
Adding a number to a float works. And it does if we know the type at
compile time.  But in this case the type is "any" and we need a runtime
type check.  That one was checking for float.  I'll make a fix for that.
Adding the "" type check will make it fail, since a number is
passed and the type is explicitly checked to be a float.  This may be a
bit unexpected, and I had been wondering whether we should actually
change the value, turning the number into a float.  Quite a few
languages do it this way.  On the other hand, it's been like this for
almost a year now, and this appears to be the first time a problem is
encountered.  So it might be better just to leave it as it is.
--
Sorry, no fortune today.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Adding the <float> type check will make it fail, since a number is passed and the type is explicitly checked to be a float.

Thanks for the explanation! I should have paid more attention to the help file.
Back on topic: I confirm that the type mismatch error is fixed (thanks!), but the following code, which is a slight simplification of the code I originally posted, still gives some unexpected results:
vim9script

def Scan(ll: list<any>): func(func(any))
  return (Emit: func(any)) => {
    for e in ll
      Emit(e)
    endfor
  }
enddef

def Sum(Cont: func(func(any))): any
  var sum = 0.0
  Cont((v: float) => {  # <== NOTE: the lambda expects a float
    sum += v
  })
  return sum
enddef

const x = [3, 2, 7]
const y = [3.0, 2, 7]
const w = [3.0, 2.0, 7]

echo Scan(x)->Sum()  # 5.928788e-323
echo Scan(y)->Sum()  # 3.0
echo Scan(w)->Sum()  # 5.0

It seems as if the values of type number are silently ignored. The code computes the correct sum if the type of the lambda's argument is relaxed to any.
For comparison, the “straightforward” version of the code above raises an error:
def Sum(l: list<float>): float
   var sum = 0.0
   for v in l
     sum += v
   endfor
   return sum
 enddef

const x = [3, 2, 7]

echo Sum(x)  # Error: passing list of numbers to a function expecting list of floats

Probably, also the code above should produce a similar error.

Adding the <float> type check will make it fail, since a number is
passed and the type is explicitly checked to be a float.

Thanks for the explanation! I should have paid more attention to the help file.
Back on topic: I confirm that the type mismatch error is fixed
(thanks!), but the following code, which is a slight simplification of
the code I originally posted, still gives some unexpected results:
vim9script

def Scan(ll: list<any>): func(func(any))
  return (Emit: func(any)) => {
    for e in ll
      Emit(e)
    endfor
  }
enddef

def Sum(Cont: func(func(any))): any
  var sum = 0.0
  Cont((v: float) => {  # <== NOTE: the lambda expects a float
    sum += v
  })
  return sum
enddef

const x = [3, 2, 7]
const y = [3.0, 2, 7]
const w = [3.0, 2.0, 7]

echo Scan(x)->Sum()  # 5.928788e-323
echo Scan(y)->Sum()  # 3.0
echo Scan(w)->Sum()  # 5.0

It seems as if the values of type number are silently ignored. The
code computes the correct sum if the type of the lambda's argument is
relaxed to any.
For comparison, the “straightforward” version of the code above raises
an error:
def Sum(l: list<float>): float
   var sum = 0.0
   for v in l
     sum += v
   endfor
   return sum
 enddef

const x = [3, 2, 7]

echo Sum(x)  # Error: passing list of numbers to a function expecting list of floats

Probably, also the code above should produce a similar error.

Hmm, a bit complicated.  The code currently assumes the argument types
are checked at compile time, but since the type is defined as "any" and
the function being called expects a float, a runtime type check is
required.
The easiest is to do the runtime type check always.  I'll make a patch
for that.  It adds some overhead, but it avoids bad computations, or
perhaps even a crash (e.g. when a string is expected but a number is
passed).
--
A parent can be arrested if his child cannot hold back a burp during a church
service.
[real standing law in Nebraska, United States of America]
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

authors: brammool lifepillar