Sucha's Blog ~ Archive for January, 2020
Babun 和 VSCode git.path
时光轮流转，现在常用的是 Unix Like 的环境，Win 环境反而是少用了，所以 CatetoryLinux 也用来记录 Win 下的东东吧。
话说过年回家收了家人的 Win7 赛扬四核上网本后，我也不知道哪里来的兴趣（也许是键盘真的要比 13 寸的 MBP 好太多），搭建了发布主页的环境，当时就安装了 Git For Windows，配合 VSCode 设置了 git.path 后，用得好好的。
然后觉得 MinGW64 的 shell 太一般了（其实就是指定了 Path 的 cmd），Git For Windows 自带的 Bash 也真的不好用，就开始搜索 Win 下好用的 shell 环境。PowerShell 是先考虑的，但是看到依赖 NetFramework 4.x 我就想算了，养不起。
然后看到了 BaBun，虽然是基于 Cygwin 的再次开发，但自动化安装后，用得很不错。配置部分我现在是很少弄了，安装好后，看到自带了 zsh 和 oh-my-zsh 的配置，不得不说很赞。另外就是操作速度要比之前的 Git Bash 好太多，颜色搭配也相当好看，如下图：
但是不好的地方，在于毕竟依赖了 Cygwin，而 VSCode 无法直接使用 Cygwin 下的 git 来做版本控制，也许是依赖 cygwin dll 的关系吧。
VSCode 团队回复这种情况，说已经对 Git For Windows 做了支持，这种 Cygwin 环境下的不考虑了。其实大家装了 Cygwin 后，是不想再装一个 Git For Windows 了，几乎做同样的事情，太浪费。
不得不说有的人脑洞奇特（没错，是日本人，无贬义），想着将 Cygwin 下的 git 包一层给 VSCode 使用，重点说一下思路，这种封装依赖的思想。
首先建立一个验证环境的逻辑，VSCode 对于版本控制 git 程序的依赖，跟 Win 下普通 cmd 操作 git 是一样的，如果 Win 下普通 cmd 在不知道 Cygwin 环境时，能够正常使用一个类似 git 的工具完成 git 的功能，可以认为这个工具就是 git（版本控制工具）。
这个思路，其实就是封装环境，将 Cygwin 下的 git 及其依赖，封装到这个工具内部。
这里需要选择工具链，需要生成仅仅依赖 Win 下系统原生 dll 的工具链，比如之前已经用过的 MinGW64。我们把 Cygwin 的依赖，环境描述，写到一个 C 源文件里，在源文件里面，调用了 Cygwin 的 bash，跑一个脚本，这个脚本，大概是整理输入的参数并传递给真正 Cygwin 下的 git。Cygwin 的环境，在 bash 拉起脚本的时候，已经建立完成。
这里可以确保在系统的任何地方，调用这个 C 生成的程序，拉起的 Cygwin 环境都是正常的，然后跑脚本里面的 Cygwin 下的 git 操作，就很顺理成章了。
贴一下仓库地址吧：https://github.com/nukata/cyg-git
话说这种想法感觉跟容器化的想法类似，将依赖封装到一起；跟编程语言里面的闭包思想也类似，将 upvalue 带入到闭包里面。只是头大后碰到了这样的解决办法，佩服之余，也思考学习一下。
庆祝在 Windows 下更新本站
受益于MarkdownProjectCompositor 支持 Win 7，有了 generator、compositor 的准备，包括 Win 下 Git 的支持，加上我的编辑器是一个浏览器端单文件编辑器，现在可以比较顺利地在 Win 下写 Markdown，并更新博客了。
老早之前，用 Emacs 做 Markdown 编辑器 + 生成器的时候，也是能够支持 Win 的，当时是用 FTP 上传到网站，改换成 cmark-gfm 后，终于又实现了一次。
m_net 支持 pull-style API
m_net 之前只支持设置 callback 方式回调通知，最近的修改是开始支持 pull-style API。弃用 callback 是为了配合 LuaJIT 的使用，因为 LuaJIT 在 C 层 callback Lua，性能非常不好，LuaJIT FFI callback performence 有说明，大体上有 x27 slower。
LuaJIT 官网的相关介绍，也是不推荐 C 层 callback Lua，因为 callback 函数是临时分配生成的，性能不好，而推荐用 pull-style API。
所谓 pull-style API，就是一个同步操作的含义，call 一次就拿一次数据这样。
m_net 的修改，是将 callback 这一层，从 C 移到了 Lua 层，Lua 层从 C 层获取事件通知的多个 chann 及其 message，之后在 Lua 层面做 callback，算是避开了从 C callback Lua 这个坑。
这样子修改之后，跟原来提供非 JIT 的 Lua 接口不一致了，考虑到非 JIT Lua 可选用网络通信模型挺多的，比如老一辈的 LuaSocket，比如 Luvit 之类的，索性我就去掉了非 JIT Lua 的接口支持。
修改完后，做了一个简单的压测，对所有 accept 的 chann，发送一个 HTML 包裹的 hello，world，设置了 backlog 100，ab 100 个实例 5000 次试验的结果：
# ab -c 100 -n 5000 http://127.0.0.1:8080/empty
Concurrency Level: 100
Time taken for tests: 0.547 seconds
Complete requests: 5000
Failed requests: 0
Total transferred: 530000 bytes
HTML transferred: 65000 bytes
Requests per second: 9134.39 [#/sec] (mean)
Time per request: 10.948 [ms] (mean)
Time per request: 0.109 [ms] (mean, across all concurrent requests)
Transfer rate: 945.55 [Kbytes/sec] received
感觉还可以。
MarkdownProjectCompositor 支持 Win 7
给家人换了一台性能更好的老笔记本，之前的上网本自然就归我了，赛扬 N3150 4核 4GB 其实不算差，至少现在开着 Chrome 写 Markdown 是很流畅的，然后想着怎么废物利用，比如用来做下载机，但其实我没啥可下载的，用来搞点 Windows 环境下的编程，写点 Markdown 倒是不错。
然后就想着怎么把之前的工程搬到 Windows 上面来，网络部分的先算了，没有 IOCP 也没啥意思，看来看去，LuaJIT 加上 MarkdownProjectCompositor 是个不错的入口。
即便如此，这次适配也吃了苦头，赛扬 4G 我是不想用 Visual Studio 了，不管是 2012 还是 2015，下个几 G 编译个几百 K，不值得。就搞了个 MingW64，然后下载了一个 Git。
依赖有 cmark-gfm 和 LuaJIT，lfs_ffi.lua 看了一下是支持 Windows 的。可是 cmark-gfm 不能直接在 MingW64 下编译，需要 cmake，搞了一个 win 下的 cmake，可不是随随便便就能生成 makefile 了，MingW 环境下需要这样：
mkdir build
cd build
cmake -G "MinGW Makefiles" ..
make
你没看错，需要指定生成 MingW 下的 makefile，而且冒号内的关键字不能错哦，这一步浪费了我好几个小时。后面的 make 就很顺利了，虽然赛扬 4G 马力明显不足，磕磕碰碰的最后还是给捣出来了。
MingW 环境编译的程序只依赖 Windows 原生库，所以蛮小的。接下来的 LuaJIT 编译有了前面的铺垫，很顺利就生成了。
后面的 2 个小时，浪费在了 compositor 拼接 source 以及生成 html 的过程中，因为在 lua 里面 io.open() 文件时，没有带 b 用二进制的方式，使得在 windows 下换行是 CRLF 的。因为我的 config.lua 也很复杂，WelcomePage 是根据生成的 html 最后做拼接的，这里也要指定用 binary 的方式读写。
最后我还在 compositor 里面加入了去掉 CRLF 以及 CR 的 dos2unix 开关，把原来 Markdown 里面的多余 CR 都去掉了，毕竟 CR 没啥用，会被 HTML 的 tag 忽略的。这段是确保 MacOS 下生成的 HTML 跟 Windows 下生成的一模一样。
再搞了一个 publish_html.bat 脚本，配置好 config.lua 以及目录后，一键生成，就可以看着赛扬 4核慢吞吞地做转换了。
最后把这半天的成果，windows 下的 cmark-gfm、luajit、lfs_ffi.lua，还有一个一键生成脚本，打了一个 zip 包，作为一个 release 发出去了，毕竟不是专业 windows 下的开发，也许以后再换一个 windows 环境，可真的折腾不来了。