理论上是相同的, Transformer 架构的老本行就是机器翻译

@rammiah #20 逐行翻译的, zig 版本是啥样翻译成 rust 就是啥样. 前期快速翻译过来, 后期重构时这些 unsafe 代码块就几乎等于 // FIXME 了

```zig
extern fn WTF__base64URLEncode(input: [*]const u8, input_len: usize, output: [*]u8, output_len: usize) usize;
pub fn encodeURLSafe(dest: []u8, source: []const u8) usize {
bun.jsc.markBinding(@src());
return WTF__base64URLEncode(source.ptr, source.len, dest.ptr, dest.len);
}
```

https://i.imgur.com/a35H8nm.png

真是草台班子, option+ 和 GHUB 的体验太糟糕了, 体积还大

太恶心了, 政府机关强制使用第三方的专有闭源格式, 导致用户丧失选择权; ooxml 再怎么烂也是开源格式, 比 wps 好得不知道哪去.

太棒了, 做了我一直想做而没时间做的事情

与格式有关, 格式越复杂性能越差
建议将纯文本拷贝到新的 word 中, 再用主题统一设置样式, 尽量避免设置单个或者部分文本的样式

推荐你买 PS5, 我买的 XSX, 之前主要是看 XGP 便宜大碗, 现在 XGP 涨价, 还有部分游戏(说的就是黑猴) XBOX 独不占, 很搞心态

按道理来说可以直接在 hyper-v 里面装安卓吧, 反正都是 aarch64 架构的

TL;DR 用 CRDT 算法

原因:
- 常用的 raft 算法无法容忍脑裂, 即 A-B / C-D 上线然后还要实现日志同步, 即使要解决脑裂也要用非常扭曲的方法;
- CTDT 是 p2p base 的分布式一致性算法, 且你的业务场景比较简单, 只需要需要处理 retain+insert 的场景, 不涉及到 remove;
- https://github.com/vlcn-io/cr-sqlite 这个用 crdt 做 sqllite 代理的项目应该比较适合你的业务场景

@ghwolf007 逻辑上没有区别, 印象中 doc 跟 docx 一样都是根据 styleId 去样式表中查找对应的样式, 但是这个 styleId 五花八门, 比如一眼从客户端中能看出来是标题的段落, 实际的 styleId 可能是 「 heading 1 」/「标题」 或者干脆命名成 「丁真」

如果这些文档是由同一个文档模版创建的, 那么可行; 否则, 不可行

1, 无法准确识别文章某一个段落的格式类型, docx 文档中不存在「标题」「正文」...只有「样式表」, 换句话说, 所有的标题和正文的格式只是「样式表」中的某一个样式的命名.你没法保证每一个文档中样式表的命名都是「标题」「正文」.只能根据 fOntSize==16 或者 bold==true 这样的条件去判断, 但是每一个文档中样式都略有区别.

2. 从 doc 转到 docx 之后, 形状、图片元素可能被转置成 VML 而非 OOXML 通用的 DML, 虽然没看 python-docx 代码, 但是大概率是不支持的

我老婆前天晚上问我那老黑是谁
没想到姆巴佩在女性群体里的知名度这么低

应该是盒子硬件不支持视频编码使用了软解, 跟传输速率应该没关系

遇到一件怪事, 手机的剪切板同步在 m1 mbp 上是好的, 但是最近无法在 x86 mbp 上使用了, 无论是重启, 重登 icloud 都没用, 果子体验原来越差了

文档本身的 Blob 数据存对象存储. 数据库中只存索引

想到下面几个能扯上边的

遥测端点: telemetry entrypoint
调试器: debugger/hook
修复工具: repairer