在 Go 中管理 Lua 内存!

image_2025-07-02_15-22-15.png

770.5 KB

ginja 已经写好了第一个版本
go.yuchanns.xyz/ginja
但是性能很不理想，比起 go 标准库 template 慢了十几倍！
接下来想验证:
1. purego v.s. purego+libffi 性能
2. cgo v.s. purego 性能
如果确定是 libffi 拖后腿，我可能就需要考虑如何仅使用 purego 来实现了

今天开发 ginja 的时候发现和 opendal go binding 一样的 c 的部分有重复的代码，明天可以封装一个 typeffi

#开源项目 我又有个想法。想写一个 #mcptranslator 这个名字并不是说它是一个 mcp 工具，而是表示它会通过 mcp 协议使用一些工具进行翻译。例如，它会首先调用语言检测工具检测语种，然后使用对应语种的词典查阅单词信息，或者专有名词信息，接着根据上下文翻译到目标语言，最后查询 native speaker 常用表达语句，进行本地化润色。灵感来自于参与 yetone 的 avante.nvim 的开发与使用。这个项目促使 AI 使用各种工具优化代码，具有显著的质量提升

#dalbox 第四个插件，使用 emby api 进行内嵌播放能力

#开源项目 有空的时候希望研究一下 https://github.com/yomaytk/elfconv/issues/57

GitHub

Linux system calls implementation tasks. · Issue #57 · yomaytk/elfconv

We should emulate the Linux system calls on both the WASI and the browser. Many system calls can easily implemented by using the function defined in the wasi-libc or emscripten as follows (below ex...

#dalbox 而 AI 字幕则作为一个单独的进程，以第一种插件的形式接入

#dalbox 按照之前的插件架构设计，一般插件都要以一个进程的形式而存在。感觉有时候不是很必要，尤其是这个插件只是作为一个垫片的形式存在时。例如: 下载插件，本质上是作为一个垫片帮助 dalbox 访问 aria2 的 API, 这种情况下 aria2 已经是一个进程了，垫片作为一个进程显得很不必要。应当考虑支持第二种形式的插件，比如 lua 脚本。这样就可以作为轻量的垫片来实现。运行在 goroutine 管理的 lua vm 下。像订阅这种插件似乎也没有必要以一个单独的进程存在，完全可以是一片 lua 代码, 进行简单地周期性轮询订阅

#dalbox 第三个重要的插件应该是字幕吧？而且是使用 AI 转音频转文字后翻译的字幕，支持设置作品上下文中特定的名词

#dalbox mvp 目标: 提供一个以 opendal 为核心的文件管理器本体，以及初步实现的插件架构和初版组件模板，并实现订阅插件(仅支持自定义订阅)和下载(aria2)的插件 #开源项目

#TIL https://blog.dsrkafuu.net/post/2020/github-add-commit-to-pull-request/
今天协作修改一个 OpenDAL 的 PR 时学到了

blog.dsrkafuu.net

GitHub 修改他人的 pull request 并提交 commit | DSRBLOG

使用一种更简单的方案修改其他社区开发者提交的 pull request。