尧图网站建设 
数据可视化前端【免费下载链接】visdomTool for real-time visualization, monitoring and collaborative analysis of AI/ML experiments and live data. Supports Python, PyTorch/Torch, NumPy, TensorFlow/Keras https://visdom.dev项目地址https://gitcode.com/gh_mirrors/vi/visdom点击查看免费下载Visdom 是一款面向 AI/ML 实验的可视化工具它由 Python/Tornado 后端、React 前端与 Lua/Python 双客户端组成。本文以仓库根目录的 CONTRIBUTING.md 为骨架完整讲解如何排查常见使用问题、如何报告 Bug、如何提交 Pull Request并深入 Pythonpytest与前端Playwright两套测试体系的架构与实战用法。读完本文你将掌握一条从遇到问题到提交被合入的代码的完整贡献路径并能在当前仓库源码中定位到每一步对应的实现文件。一、先学会排障用 Issue 清单理解 Visdom 的运行机制贡献者最常见的起点不是写代码而是先理解问题。CONTRIBUTING.md 把高频问题整理成了一张排障清单同时也揭示了 Visdom 的核心运行架构Python 客户端负责构造数据 → 经 WebSocket 发送给 Tornado 服务器 → 服务器将 JSON 结构交给前端 Plotly 渲染。1.1 无法连接 Visdom 服务器这是最高频的问题。排查链路如下确认服务器是否在运行通过python -m visdom.server启动然后尝试重启。该命令对应的实现入口在 py/visdom/server/main.py它会调用 run_server.py 中的启动逻辑。确认网络未被阻断防火墙可能拦截了浏览器与服务器之间的流量此时可通过服务器启动参数-proxy指定代理也可以在本地~/.ssh/config中为远程服务器配置 SSH 隧道转发LocalForward 127.0.0.1:8097 127.0.0.1:8097确认端口未被占用部分用户反馈执行sudo ufw allow 8097可以放行被防火墙拦截的 8097 端口。值得注意的是Visdom 的默认端口 8097 同样体现在测试基建中例如 playwright.config.js 的 webServer 配置使用visdom -port 8098 -env_path /tmp启动独立实例而 py/tests/conftest.py 中appfixture 默认构造Application(port8097, ...)。1.2 浏览器出现蓝屏但看不到可视化内容蓝屏通常意味着前端 JavaScript 依赖没有加载成功这在部分网络环境下是常见问题。排查方式在 Chrome 中点击View → Developer → JavaScript Console检查是否存在与缺失 JS 依赖相关的报错。若确认依赖缺失进入已安装的visdom包目录例如/home/$USERNAME/$ANACONDA_FOLDER/lib/python$PYTHON_VERSION/site-packages/visdom-$VISDOM_VERSION-py$PYTHON_VERSION.egg路径变量取决于你的安装方式从源码安装时目录可能不同。查看仓库根目录的 download.sh 脚本——它会下载 Plotly、MathJax、SJCL 等前端资源到py/static/js与py/static/css等目录你可以直接执行该脚本或按脚本内容手动下载全部资源。重启 Visdom 服务器再次打开 JavaScript Console 确认依赖已全部就位。从源码结构看download.sh 下载的plotly.min.js、mathjax-tex-mml-svg.js等资源正是前端渲染与公式显示所依赖的运行时库最终会被 setup.py 通过package_data{visdom: [static/*.*, static/**/*, ...]}打包进发行版。1.3 想要一个现有 API 之外的绘图特性Visdom 的可视化能力建立在 Plotly 之上客户端代码先构造一个 JSON 结构再由服务器把该结构交给 Plotly 渲染。这意味着只要输入正确Visdom 就能展示 Plotly 支持的任何可视化——但 Visdom 只暴露了其中最常见的部分。如果你需要某个未暴露的特性官方态度是欢迎直接动手改造客户端修改产生数据结构的客户端代码位置在 py/visdom/init.py每种绘图类型的全部可用选项可以参考 Plotly 官方手册Python 版甚至可以从零构造自己的绘图数据结构然后直接调用_send方法把它发送给 Visdom 服务器。_send的当前实现位于 py/visdom/init.py签名形如def _send(self, msg, endpointevents, quietFalse, from_logFalse, ...):它是客户端与服务器之间所有消息默认走events端点的统一出口理解它有助于定位数据是如何从 Python 到达前端的完整链路。1.4 想使用 pip 版本尚未包含的新特性最新的特性往往只在源码仓库中。从源码安装的方式# 先卸载已安装版本再以可编辑模式安装 pip uninstall visdom pip install -e .本地开发注意事项执行python -m visdom.server时Python 可能仍会导入site-packages里旧版本的visdom包而不是你 checkout 出来的源码。此时会出现前端编译成功、main.js已更新、服务器正常重启、但 UI 仍旧是老行为的迷惑现象。验证当前实际加载的源码python -c import visdom; print(visdom.__file__)输出路径应指向你的本地仓库而非site-packages。若需要手动优先本地源码export PYTHONPATH$PWD/py:$PYTHONPATH部分 pip 安装场景下可编辑安装无法正确链接模块此时可退而使用python setup.py install。关于 Python 版本约束setup.py 中python_requires3.12明确写明了当前仓库要求 Python 3.12 及以上。二、如何提交一份高质量 Bug 报告找到问题后一份可复现的报告能极大加速定位。CONTRIBUTING.md 要求 Bug 报告中必须包含以下三要素Visdom 服务器输出的错误信息直接从终端复制粘贴JavaScript Console 输出的错误信息如有在 Chrome 中通过View → Developer → JavaScript Console查看并粘贴警告或错误运行平台信息操作系统、浏览器、Visdom 版本。在提交前请先翻阅 Issue 列表确认是否已有相同问题及解决方案同时请理解Visdom 是维护者业余时间维护的项目没有专职工程师请求无法全部即时响应。三、贡献者行为准则首次贡献者与 AI 辅助编码仓库对贡献者提出了两条明确的软性规范首次贡献者建议从入门级 issue 开始避免一开始就接手涉及大规模文件改动或重大代码重构的任务保持初始贡献聚焦、范围可控便于熟悉代码库并通过评审。AI 辅助编码欢迎使用 AI 工具协助编写、调试或理解代码但只有在你完全理解改动作用、并能逐行解释每一处改动时才应提交 PR。盲目复制粘贴无法解释、无法调试的 AI 生成代码是不被允许的——贡献者对自己提交代码的正确性与可维护性负全责。四、Pull Request 流程全解仓库积极欢迎 PR提交前请逐条核对以下清单Fork 仓库并从dev分支创建你的工作分支新增代码必须有对应测试Python 测试规范见下一节若改动了 API同步更新文档确保 Lua 与 Python 两套接口保持同步——仓库中 th/Lua 侧与 py/visdom/Python 侧共同面向同一套服务器协议这是 Visdom 双客户端架构的特殊要求若改动js/目录需提交 React 编译后的main.js详见UI 贡献一节GitHub Action Update Static JS Files 会在你创建分支后自动构建并提交main.js与main.js.map为新特性添加 demo见仓库 example/ 目录并确保 demo 可运行保证代码通过 lintJavaScriptnpm lintPythonblack py安装pip install black23.1可在每次git commit前自动执行pre-commit install若尚未签署完成 Contributor License AgreementCLA。五、Python 测试体系py/tests 的架构与用法Visdom 的 Python 测试套件使用 pytest 下。其设计宗旨是封闭hermetic不需要运行真实的 Visdom 服务器也没有任何测试触碰网络。由于 Visdom 要求 Python 3.12测试也应运行在 3.12 及以上环境。5.1 运行测试pip install -e . # 安装 visdom pip install -r test-requirements.txt # 安装 pytest 及测试依赖 pytest # 运行整套测试 pytest -m not server # CI 实际运行的命令排除需要外部服务器的用例测试发现规则配置在 pyproject.toml 中testpaths [py/tests]限定只收集py/tests下的用例仓库根目录的零散test_*.py脚本会被忽略因此从仓库任意位置执行pytest都能自动发现套件无需传入路径。开发期间的常用收窄方式pytest py/tests/unit # 快速子集无 HTTP纯逻辑 pytest py/tests/unit/window_builder.py # 单个文件 pytest -k window_builder # 按名称匹配 pytest -x --lf # 首个失败即停随后只重跑失败项unit、integration、slow、server四个 marker 均在 pyproject.toml 中注册可用-m选择addopts -ra -q已默认开启-q再传-q会隐藏汇总行如需 pytest 完整默认输出可加-o addopts。5.2 测试目录结构与新增测试的规范目录结构如下py/tests/ conftest.py # 共享 fixtures自动加载 testutils/ # 可导入的辅助代码——永远不会被当作测试收集 unit/ # 纯逻辑不构造 Application除 tmp_path 外无 I/O integration/ # 进程内 Application、真实 HTTP 或 handler 分发新增测试时的三条硬性规范文件放哪、叫什么按依赖选择unit/或integration/文件命名用unit/window_builder.py而非unit/test_window_builder.py目录名已经说明是测试但测试函数仍必须以test_前缀命名否则 pytest 不会执行。优先使用普通函数写成def test_*()函数。pytest 无法向unittest.TestCase方法注入 fixture所以TestCase无法使用 conftest.py 中的任何共享 fixture也无法使用pytest.mark.parametrize。唯一例外是需要真实 HTTP 往返的测试继承testutils.VisdomHTTPTestCase定义于 py/tests/testutils/http.py它在临时端口上进程内启动 Tornado app仍然保持封闭性。外部服务器标记需要外部启动的服务器才能运行的测试必须标注pytest.mark.server以便 CI 通过-m not server排除。当前套件中没有任何用例需要它。5.3 共享 fixtures 与测试依赖py/tests/conftest.py 提供的共享 fixture 揭示了测试如何逼近真实运行环境env_path临时环境目录基于tmp_pathstore/spy_store分别提供真实的JSONStore与记录服务器调用的SpyStore见 py/tests/testutils/fakes.pyapp/app_factory构造进程内的Application默认端口 8097只记录端口不真正绑定因此可并行构造inline_executor把IOLoop.current().run_in_executor调用改为线程内立即执行用于断言自动保存等异步调度行为。测试依赖清单见 test-requirements.txt包含 pytest、matplotlib、numpy、torch、lightning、scikit-learn、xgboost 等——这与 py/visdom/loggers/ 下各框架 logger 的测试需求一一对应如keras.py、lightning.py、sklearn.py、xgboost.py。六、UI 贡献React 前端构建与 Playwright 端到端测试Visdom 前端基于React构建源码位于 js/ 目录。一个关键术语澄清UI 中的 Pane 就是 Python/Lua API 里所称的 window。由于前端需要编译所有 JS 改动都要走构建流程。6.1 前端构建yarn 与 npm 二选一# yarn 方式 cd /path/to/visdom yarn # 安装 node 依赖 yarn run build # 构建 js# npm 方式 cd /path/to/visdom npm install # 安装 node 依赖 npm run build # 构建 js这两条命令分别对应 package.json 中的脚本与 webpack 配置webpack.dev.js、webpack.prod.js、webpack.common.jsnpm run build走生产构建npm run dev则是带 watch 的开发模式。提交 PR 时官方建议让 GitHub Action Update Static JS Files 来编译以保证构建一致性——该 Action 会在你创建的任何分支上检测到 JS 文件变更后自动构建并把生成的main.js与main.js.map提交回分支对应 py/visdom/static/js/ 下的产物。Demo 与 UI 测试依赖部分 Python 包请先安装pip install -r test-requirements.txt6.2 Playwright 测试矩阵端到端与视觉回归项目使用 Playwright涵盖基础功能、图片、文本、属性、导出、上传、并行坐标等多个方面。若你新增或修改了函数建议同步调整或补充测试。Playwright UI 模式npx playwright install chromium # 首次安装浏览器 npm run build # 或 npm run dev编译前端 # 确保 8098 端口可用——Playwright 会自动启动一个隔离的 Visdom 服务器 npm run test:gui # 打开 UI 并选择要检查的 specCLI 模式npx playwright install chromium npm run build # 或 npm run dev npm test # 运行 WebSocket 套件 npm run test:polling # 用前端轮询方式运行同一套功能测试视觉回归测试npm run test:init # UI 改动前先生成基线截图 npm run test:visual # 改动构建完成后与基线对比这些命令与 package.json 中的 scripts 一一对应并分别使用独立的 Playwright 配置playwright.config.js、playwright.polling.config.js、playwright.init.config.js、playwright.visual.config.js。从配置可见默认 WebSocket 套件通过 webServer 自动执行visdom -port 8098 -env_path /tmp不复用已有服务器、不包含视觉回归 spec轮询套件则以-use_frontend_client_polling启动 Visdom——该参数在 py/visdom/server/run_server.py 的命令行解析中注册用于让前端通过轮询而非 WebSocket 获取更新从而覆盖两种传输通道。七、编码风格与许可协议Lua使用 3 空格缩进不用 tabPython遵循 PEP 8行宽80 字符License贡献即表示同意你的贡献遵循仓库根目录 LICENSE 的条款Apache-2.0。总结一条完整的 Visdom 贡献链路可以这样概括先借 Issue 排障清单吃透Python 客户端 → Tornado 服务器 → Plotly 渲染的核心架构按三要素模板提交可复现的 Bug 报告认领入门 issue、在dev分支上做小而聚焦的改动Python 侧改动落入 py/tests/ 的unit/与integration/目录并跑通 pytest前端改动经 webpack 构建后用 Playwright 四套配置验证 WebSocket 与轮询两条通道及视觉回归最后经 lint、文档与 Lua/Python 接口同步检查后提交 PR。每一条规则背后都有当前仓库的配置与实现文件可查证这正是 Visdom 作为开源项目易贡献、可验证的工程化体现。赞分享数据可视化前端【免费下载链接】visdomTool for real-time visualization, monitoring and collaborative analysis of AI/ML experiments and live data. Supports Python, PyTorch/Torch, NumPy, TensorFlow/Keras https://visdom.dev项目地址https://gitcode.com/gh_mirrors/vi/visdom点击查看免费下载相关推荐PDM 开发者贡献指南从提交 Issue 到发布 Release 的完整工作流PDM 开发者贡献指南从提交 Issue 到发布 Release 的完整工作流 本文面向希望参与 PDMPython 包与依赖管理器 开源项目的开发者系开发工具包管理器CLIStarlette 贡献指南从提交 Issue 到合并 PR 的完整开发者工作流Starlette 贡献指南从提交 Issue 到合并 PR 的完整开发者工作流 Starlette 是一个轻量级 ASGI 框架它的演进离不开社区贡献。本后端Web框架react-datepicker贡献者指南从Issue到PR的完整流程react datepicker贡献者指南从Issue到PR的完整流程 引言为什么需要这份指南 你是否曾想为开源项目贡献代码却被复杂的流程吓退作为Gi前端UI组件上一篇brpc跨语言通信实践与Python/Java服务的无缝对接下一篇Winlator输入控制系统深度解析Android运行Windows应用的技术挑战与解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Visdom 贡献指南：从 Issue 排障到 Python/React 双端测试的完整开发者工作流
数据可视化前端【免费下载链接】visdomTool for real-time visualization, monitoring and collaborative analysis of AI/ML experiments and live data. Supports Python, PyTorch/Torch, NumPy, TensorFlow/Keras https://visdom.dev项目地址https://gitcode.com/gh_mirrors/vi/visdom点击查看免费下载Visdom 是一款面向 AI/ML 实验的可视化工具它由 Python/Tornado 后端、React 前端与 Lua/Python 双客户端组成。本文以仓库根目录的 CONTRIBUTING.md 为骨架完整讲解如何排查常见使用问题、如何报告 Bug、如何提交 Pull Request并深入 Pythonpytest与前端Playwright两套测试体系的架构与实战用法。读完本文你将掌握一条从遇到问题到提交被合入的代码的完整贡献路径并能在当前仓库源码中定位到每一步对应的实现文件。一、先学会排障用 Issue 清单理解 Visdom 的运行机制贡献者最常见的起点不是写代码而是先理解问题。CONTRIBUTING.md 把高频问题整理成了一张排障清单同时也揭示了 Visdom 的核心运行架构Python 客户端负责构造数据 → 经 WebSocket 发送给 Tornado 服务器 → 服务器将 JSON 结构交给前端 Plotly 渲染。1.1 无法连接 Visdom 服务器这是最高频的问题。排查链路如下确认服务器是否在运行通过python -m visdom.server启动然后尝试重启。该命令对应的实现入口在 py/visdom/server/main.py它会调用 run_server.py 中的启动逻辑。确认网络未被阻断防火墙可能拦截了浏览器与服务器之间的流量此时可通过服务器启动参数-proxy指定代理也可以在本地~/.ssh/config中为远程服务器配置 SSH 隧道转发LocalForward 127.0.0.1:8097 127.0.0.1:8097确认端口未被占用部分用户反馈执行sudo ufw allow 8097可以放行被防火墙拦截的 8097 端口。值得注意的是Visdom 的默认端口 8097 同样体现在测试基建中例如 playwright.config.js 的 webServer 配置使用visdom -port 8098 -env_path /tmp启动独立实例而 py/tests/conftest.py 中appfixture 默认构造Application(port8097, ...)。1.2 浏览器出现蓝屏但看不到可视化内容蓝屏通常意味着前端 JavaScript 依赖没有加载成功这在部分网络环境下是常见问题。排查方式在 Chrome 中点击View → Developer → JavaScript Console检查是否存在与缺失 JS 依赖相关的报错。若确认依赖缺失进入已安装的visdom包目录例如/home/$USERNAME/$ANACONDA_FOLDER/lib/python$PYTHON_VERSION/site-packages/visdom-$VISDOM_VERSION-py$PYTHON_VERSION.egg路径变量取决于你的安装方式从源码安装时目录可能不同。查看仓库根目录的 download.sh 脚本——它会下载 Plotly、MathJax、SJCL 等前端资源到py/static/js与py/static/css等目录你可以直接执行该脚本或按脚本内容手动下载全部资源。重启 Visdom 服务器再次打开 JavaScript Console 确认依赖已全部就位。从源码结构看download.sh 下载的plotly.min.js、mathjax-tex-mml-svg.js等资源正是前端渲染与公式显示所依赖的运行时库最终会被 setup.py 通过package_data{visdom: [static/*.*, static/**/*, ...]}打包进发行版。1.3 想要一个现有 API 之外的绘图特性Visdom 的可视化能力建立在 Plotly 之上客户端代码先构造一个 JSON 结构再由服务器把该结构交给 Plotly 渲染。这意味着只要输入正确Visdom 就能展示 Plotly 支持的任何可视化——但 Visdom 只暴露了其中最常见的部分。如果你需要某个未暴露的特性官方态度是欢迎直接动手改造客户端修改产生数据结构的客户端代码位置在 py/visdom/init.py每种绘图类型的全部可用选项可以参考 Plotly 官方手册Python 版甚至可以从零构造自己的绘图数据结构然后直接调用_send方法把它发送给 Visdom 服务器。_send的当前实现位于 py/visdom/init.py签名形如def _send(self, msg, endpointevents, quietFalse, from_logFalse, ...):它是客户端与服务器之间所有消息默认走events端点的统一出口理解它有助于定位数据是如何从 Python 到达前端的完整链路。1.4 想使用 pip 版本尚未包含的新特性最新的特性往往只在源码仓库中。从源码安装的方式# 先卸载已安装版本再以可编辑模式安装 pip uninstall visdom pip install -e .本地开发注意事项执行python -m visdom.server时Python 可能仍会导入site-packages里旧版本的visdom包而不是你 checkout 出来的源码。此时会出现前端编译成功、main.js已更新、服务器正常重启、但 UI 仍旧是老行为的迷惑现象。验证当前实际加载的源码python -c import visdom; print(visdom.__file__)输出路径应指向你的本地仓库而非site-packages。若需要手动优先本地源码export PYTHONPATH$PWD/py:$PYTHONPATH部分 pip 安装场景下可编辑安装无法正确链接模块此时可退而使用python setup.py install。关于 Python 版本约束setup.py 中python_requires3.12明确写明了当前仓库要求 Python 3.12 及以上。二、如何提交一份高质量 Bug 报告找到问题后一份可复现的报告能极大加速定位。CONTRIBUTING.md 要求 Bug 报告中必须包含以下三要素Visdom 服务器输出的错误信息直接从终端复制粘贴JavaScript Console 输出的错误信息如有在 Chrome 中通过View → Developer → JavaScript Console查看并粘贴警告或错误运行平台信息操作系统、浏览器、Visdom 版本。在提交前请先翻阅 Issue 列表确认是否已有相同问题及解决方案同时请理解Visdom 是维护者业余时间维护的项目没有专职工程师请求无法全部即时响应。三、贡献者行为准则首次贡献者与 AI 辅助编码仓库对贡献者提出了两条明确的软性规范首次贡献者建议从入门级 issue 开始避免一开始就接手涉及大规模文件改动或重大代码重构的任务保持初始贡献聚焦、范围可控便于熟悉代码库并通过评审。AI 辅助编码欢迎使用 AI 工具协助编写、调试或理解代码但只有在你完全理解改动作用、并能逐行解释每一处改动时才应提交 PR。盲目复制粘贴无法解释、无法调试的 AI 生成代码是不被允许的——贡献者对自己提交代码的正确性与可维护性负全责。四、Pull Request 流程全解仓库积极欢迎 PR提交前请逐条核对以下清单Fork 仓库并从dev分支创建你的工作分支新增代码必须有对应测试Python 测试规范见下一节若改动了 API同步更新文档确保 Lua 与 Python 两套接口保持同步——仓库中 th/Lua 侧与 py/visdom/Python 侧共同面向同一套服务器协议这是 Visdom 双客户端架构的特殊要求若改动js/目录需提交 React 编译后的main.js详见UI 贡献一节GitHub Action Update Static JS Files 会在你创建分支后自动构建并提交main.js与main.js.map为新特性添加 demo见仓库 example/ 目录并确保 demo 可运行保证代码通过 lintJavaScriptnpm lintPythonblack py安装pip install black23.1可在每次git commit前自动执行pre-commit install若尚未签署完成 Contributor License AgreementCLA。五、Python 测试体系py/tests 的架构与用法Visdom 的 Python 测试套件使用 pytest 下。其设计宗旨是封闭hermetic不需要运行真实的 Visdom 服务器也没有任何测试触碰网络。由于 Visdom 要求 Python 3.12测试也应运行在 3.12 及以上环境。5.1 运行测试pip install -e . # 安装 visdom pip install -r test-requirements.txt # 安装 pytest 及测试依赖 pytest # 运行整套测试 pytest -m not server # CI 实际运行的命令排除需要外部服务器的用例测试发现规则配置在 pyproject.toml 中testpaths [py/tests]限定只收集py/tests下的用例仓库根目录的零散test_*.py脚本会被忽略因此从仓库任意位置执行pytest都能自动发现套件无需传入路径。开发期间的常用收窄方式pytest py/tests/unit # 快速子集无 HTTP纯逻辑 pytest py/tests/unit/window_builder.py # 单个文件 pytest -k window_builder # 按名称匹配 pytest -x --lf # 首个失败即停随后只重跑失败项unit、integration、slow、server四个 marker 均在 pyproject.toml 中注册可用-m选择addopts -ra -q已默认开启-q再传-q会隐藏汇总行如需 pytest 完整默认输出可加-o addopts。5.2 测试目录结构与新增测试的规范目录结构如下py/tests/ conftest.py # 共享 fixtures自动加载 testutils/ # 可导入的辅助代码——永远不会被当作测试收集 unit/ # 纯逻辑不构造 Application除 tmp_path 外无 I/O integration/ # 进程内 Application、真实 HTTP 或 handler 分发新增测试时的三条硬性规范文件放哪、叫什么按依赖选择unit/或integration/文件命名用unit/window_builder.py而非unit/test_window_builder.py目录名已经说明是测试但测试函数仍必须以test_前缀命名否则 pytest 不会执行。优先使用普通函数写成def test_*()函数。pytest 无法向unittest.TestCase方法注入 fixture所以TestCase无法使用 conftest.py 中的任何共享 fixture也无法使用pytest.mark.parametrize。唯一例外是需要真实 HTTP 往返的测试继承testutils.VisdomHTTPTestCase定义于 py/tests/testutils/http.py它在临时端口上进程内启动 Tornado app仍然保持封闭性。外部服务器标记需要外部启动的服务器才能运行的测试必须标注pytest.mark.server以便 CI 通过-m not server排除。当前套件中没有任何用例需要它。5.3 共享 fixtures 与测试依赖py/tests/conftest.py 提供的共享 fixture 揭示了测试如何逼近真实运行环境env_path临时环境目录基于tmp_pathstore/spy_store分别提供真实的JSONStore与记录服务器调用的SpyStore见 py/tests/testutils/fakes.pyapp/app_factory构造进程内的Application默认端口 8097只记录端口不真正绑定因此可并行构造inline_executor把IOLoop.current().run_in_executor调用改为线程内立即执行用于断言自动保存等异步调度行为。测试依赖清单见 test-requirements.txt包含 pytest、matplotlib、numpy、torch、lightning、scikit-learn、xgboost 等——这与 py/visdom/loggers/ 下各框架 logger 的测试需求一一对应如keras.py、lightning.py、sklearn.py、xgboost.py。六、UI 贡献React 前端构建与 Playwright 端到端测试Visdom 前端基于React构建源码位于 js/ 目录。一个关键术语澄清UI 中的 Pane 就是 Python/Lua API 里所称的 window。由于前端需要编译所有 JS 改动都要走构建流程。6.1 前端构建yarn 与 npm 二选一# yarn 方式 cd /path/to/visdom yarn # 安装 node 依赖 yarn run build # 构建 js# npm 方式 cd /path/to/visdom npm install # 安装 node 依赖 npm run build # 构建 js这两条命令分别对应 package.json 中的脚本与 webpack 配置webpack.dev.js、webpack.prod.js、webpack.common.jsnpm run build走生产构建npm run dev则是带 watch 的开发模式。提交 PR 时官方建议让 GitHub Action Update Static JS Files 来编译以保证构建一致性——该 Action 会在你创建的任何分支上检测到 JS 文件变更后自动构建并把生成的main.js与main.js.map提交回分支对应 py/visdom/static/js/ 下的产物。Demo 与 UI 测试依赖部分 Python 包请先安装pip install -r test-requirements.txt6.2 Playwright 测试矩阵端到端与视觉回归项目使用 Playwright涵盖基础功能、图片、文本、属性、导出、上传、并行坐标等多个方面。若你新增或修改了函数建议同步调整或补充测试。Playwright UI 模式npx playwright install chromium # 首次安装浏览器 npm run build # 或 npm run dev编译前端 # 确保 8098 端口可用——Playwright 会自动启动一个隔离的 Visdom 服务器 npm run test:gui # 打开 UI 并选择要检查的 specCLI 模式npx playwright install chromium npm run build # 或 npm run dev npm test # 运行 WebSocket 套件 npm run test:polling # 用前端轮询方式运行同一套功能测试视觉回归测试npm run test:init # UI 改动前先生成基线截图 npm run test:visual # 改动构建完成后与基线对比这些命令与 package.json 中的 scripts 一一对应并分别使用独立的 Playwright 配置playwright.config.js、playwright.polling.config.js、playwright.init.config.js、playwright.visual.config.js。从配置可见默认 WebSocket 套件通过 webServer 自动执行visdom -port 8098 -env_path /tmp不复用已有服务器、不包含视觉回归 spec轮询套件则以-use_frontend_client_polling启动 Visdom——该参数在 py/visdom/server/run_server.py 的命令行解析中注册用于让前端通过轮询而非 WebSocket 获取更新从而覆盖两种传输通道。七、编码风格与许可协议Lua使用 3 空格缩进不用 tabPython遵循 PEP 8行宽80 字符License贡献即表示同意你的贡献遵循仓库根目录 LICENSE 的条款Apache-2.0。总结一条完整的 Visdom 贡献链路可以这样概括先借 Issue 排障清单吃透Python 客户端 → Tornado 服务器 → Plotly 渲染的核心架构按三要素模板提交可复现的 Bug 报告认领入门 issue、在dev分支上做小而聚焦的改动Python 侧改动落入 py/tests/ 的unit/与integration/目录并跑通 pytest前端改动经 webpack 构建后用 Playwright 四套配置验证 WebSocket 与轮询两条通道及视觉回归最后经 lint、文档与 Lua/Python 接口同步检查后提交 PR。每一条规则背后都有当前仓库的配置与实现文件可查证这正是 Visdom 作为开源项目易贡献、可验证的工程化体现。赞分享数据可视化前端【免费下载链接】visdomTool for real-time visualization, monitoring and collaborative analysis of AI/ML experiments and live data. Supports Python, PyTorch/Torch, NumPy, TensorFlow/Keras https://visdom.dev项目地址https://gitcode.com/gh_mirrors/vi/visdom点击查看免费下载相关推荐PDM 开发者贡献指南从提交 Issue 到发布 Release 的完整工作流PDM 开发者贡献指南从提交 Issue 到发布 Release 的完整工作流 本文面向希望参与 PDMPython 包与依赖管理器 开源项目的开发者系开发工具包管理器CLIStarlette 贡献指南从提交 Issue 到合并 PR 的完整开发者工作流Starlette 贡献指南从提交 Issue 到合并 PR 的完整开发者工作流 Starlette 是一个轻量级 ASGI 框架它的演进离不开社区贡献。本后端Web框架react-datepicker贡献者指南从Issue到PR的完整流程react datepicker贡献者指南从Issue到PR的完整流程 引言为什么需要这份指南 你是否曾想为开源项目贡献代码却被复杂的流程吓退作为Gi前端UI组件上一篇brpc跨语言通信实践与Python/Java服务的无缝对接下一篇Winlator输入控制系统深度解析Android运行Windows应用的技术挑战与解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考