 fanlusky
|
2c3546f823
|
perf(engine): 简拼、快捷短语、表情、颜文字查询复用词库连接
这四种模式每个键都新开一次 SQLite 连接，第一次 prepare 还要解析整个 schema
——msime.db 有两百多张分表。新增 local_modes/local_database，四个查询统一经它
打开只读连接：路径正是当前数据目录下的 msime.db 或 others.db 时共享一条连接，
其余路径（测试、工具）照旧每次独立打开、用完即关。
只共享这两个随安装包发布的库：msime.db 本来就被引擎整个会话持有，others.db 只在
Server 停止时由安装程序替换；保持其它文件常开会让删除它们的工具或测试在 Windows
上失败。close_default_user_database() 同时释放这些连接，调用方原本就用它在删除
或替换数据目录前放开文件。
引擎测试（本地单独构建，CI 不跑）23/23 通过；不加释放钩子时 input_session、
mixed_expressive_input_session、jianpin_input_session 会因目录删不掉而失败。
|
2026-09-27 16:10:01 +08:00 |
|
|
fanlusky
|
8f2c81dd0f
|
perf(server,engine): 选词学习的写库挪出按键线程
权重调整（AdjustCandidateRanking）和输入过的英文词（LearnEnteredEnglishWord）
原本和按键排在同一个 worker 队列里：每次选非首位候选都要在下一个键之前付一次
用户日志的提交和 fsync，触发阈值时还有 msime.db 的一次提交。磁盘忙或杀软扫描
时，这就是肉眼可见的卡顿。
- server/src/utils/serial_task_runner：单线程、按提交顺序执行、低优先级，Stop()
先执行完队列再退出，选词不会在退出时丢失。附单元测试。
- 两类写入改为投递给这个执行器。它们只调用 user_dictionary，不碰输入会话；唯一
的会话副作用——权重变化后清引擎候选缓存——经 EnqueueResetInputSessionCacheTask
回到 worker。删除对应的 TaskType 和 Task 字段。main 在 worker join 之后调用
ShutdownDictionaryWriter()。
- user_dictionary：默认日志连接改为每线程一条。FULLMUTEX 只保证单次调用安全，
保证不了事务：连接只有一个事务状态，写线程的 BEGIN IMMEDIATE..COMMIT 会把
worker 的读卷进来，worker 侧 UserDatabase 析构时还会把它回滚。
close_default_user_database() 递增代号，各线程下次访问时关闭旧连接。
- WorkerThread 取任务改为 move，不再每次复制整个 Task。
行为变化：选词后如果写入还没完成就立刻再打同一串，会短暂看到旧顺序；写完后
worker 清缓存，下一次查询即是新顺序。此前的“下一个键之前一定写完”换成了不阻塞
按键。
|
2026-09-27 16:09:51 +08:00 |
|
|
Jia Sui
|
c6632e8d85
|
feat(engine): 五笔前缀逐键提示与调频接线
- 码表查询从精确匹配改为前缀匹配：精确等长行优先（保住一级/二级简码），
前缀行按权重降序跟随，LIMIT 50 截断（引擎层不读 server 配置的分层边界）
- WubiCandidateProvider 注入 RuntimePaths：接通 update_weight / delete_by_key
到 user_dictionary journal；新增 bump_wubi_weight（同码组 MAX+1、主库更新
与 journal upsert 同事务，行缺失不造行）
- create_word / cache_dynamic_candidate 补「为何 no-op」注释（后续任务范畴）
- 两个 toml 的 wubi_schema 注释与实现对齐：当前仅支持 wubi86
- server 测试：前缀语义、LIMIT 截断、上界构造、调频+journal 回放、删词墓碑
|
2026-09-22 09:23:25 +08:00 |
|
|
fanlusky
|
e32eeadec9
|
fix(engine): 调频比较集跨键合并，按权重而非显示顺序取基准
打 jian 时列表里混着另一种切分 ji'an 的词。吉安 在出货词库里权重是 1，压在同组的
积案(9420)/几案(5999) 底下，而 adjust_candidate_ranking 按音节数圈比较集，于是
吉安 只跟 ji'an 这一组比，可学权重封顶一万出头，永远追不上 见 的 3460998——用户
选多少次，这个候选都纹丝不动。
音节数这个尺度是 #400 加的，为的是挡住另一个 bug：显示列表里备选切分词会被保护位
顶到最前面，中点数学却假定列表按权重降序，于是拿 西鄂(w=6) 当基准把 写 写成 506。
根子在「显示顺序 != 权重顺序」，按音节数滤掉跨表行只是绕开了症状，代价是把每个候选
关进自己的组里。
改成在比较集上直接按权重降序排一次，不变式在源头恢复：任何行都不可能坐在高于自身
权重的位置上充当基准，西鄂 那条路被堵死；同时比较集不再按音节数切开，吉安 的基准
取到整个列表最重的 见，置顶一次即越过，promote 模式连选五次一路走到首位。写入仍只
落在 entry_key 的行上，#36 的护栏不变。
test_user_dictionary_journal 新增两条回归（跨键置顶、连续 promote 收敛到首位），
#400 的两条断言原样保留并仍然通过。
|
2026-09-19 22:14:57 +08:00 |
|
|
Jia Sui
|
9bbd86b633
|
fix(engine): 调频权重基准限定同音节尺度
置顶/提升把一个候选的权重算成「显示列表首位权重 + 500」。显示列表会混入
备选切分词和不同切分的候选，它们的权重是另一套尺度（单字表是语料计数、
多字表是词组词权），于是基准取错就把候选写成垃圾值：用户机器上 xi'e 的西鄂
(w=6) 坐在 xie 列表首位时，置顶写会写出 506（= 6+500），低于些/血/谢，反而
被埋到三十名开外；将也以同样方式被写成 24240（= 激昂 23740+500）。
- 候选的 rank 与权重基准改在同音节尺度内计算：同音节数的表互相可比（九宫格
数字上下混多个单字表、简拼上下文混多个 key 都保留原语义），跨音节数不再
互相充当中点基准。选中词已是同尺度首位时不再写权重，避免被跨尺度反降。
- 写入仍按 entry_key 走，rebalance 不会落到别的 key 的行上（#36 的护栏不变）。
test_user_dictionary_journal 增加回归：混表列表里置顶写必须以些为基准，
且不再把些本身写成 506。
|
2026-09-14 20:14:28 +08:00 |
|
|
fanlusky
|
a7779d2b05
|
refactor(engine): 将 engine 从 submodule 内嵌为仓内一等组件
`vendor/MetasequoiaImeEngine` submodule 改为 `engine/` 目录，导入的是
product-lock.json 原本钉住的提交 c810d201，逐文件核对过 blob，因此这是一次
搬迁而不是引擎升级。引擎自己的嵌套 submodule（googlepinyinime-rev、utfcpp、
miniaudio）按各自 gitlink 一并展开，来源与提交见 engine/UPSTREAM.md。
Windows 专门化裁掉了不属于本产品的部分：whisper.cpp 与本地推理 provider、
macOS 示例宿主、整个 dictionary/ 建库流水线、上游 CI 与 release-please 配置。
词库仍按 product-lock.json 在构建时取发布产物。
引擎不再进 product-lock.json：没有 gitlink 就没有可比对的东西，锁里写一个上游
commit 等于宣称这棵树仍等于上游，而第一个 Windows 专门化改动落地时这句话就假了。
verify-contracts / verify-checkout 随之移除，verify-published 保留。
CI 与工具链：引擎源码并入根 scripts/format.sh（删掉引擎自己的那份，避免两套排除
列表分叉）；引擎 voice.yml 里的 silero_vad.onnx 摘要校验移到本仓 lock job；
engine-bump-triage 工作流与其测试删除；gitsubmodule 的 dependabot 频率由 daily
改为 monthly。
README、README.en、AGENTS.md、CONTRIBUTING、docs/product-release.md 及各子目录
文档同步说明新的位置与边界。
|
2026-09-12 03:40:48 +08:00 |
|