之前因为 MacBookPro 内置的 Wi-Fi 总是有问题，就找了个 USB 的无线网卡：TP-Link Archer T4U V3（VID：2357，PID：0115），这个网卡也没有主线的驱动，在网上找到了现成的驱动：cilynx/rtl88x2bu，按照 README 用 DKMS 安装即可，实测可用。 Update: Linux 6.2+ 已经支持，见 https://linux-hardware.org/?id=usb:2357-0115
MacBookPro 14,3 Wi-Fi 驱动问题解决方案
之前在 MacBookPro 14,3 安装 Linux 后，很多东西的驱动都有了解决方法，参考 1，参考 2，触摸板和键盘等等都可以正常使用，触摸板的使用效果比我意料要好一些，虽然还是没有 macOS 原生那么好。但 Wi-Fi 一直有能扫到信号但连不上的问题，最近终于有了比较完善的解决方案，地址，也是两个月前才出来的方案，我测试了一下，确实可以很好的解决网络问题，网卡型号是 BCM43602，驱动用的是 brcmfmac。 另一方面，带 T2 的 MacBook 似乎也有了支持，见 aunali1/linux-mbp-arch，有一些尚未 upstream 的 patch，但我没有设备，就没有测试了。需要吐槽的是 ArchWiki 不怎么更新新 Model 的 MacBook 的教程，都是到处找散落的 github repo 和 gist 找别人的方案。 P.S. 可以正常工作的有：Wi-Fi，键盘，触摸板，Touchbar，内置摄像头，键盘背光，蓝牙 P.P.S MacBookPro11,2 的网卡是 BCM4360，直接用 broadcom-wl 驱动就可以。
JieLabs 是如何工作的
简介 JieLabs 是陈嘉杰、高一川、刘晓义（按姓氏拼音首字母排序）于 2020 年新型冠状病毒疫情期间开发的在线数字逻辑电路实验系统，用于清华大学 2020 年春季学期数字逻辑电路实验课程。其包括前端、后端和固件三部分，分别主要由刘晓义、陈嘉杰和高一川负责开发。核心功能实现用时一周，后续界面和稳定性优化用时两周。本文会详细地介绍 JieLabs 的工作原理和一些技术细节，希望对各位同学有所帮助。 太长；不看。 采用了如下的技术方案： 前端：React 框架 + Redux 状态管理 + Monaco 编辑器 + WebAssembly 运行 Rust 代码 + WebSocket 实时通信 + SASS 样式 后端：Actix-Web 框架 + Diesel/PostgreSQL 数据库 + Redis 消息队列 + Quartus 构建 + Kubernetes 构建容器编排 固件：Xilinx FPGA 控制 + Buildroot 系统 + Linux 内核 前端 前端大部分都是刘晓义同学编写的，也是这个项目工作量最大的一部分。除了本文，还可以阅读刘晓义同学自己写的总结。主要分以下几部分来谈前端的技术实现： 第三方库 整体上采用了时下比较流行的 React 框架，配合 Redux 进行状态管理，用 React Hooks 编写组件的逻辑。为了实现 VHDL/Verilog 代码的编辑，采用了来自 VSCode 的独立编辑器空间 Monaco，并自行编写了 VHDL 和 Verilog 语言的支持，一部分在 JS 实现，另一部分在 Rust 中实现，通过 wasm-pack 打包到 JS 中执行。另外为了实现 gzip 格式的解压缩也引入了 pako 库。
每周分享第 54 期
咕了两周 ES2019 https://javascript.christmas/2019/7 CSS 技巧 https://github.com/chokcoco/iCSS Rust 编译器加速 https://blog.mozilla.org/nnethercote/2019/12/11/how-to-speed-up-the-rust-compiler-one-last-time-in-2019/ OSXFuse 不开源 https://colatkinson.site/macos/fuse/2019/09/29/osxfuse/ 嵌入式 Rust 的 fmt 优化 https://jamesmunns.com/blog/fmt-unreasonably-expensive/ Docker base image 更新工具 https://github.com/containrrr/watchtower 运行 Linux 的名片 https://www.thirtythreeforty.net/posts/2019/12/my-business-card-runs-linux/
每周分享第 53 期
GDB Enhanced Features https://github.com/hugsy/gef Lisp on Lua https://fennel-lang.org/ Django 3.0 https://docs.djangoproject.com/en/3.0/releases/3.0/ Rust Constant Propagation https://blog.rust-lang.org/inside-rust/2019/12/02/const-prop-on-by-default.html ES2019 features https://javascript.christmas/2019/7
每周分享第 52 期
传递 Rust 闭包到 C https://readhacker.news/s/4dbWL SystemVerilog Online http://sv-lang.com/ Java 14 新特性 https://www.javaworld.com/article/3437797/work-begins-on-java-14.html 在线 or1k 的模拟器 https://readhacker.news/s/4dfqc 在 macOS 上运行 virt-manager https://github.com/jeffreywildman/homebrew-virt-manager 关于 SystemVerilog 的博客 http://systemverilog.io/ 结合 VSCode 和 Docker 的开发环境 https://github.com/cdr/sail
每周分享第 51 期
一个 LaTeX 的 LSP https://github.com/latex-lsp/texlab Rope 数据结构 https://github.com/cessen/ropey 一个把 Vivado 工程放 git 中管理的方法 https://github.com/jhallen/vivado_setup https://github.com/athre0z/color-backtrace 拿 Arch 当路由器 https://github.com/archwrt Sourcetrail 开源了 https://www.sourcetrail.com/blog/open_source/ NodeJS 正式支持 ES Module https://medium.com/@nodejs/announcing-core-node-js-support-for-ecmascript-modules-c5d6dc29b663 Rust 的错误处理 https://blog.yoshuawuyts.com/error-handling-survey/
实现一个简单的 Decaf LSP
背景 编译原理课程在做 Decaf 的 PA，之前做了一些比较简单的尝试，包括在线 Decaf、在线 TAC VM 等等，都是套一个前端，然后整个编译到 wasm 跑前端就可以了。如果要做 LSP 的话，工作量会稍微大一些，不过也更加实用。 然后有一天，助教 @equation314 写了 decaf-vscode 一个 VSCode 对 Decaf 的语法高亮插件，我就 Fork 了一份到 jiegec/decaf-vscode，然后添加了 LSP 的支持，让它有了一些更高级的功能。 实现 LSP 服务端一般是一个命令行程序，通过 JSONRPC 进行消息通讯，然后就上午找有没有现成的框架。比较重要的是 lsp-types 和 tower-lsp ，前者封装了 LSP 协议的各个结构体，后者提供了服务端的大概实现。不过由于后者做的不大全，所以我自己 fork 了一份添加了一些。 实际实现的时候，需要实现几个函数，分别相应客户端的请求，比如在 initialize 的时候告诉客户端我都实现了哪些东西，然后相应地提供各种信息，如 symbol，hover，folding，definition 等等。为了实现简单，我要求客户端每次修改的时候都把完整的文件传过来，虽然不是很高效，但是很简单，目前也没有啥很长的 Decaf 程序嘛。 每次拿到 Decaf 程序之后，就按照 decaf-rs 的方法，Lex 然后 Parse，然后遍历 AST，分别把需要的各个信息都存下来，当客户端在请求的时候，直接返回即可。然后就会在 VSCode 中出现，比如实现了 document symbol，在左边的 Outline 中就会出现相应的结构；实现了 hover，当移动到一些地方的时候，客户端发出请求，服务端就把相应的 hover 信息返回给客户端。整个协议并不复杂，后面实际实现其实才是比较复杂的地方。 实现的功能中，symbols hovers ranges definition 都是在得到 AST 后一次遍历都计算好，然后返回，同时在遇到错误的时候，也通过 diagnostic 的形式把检查出来的错误汇报给用户。由于 VSCode 的良好支持，基本不需要写 TypeScript 代码。
每周分享第 50 期
时间过得真快，忽然就 50 期了。。 CLion 的 C++20 Concept 支持 https://blog.jetbrains.com/clion/2019/11/cpp20-concepts-in-clion/ TypeScript 一些工具 https://github.com/pirix-gh/ts-toolbelt Rust 编写的 SystemVerilog Parser https://github.com/dalance/sv-parser MacBookPro 16 英寸 发布 用 Rust 写 eBPF 程序 https://blog.redsift.com/labs/putting-rust-in-the-kernel-with-ebpf/ 终端里玩蜘蛛纸牌 https://github.com/chrisbouchard/klondike-rs Rust 的 coverage 工具 https://github.com/mozilla/grcov 在 Menu Bar 或者 Touch Bar 控制 AirPods Pro 模式 https://github.com/insidegui/NoiseBuddy Demangle Rust 符号的工具 https://github.com/luser/rustfilt
用 Rust Procedure Macro 实现 GLL Parser
背景 在编译原理课上，PA 框架采用的是 MashPlant/lalr1 ，是一个比较好用的 Lexer + Parser 的工具，它的大概语法见 一个完整的例子 。然后之前看到了 GLL Parser，想着可不可以照着类似的语法也写一个 GLL 的 Parser Generator，也是用 Rust Procedure Macro 的方法，就开始了研究。 尝试 首先是阅读 GLL 的论文，它并不长，大概的意思就是，LL(1) 文法需要考虑 PS 冲突的情况，而 GLL 的解决方法就是“都试一下”，然后为了效率，用了 GSS 表示解析过程和 SPPF 表示解析结果。然后就开始照着论文手写了不同版本的实现，见 jiegec/gll-test 。 第一种就是按照论文里第一段实现直接抄过来，每个可能性作为一个 Continuation 存下来，它有自己的栈和执行位置（Label）。这样 Work 以后呢，我又想到了 async/await，用类似的方法又写了一遍，相对要简洁一些，也是很平常的递归下降的写法，而不是 Loop + Label 的形式。但这些都不能做到合并栈的目的，所以遇到十分有歧义的文法的时候会很糟糕。 然后开始按照论文中的 GSS 进行编写，基本还是按照论文进行翻译，然后一步一步做，做好以后把 GSS 画出来，和论文的图可以对的上；然后照着 GLL parse-tree generation 的论文把 SPPF 实现了，这时候就可以从 recongizer 变成一个 parser 了。 宏 得到一份可行的代码以后，就要扩展到通用的情况上。学习了一下 MashPlant/lalr1 的实现，实现了一个 proc macro，它读取了用户的程序，从一个模板文件开始，往里面插入一些生成的代码，丢给编译器去编译。这时候就涉及到编译期和运行时的不同了，我把运行时一些通用的结构放到了 gll-pg-core 中，把编译期的代码放到了 gll-pg-macros 。