Younger Blog

使用Vercel进行blog部署

Sun, 21 Jul 2024 00:00:00 +0000

Github Pages 在中国大陆的访问速度较慢，并且在博客更新后，部署速度很慢，对于静态资源的更新不利。

Vercel 拥有更好的访问体验已经更快的部署速度，因此弃用Pages而使用Vercel。

使用Vercel部署huxpro.github.io的步骤很简单，注册账号后，通过Github导入对应的项目，直接部署即可。

需要注意的是，将域名绑定到在Vercel部署的页面时，CNAME应选择 cname-china.vercel-dns.com 而非 cname.vercel-dns.com，后者已经被墙。
A记录需要增加三条：76.76.21.21、76.76.21.98、76.223.126.88。
若使用cloudflare作域名解析，需要SSL/TLS加密模式设置为完全，否则会因为过多重定向而无法访问网页。

Openwrt building config maker / Openwrt编译配置生成工具

Intro / 说明

以下是为检测Vercel部署速度而写的内容。

苦昼短
飞光飞光，劝尔一杯酒。吾不识青天高，黄地厚，唯见月寒日暖，来煎人寿。食熊则肥，食蛙则瘦。神君何在，太一安有？天东有若木，下置衔烛龙。吾将斩龙足，嚼龙肉，使之朝不得回，夜不得伏。自然老者不死、少者不哭。何为服黄金，吞白玉？谁似任公子，云中骑碧驴。刘彻茂陵多滞骨，嬴政梓棺费鲍鱼。

江行无题
兵火有余烬，贫村才数家。无人争晓渡，残月下寒沙。

秋风词
秋风清，秋月明。落叶聚还散，寒鸦栖复惊。相思相见知何日，此时此夜难为情。

Usage / 用法

English

Openwrt building config maker

Make your own Openwrt build config file by the GitHub Action, save your time from setting up the build environment.

Usage

Click HERE to create a new repository
Select Make Config File on the Actions page
Click the Run workflow button
Refresh the page and click the lastest Make Config File action to access its log
Click on the build job on the left sidebar

Wait for the SSH connection to Actions job to be executed at this page, and information like the following will appear:

  To connect to this session copy and paste the following into a terminal or browser:
  CLI: ssh McuGhq5PvktJyr53WHFsyjLMW@nyc1.tmate.io
  URL: https://tmate.io/t/McuGhq5PvktJyr53WHFsyjLMW
  TIPS: Run 'touch /tmp/continue' to continue to the next step.

then follow the tips to SSH to Actions. (If you are using a web terminal and get a black screen, just press Ctrl+C)

Type cd openwrt && make menuconfig in the terminal to start building your .config file
After you finishing your work, type touch /tmp/continue in the terminal then exit the terminal, the rest of the work will be done automatically
~~Star this repo, then it will be done faster~~
After all the work is done, you will see OpenWrt_config in Artifacts on the Action Summary page, just click and download it

Advanced Usage

custom source code
This repo will use LEDE’s source code to build the environment by default, you can change it in file .github/workflows/make-config.yml
custom fireware envs
You can change your firmware’s default IP, hostname, theme, add/remove packages and so on by adding command in ./github/diy-part1.sh and ./github/diy-part2.sh
custom feeds source
You can add your own feeds by modifying ./github/feeds.conf.default. For example, add src-git luci https://github.com/coolsnowwolf/luci to use the packages of LuCI

中文

Openwrt编译配置生成工具

通过Github Actions来构建你的Openwrt编译配置文件(.config)，免受自行搭建编译环境的痛苦，并可以配合 P3TERX/Actions-OpenWrt 等在线编译项目，在完全不搭建编译环境的情况下编译自己的固件。实际上，此项目就是从 P3TERX/Actions-OpenWrt 分离出的的模块的改良版

用法

点击这里生成一个新的仓库
在Actions页面中，选择 Make Config File
点击 Run workflows
刷新页面后，你将会看到Actions执行了新的工作，点击它以进入日志页面
点击左侧边栏中的 build

在这个页面上等待Actions执行到 SSH connection to Actions ,然后你会看到类似下面的信息：

  To connect to this session copy and paste the following into a terminal or browser:
  CLI: ssh McuGhq5PvktJyr53WHFsyjLMW@nyc1.tmate.io
  URL: https://tmate.io/t/McuGhq5PvktJyr53WHFsyjLMW
  TIPS: Run 'touch /tmp/continue' to continue to the next step.

点击URL链接或者在命令行中输入上面的ssh命令，就可以与Actions建立SSH连接（如果你进入网页终端时黑屏，按下Ctrl+C即可）

在终端中输入 cd openwrt && make menuconfig ，然后就可以开始构建你的配置文件了
完成并保存你的配置后，在终端中输入 touch /tmp/continue 命令就可以关闭终端了，剩下的工作会自动完成
~~给这个项目点一个 star 会让工作进行得更快~~
所有工作结束后，点击左侧的 Summary ，可以看到一个 Openwrt_config 文件，点击就可以下载你的 .config 文件

进阶用法

自定义源码
本仓库默认使用LEDE的源码进行环境搭建，你可以通过修改 ./github/workflows/make-config.yml 中的相关变量来修改代码源
自定义固件
你可以通过在 ./github/diy-part1.sh 或 ./github/diy-part2.sh 中添加自定义命令来让Actions在 make menuconfig 前或后执行，从而修改固件的默认 IP、主机名、主题、添加 / 删除软件包等
自定义软件源
如果你需要添加自定义的软件源，你可以修改./github/feeds.conf.default。例如，在该文件中添加 src-git luci https://github.com/coolsnowwolf/luci 以使用LuCI中的软件包

Credit / 鸣谢

Config Maker 介绍

Sun, 29 Jan 2023 00:00:00 +0000

这是我Github中的一个项目的介绍及使用方式

Config-Maker

Openwrt building config maker / Openwrt编译配置生成工具

Intro / 说明

这个项目通过Github Actions来构建你的Openwrt编译配置文件(.config)，使你免受自行搭建编译环境的痛苦，并可以配合 P3TERX/Actions-OpenWrt 等在线编译项目，在完全不搭建编译环境的情况下编译自己的固件。

By this project, you can make your own Openwrt build config file by the GitHub Action, save your time from setting up the build environment.

Usage / 用法

English

Openwrt building config maker

Make your own Openwrt build config file by the GitHub Action, save your time from setting up the build environment.

Usage

Click HERE to create a new repository
Select Make Config File on the Actions page
Click the Run workflow button
Refresh the page and click the lastest Make Config File action to access its log
Click on the build job on the left sidebar

Wait for the SSH connection to Actions job to be executed at this page, and information like the following will appear:

  To connect to this session copy and paste the following into a terminal or browser:
  CLI: ssh McuGhq5PvktJyr53WHFsyjLMW@nyc1.tmate.io
  URL: https://tmate.io/t/McuGhq5PvktJyr53WHFsyjLMW
  TIPS: Run 'touch /tmp/continue' to continue to the next step.

then follow the tips to SSH to Actions. (If you are using a web terminal and get a black screen, just press Ctrl+C)

Type cd openwrt && make menuconfig in the terminal to start building your .config file
After you finishing your work, type touch /tmp/continue in the terminal then exit the terminal, the rest of the work will be done automatically
~~Star this repo, then it will be done faster~~
After all the work is done, you will see OpenWrt_config in Artifacts on the Action Summary page, just click and download it

Advanced Usage

custom source code
This repo will use LEDE’s source code to build the environment by default, you can change it in file .github/workflows/make-config.yml
custom fireware envs
You can change your firmware’s default IP, hostname, theme, add/remove packages and so on by adding command in ./github/diy-part1.sh and ./github/diy-part2.sh
custom feeds source
You can add your own feeds by modifying ./github/feeds.conf.default. For example, add src-git luci https://github.com/coolsnowwolf/luci to use the packages of LuCI

中文

Openwrt编译配置生成工具

通过Github Actions来构建你的Openwrt编译配置文件(.config)，免受自行搭建编译环境的痛苦，并可以配合 P3TERX/Actions-OpenWrt 等在线编译项目，在完全不搭建编译环境的情况下编译自己的固件。实际上，此项目就是从 P3TERX/Actions-OpenWrt 分离出的的模块的改良版

用法

点击这里生成一个新的仓库
在Actions页面中，选择 Make Config File
点击 Run workflows
刷新页面后，你将会看到Actions执行了新的工作，点击它以进入日志页面
点击左侧边栏中的 build

在这个页面上等待Actions执行到 SSH connection to Actions ,然后你会看到类似下面的信息：

  To connect to this session copy and paste the following into a terminal or browser:
  CLI: ssh McuGhq5PvktJyr53WHFsyjLMW@nyc1.tmate.io
  URL: https://tmate.io/t/McuGhq5PvktJyr53WHFsyjLMW
  TIPS: Run 'touch /tmp/continue' to continue to the next step.

点击URL链接或者在命令行中输入上面的ssh命令，就可以与Actions建立SSH连接（如果你进入网页终端时黑屏，按下Ctrl+C即可）

在终端中输入 cd openwrt && make menuconfig ，然后就可以开始构建你的配置文件了
完成并保存你的配置后，在终端中输入 touch /tmp/continue 命令就可以关闭终端了，剩下的工作会自动完成
~~给这个项目点一个 star 会让工作进行得更快~~
所有工作结束后，点击左侧的 Summary ，可以看到一个 Openwrt_config 文件，点击就可以下载你的 .config 文件

进阶用法

自定义源码
本仓库默认使用LEDE的源码进行环境搭建，你可以通过修改 ./github/workflows/make-config.yml 中的相关变量来修改代码源
自定义固件
你可以通过在 ./github/diy-part1.sh 或 ./github/diy-part2.sh 中添加自定义命令来让Actions在 make menuconfig 前或后执行，从而修改固件的默认 IP、主机名、主题、添加 / 删除软件包等
自定义软件源
如果你需要添加自定义的软件源，你可以修改./github/feeds.conf.default。例如，在该文件中添加 src-git luci https://github.com/coolsnowwolf/luci 以使用LuCI中的软件包

Credit / 鸣谢

编译一个Openwrt固件

Sun, 27 Nov 2022 00:00:00 +0000

Openwrt 固件编译

基于 Ubuntu22.04.1 桌面版（Vmware）

安装编译环境依赖

先更新apt软件列表

 sudo apt full-upgrade -y && sudo apt update -y

通过apt安装依赖

 sudo apt install -y ack antlr3 aria2 asciidoc autoconf automake autopoint binutils bison build-essential bzip2 ccache \
 cmake cpio curl device-tree-compiler fastjar flex g++-multilib gawk gcc-multilib gettext git git-core gperf haveged \
 help2man intltool lib32gcc-s1 libc6-dev-i386 libelf-dev libglib2.0-dev libgmp3-dev libltdl-dev libmpc-dev libmpfr-dev \
 libncurses5-dev libncursesw5-dev libpython3-dev libreadline-dev libssl-dev libtool libz-dev lrzsz mkisofs msmtp nano \
 ninja-build p7zip p7zip-full patch pkgconf python2.7 python3 python3-pip qemu-utils rsync scons squashfs-tools \
 subversion swig texinfo uglifyjs unzip upx upx-ucl vim wget xmlto xxd zlib1g-dev

首次编译

以下操作需在非root用户进行 以下操作需在非root用户进行 以下操作需在非root用户进行

设置系统代理并为git设置代理

 git config --global http.proxy socks5://192.168.7.3:7890
 git config --global https.proxy socks5://192.168.7.3:7890

通过这个网址获取github的IP并修改/etc/hosts如下

 IP github.com
 IP www.github.com

拉取源码

 git clone https://github.com/coolsnowwolf/lede.git openwrt

添加自定义源

 cd ~/openwrt
 cat >> feeds.conf.default <<EOF
 src-git kenzo https://github.com/kenzok8/openwrt-packages
 src-git passwall https://github.com/xiaorouji/openwrt-passwall
 EOF

更新并拉取

 ./scripts/feeds update -a
 ./scripts/feeds install -a

单独添加软件包（可选）

例：添加fcgiwrap用于包装luci

 git clone https://github.com/yhfudev/openwrt-fcgiwrap.git package/feeds/packages/fcgiwrap

更改主题（可选）

 # 删除自定义源默认的 argon 主题
 rm -rf package/lean/luci-theme-argon

 # 部分第三方源自带 argon 主题，上面命令删除不掉的请运行下面命令
 find ./ -name luci-theme-argon | xargs rm -rf;

 # 针对 LEDE 项目拉取 argon 原作者的源码
 git clone -b 18.06 https://github.com/jerrykuku/luci-theme-argon.git package/lean/luci-theme-argon

 # 替换默认主题为 luci-theme-argon
 sed -i 's/luci-theme-bootstrap/luci-theme-argon/' feeds/luci/collections/luci/Makefile

设置路由器默认的LAN IP（可选）

 # 设置默认IP为 192.168.7.1
 sed -i 's/192.168.1.1/192.168.7.1/g' package/base-files/files/bin/config_generate

两种编译方式：

云端编译（仅制作.config文件）

配置编译选项
```
1
make menuconfig
```

通过以下命令获得 `seed.config` 配置文件

# 若在调整OpenWrt系统组件的过程有多次保存操作，则建议先删除.config.old文件再继续操作
rm -f .config.old

# 根据编译环境生成默认配置
make defconfig

# 对比默认配置的差异部分生成配置文件（可以理解为增量）
./scripts/diffconfig.sh > seed.config

使用 GitHub Actions 云编译

本地编译

配置编译选项
```
1
make menuconfig
```

下载编译所需的软件包

make download -j8 V=s

编译
```
1
make -j1 V=s
```
若第一次编译，建议使用单线程编译，可提高编译成功率，但过程非常漫长，取决于机器的性能

编译完成后固件输出路径： /openwrt/bin/targets/

二次编译

更新本地编译环境

# 更新软件列表、升级软件包
sudo sh -c "apt update && apt upgrade -y"

# 拉取最新源码
cd ~/openwrt && git pull

# 更新下载安装订阅源包含的软件包
cd ~/openwrt
./scripts/feeds update -a && ./scripts/feeds install -a

清理旧文件

# 删除/bin和/build_dir目录中的文件
make clean

如果要更换架构，建议执行以下命令深度清理 /bin 和 /build_dir 目录的中的文件 (make clean) 以及 /staging_dir、/toolchain、/tmp 和 /logs 中的文件

make dirclean

如果需要对组件重新调整，则先删除旧配置

rm -rf ./tmp && rm -rf .config

再次配置编译选项

make menuconfig
make download -j8 V=s

编译

make -j$(nproc) || make -j1 || make -j1 V=s

二次编译可以优先使用多线程，报错会自动使用单线程，仍然报错会单线程执行编译并输出详细日志

利用x86架构在Vmware中进行测试
- 路由刷机有风险，编译后可先使用x86版本的固件使用vmware测试，平台选择x86，目标image选择vmdk。vmware新建虚拟机使用已存在的磁盘，硬盘一定要选择IDE格式，不要选择SCSI
1. 安装qemu-img并转换
```
1
2
sudo apt-get install qemu-utils
qemu-img convert -f raw openwrt-x86-generic-combined-ext4.img -O vmdk openwrt-x86-generic-combined-ext4.vmdk
```
2. 创建虚拟机
  
  将上面转换后的.vmdk文件传输到主机上，在Vmware新建虚拟机按如下步骤操作：自定义 - 稍后安装操作系统 - Linux - 版本 Ubuntu - 选择虚拟机位置 - 处理器核心数 1 - 内存 1024M - 网络类型 NAT - I/O控制器类型 LSI Logic - 磁盘类型 IDE - 使用现有虚拟磁盘 - 选择转换好的.vmdk - 安装并启动
3. 修改内网配置
  
  查看IP地址
```
1
ifconfig br-lan
```
  查看虚拟机NAT模式的子网地址
  
  修改 /etc/config/network 配置br-lan的IP地址，使之处于NAT模式所在的子网
  
  重启虚拟机后主机应可以ping通虚拟机
4. 配置外网访问
  
  在主机中访问web管理界面，默认密码: password
  
  选择Network -> Interfaces，点击br-lan后面的Edit按钮
  
  将协议修改为DHCP client，并点击Switch protocol按钮，否则修改不会生效
  
  此时ip地址已经发生了改变，所以web连接断掉了，在虚拟机中查看br-lan地址，并ping外网，已经可以ping通了

参考：
使用 GitHub Actions 云编译 OpenWrt
OpenWrt 固件编译教程
 零基础编译OpenWrt看这一篇就够了
 openwrt编译教程及踩坑记录
 openwrt编译笔记
 从零开始编译OpenWRT(LEDE)固件教程(Lean大源码)x86固件个性化自定义修改

《JavaScript 二十年》推荐语

Sat, 10 Apr 2021 00:00:00 +0000

雪碧（doodlewind）邀请我给《JavaScript 二十年》写的推荐序。

JavaScript 常常被戏称为一门偶然成功的玩具语言。而实际上，它出身名门，更是成长在聚光灯之下。纵观历史，有资格被标准化的编程语言甚少，它因此成为多方角力的战场，却也有幸同时得到业界与学界先驱的亲传。时至今日，我们甚至难言是它背负了太多妥协，还是这些妥协才成就了它呢。以史为鉴，或许你会有自己的答案。

— 黄玄，Facebook 软件工程师（编程语言、JS 引擎、前端基础设施）、中文前端社区活跃成员。

作为一个前端，看不懂@黄玄的几乎每一个回答，只有我自己吗？

Sun, 05 Jul 2020 00:00:00 +0000

这篇文章转载自我在知乎上的回答

我也看不懂。

对于任何一个我有一定了解的领域，我都知道一大堆我看不懂的东西。反而是对于那些我一点都不了解的，我甚至都说不出来我不懂什么。

有的时候我会觉得，在我眼里还只有前端的时候，我还更自信更爱分享一点。可能因为那时候我能感知到的「边界」就只有 2^4 = 16 这么大，还觉得自己满打满算已经懂了 4 吧。打个比喻的话就是觉得自己已经能干活了，但还想再了解下 JS 引擎、浏览器、框架等的工作原理，或许还想再多学点后端和移动端当个全栈？总之 4/16 已经是「全集」的 25% 了，觉得自己还挺棒棒哒。

结果等我的「知识」真成长到 16 时，才意识到「欧，原来计算机科学还有这么多东西」？而且每个领域水都深得很，教科书里引论文，论文里再引更多论文，像一棵棵树般不断分形出去…认知的「边界」也相应的长到了 2^16 = 65536。自己懂的东西只占 0.02%，一下觉得自己真是什么都不是了。我把这个瞎掰称之为「认知的指数成长理论」。

而我能做的就是学会与这样的认知和平共处。Prof. Matt Might 画的那篇 The illustrated guide to a Ph.D[1]（「博士是什么」) 让我意识到个体在「人类所有知识」面前的渺小，而「成长」的过程，大概就是在那个愈发巨大的「看不懂集」里，挑选出你还愿意继续去「探索」的那些「子集」吧。

「认知的指数成长理论」

作为一个前端。

在相当长的一段时间里，「前端」既是我的兴趣也是我的职业，那时好像不需要有区别 —— 从早早在阿里实习，到还没毕业就在微影带团队，小中大的公司都待过，活动也参加了不少。其实如果就这样专注于「作为一个前端」，应该现在也还混得不赖吧。

可是偏偏你就发现，那个「看不懂集」的边缘总在发着光 —— 群友形容有一部人的动力在于「理解驱动」，我想了想，那或许是我「半路出家」积累的太多疑惑需要解答；又或许，我可能只是想要「旅游」吧 —— 在高三从重点班理科生转了艺术，在阿里从交互又转了前端，可我还有好奇的理论、又或者还没尝试过系统编程，又或者是下一个有趣的产品形态……想去探索下一件事的欲望总是逐渐盖过了舒适感，你听说了那个学科，你听说了那个文明，你听说了风暴中心，可是你不去看，你就永远不知道那里是什么样。

最近多次被问及「前端团队的方向是什么？」才突然意识到自己有一段时间不这样思考了 —— 这个问题天生就带着市场环境强调精细化分工的倾向，而相反地，有时我惊讶于 Facebook 内部「疏于管理」得就像个开源软件的菜市场。前端作为一个子领域当然需要特定的技术设施与人员的专长，但或许你我的职业/兴趣发展、公司的组织架构、软件的开发方式，不一定都非得绑上。

我想要追求的状态不只是能继续做我已经擅长的事情，我还想去探索那些我想要尝试但可能还不太擅长的事情，最后再顺便把钱赚着 —— 就美其名曰「技术自由」吧。所以你说，我是前端吗，我不是前端吗？

「专注」和「职业」又何必要是一个双射呢？

回答。

答题不是我的工作，我不做培训也不靠这个赚钱，不愿花时间琢磨如何哗众取宠，
只是有时恰好有新的感悟可以分享，有时恰好有有趣的题目能引发我的思考；

答题只是博客之外另一个用写作自我沉淀的地方罢了，难免会有点自我，
但反正也只是写给同路人看的，也为了发现与认识更多的同路人；

我不愿意「只」为了答题而写字，也还是希望言之有物，
这道题如此 meta，是回答给谁呢，又或是回答给我呢？

结语。

有的时候需要赚钱，有的时候需要理想。
你是更想做一位黑客与画家，还是想站在 Hilbert 第十问题的肩上。

Gödel 说太难，人生又怎会比 Peano 简单。
面对的 tradeoff 太多，才只能去近似一个想要的模样。

说得都是走心的话，走脑还是多看书吧。
如果能给在读的你带来一点不同思考，那便是对一个碳基生物所能给予的最高嘉奖了。

黄玄，二〇二〇年七月五日，于美国圣塔克拉拉。

「有一部分朋友知道，我现在在探索的事情跟前端关系还挺近的啦。 希望我也能突破我自我驱动的局限性，多做一些更落地的事情吧！共勉！」

参考

The illustrated guide to a Ph.D http://matt.might.net/articles/phd-school-in-pictures/

Data Representation - Floating Point Numbers

Sun, 21 Jun 2020 00:00:00 +0000

In the last episode we talked about the data representation of integer, a kind of fixed-point numbers. Today we’re going to learn about floating-point numbers.

Floating-point numbers are used to approximate real numbers. Because of the fact that all the stuffs in computers are, eventually, just a limited sequence of bits. The representation of floating-point number had to made trade-offs between ranges and precision.

Due to its computational complexities, CPU also have a dedicated set of instructions to accelerate on floating-point arithmetics.

Terminologies

The terminologies of floating-point number is coming from the scientific notation, where a real number can be represented as such:

1.2345 = 12345 × 10 ** -4
         -----   --    --
  significand^   ^base  ^exponent

significand, or mantissa, 有效数字, 尾数
base, or radix 底数
exponent, 幂

So where is the floating point? It’s the . of 1.2345. Imaging the dot can be float to the left by one to make the representation .12345.

The dot is called radix point, because to us it’s seem to be a decimal point, but it’s really a binary point in the computers.

Now it becomes clear that, to represent a floating-point number in computers, we will simply assign some bits for significand and some for exponent, and potentially a bit for sign and that’s it.

IEEE-754 32-bits Single-Precision Floats 单精度浮点数

https://en.wikipedia.org/wiki/Single-precision_floating-point_format

It was called single back to IEEE-754-1985 and now binary32 in the relatively new IEEE-754-2008 standard.

       (8 bits)             (23 bits)
sign   exponent             fraction
  0   011 1111 1    000 0000 0000 0000 0000 0000

 31   30 .... 23    22 ....................... 0

The sign part took 1 bit to indicate the sign of the floats. (0 for + and 1 for -. This is the same treatment as the sign magnitute.
The exponent part took 8 bits and used offset-binary (biased) form to represent a signed integer. It’s a variant form since it took out the -127 (all 0s) for zero and +128 (all 1s) for non-numbers, thus it ranges only [-126, 127] instead of [-127, 128]. Then, it choose the zero offset of 127 in these 254 bits (like using 128 in excess-128), a.k.a the exponent bias in the standard.
The fraction part took 23 bits with an implicit leading bit 1 and represent the actual significand in total precision of 24-bits.

Don’t be confused by why it’s called fraction instead of significand! It’s all because that the 23 bits in the representation is indeed, representing the fraction part of the real significand in the scientific notation.

The floating-point version of “scientific notation” is more like:

(leading 1)
   1. fraction  ×  2 ^ exponent   ×  sign
      (base-2)           (base-2)

So what number does the above bits represent?

S     F   ×  E  =  R
+  1.(0)  ×  0  =  1

Aha! It’s the real number 1! Recall that the E = 0b0111 1111 = 0 because it used a biased representation!

We will add more non-trivial examples later.

Demoing Floats in C/C++

Writing sample code converting between binaries (in hex) and floats are not as straightforward as it for integers. Luckily, there are still some hacks to perform it:

C - Unsafe Cast

We unsafely cast a pointer to enable reinterpretation of the same binaries.

float f1 = 0x3f800000; // C doesn't have a floating literal taking hex.
printf("%f \n", f1);   // 1065353216.000000 (???)

uint32_t u2 = 0x3f800000;
float* f2 = (float*)&u2;   // unsafe cast
printf("%f \n", *f2);      // 1.000000

C - Union Trick

Oh I really enjoyed this one…Union in C is not only untagged union, but also share the exact same chunk of memory. So we are doing the same reinterpretation, but in a more structural and technically fancier way.

#include <stdint.h>
#include <inttypes.h>
#include <math.h>

float pi = (float)M_PI;
union {
    float f;
    uint32_t u;
} f2u = { .f = pi };  // we took the data as float

printf ("pi : %f\n   : 0x%" PRIx32 "\n", pi, f2u.u);  // but interpret as uint32_t
pi : 3.141593
   : 0x40490fdb

N.B. this trick is well-known as type punning:

In computer science, type punning is a common term for any programming technique that subverts or circumvents the type system of a programming language in order to achieve an effect that would be difficult or impossible to achieve within the bounds of the formal language.

C++ - `reinterpret_cast`

C++ does provide such type punning to the standard language:

uint32_t u = 0x40490fdb;
float a = *reinterpret_cast<float*>(&u);
std::cout << a;  // 3.14159

N.B. it still need to be a conversion between pointers, see https://en.cppreference.com/w/cpp/language/reinterpret_cast.

Besides, C++ 17 does add a floating point literal that can take hex, but it works in a different way, using an explicit radix point in the hex:

float f = 0x1.2p3;  // 1.2 by 2^3
std::cout << f;     // 9

That’s try with another direction:

#include <iostream>
#include <stdint.h>
#include <inttypes.h>

int main() {
  double qNan = std::numeric_limits<double>::quiet_NaN();
  printf("0x%" PRIx64 "\n", *reinterpret_cast<uint64_t*>(&qNan));
  // 0x7ff8000000000000, the canonical qNaN!
}

Representation of Non-Numbers

There are more in the IEEE-754!

Real numbers doesn’t satisfy closure property as integers does. Notably, the set of real numbers is NOT closed under the division! It could produce non-number results such as infinity (e.g. 1/0) and NaN (Not-a-Number) (e.g. taking a square root of a negative number).

It would be algebraically ideal if the set of floating-point numbers can be closed under all floating-point arithmetics. That would made many people’s life easier. So the IEEE made it so! Non-numeber values are squeezed in.

We will also include the two zeros (+0/-0) into the comparison here, since they are also special by being the only two demanding an 0x00 exponent:

             binary                |    hex    |
--------------------------------------------------------
0 00000000 00000000000000000000000 = 0000 0000 = +0
1 00000000 00000000000000000000000 = 8000 0000 = −0

0 11111111 00000000000000000000000 = 7f80 0000 = +infinity
1 11111111 00000000000000000000000 = ff80 0000 = −infinity

_ 11111111 10000000000000000000000 = _fc0 0000 = qNaN (canonical)
_ 11111111 00000000000000000000001 = _f80 0001 = sNaN (one of them)

      (8 bits)  (23 bits)
sign  exponent  fraction
  0      00     0 ...0 0  = +0
  1      00     0 ...0 0  = -0
  0      FF     0 ...0 0  = +infinity
  1      FF     0 ...0 0  = -infinity
  _      FF     1 ...0 0  = qNaN (canonical)
  _      FF     0 ...0 1  = sNaN (one of them)

Encodings of qNaN and sNaN are not specified in IEEE 754 and implemented differently on different processors. Luckily, both x86 and ARM family use the “most significant bit of fraction” to indicate whether it’s quite.

More on NaN

If we look carefully into the IEEE 754-2008 spec, in the page35, 6.2.1, it actually defined anything with exponent FF and not a infinity (i.e. with all the fraction bits being 0), a NaN!

All binary NaN bit strings have all the bits of the biased exponent field E set to 1 (see 3.4). A quiet NaN bit string should be encoded with the first bit (d1) of the trailing significand field T being 1. A signaling NaN bit string should be encoded with the first bit of the trailing significand field being 0.

That implies, we actually had 2 ** 24 - 2 of NaNs in a 32-bits float! The 24 came from the 1 sign bit plus 23 fractions and the 2 excluded were the +/- inf.

The continuous 22 bits inside the fraction looks quite a waste, and there would be even 51 bits of them in the double! We will see how to made them useful in later episodes (spoiler: they are known as NaN payload).

It’s also worth noting that it’s weird that the IEEE choose to use the MSB instead of the sign bit for NaN quiteness/signalness:

It seems strange to me that the bit which signifies whether or not the NaN is signaling is the top bit of the mantissa rather than the sign bit; perhaps something about how floating point pipelines are implemented makes it less natural to use the sign bit to decide whether or not to raise a signal. – https://anniecherkaev.com/the-secret-life-of-nan

I guess it might be something related to the CPU pipeline? I don’t know yet.

Equality of NaNs and Zeros.

The spec defined a comparison with NaNs to return an unordered result, that means any comparison operation except !=, i.e. >=, <=, >, <, = between a NaN and any other floating-point number would return false.

No surprised that most (if not every) language implemented such behaviours, e.g. in JavaScript:

NaN !== NaN   // true
NaN === NaN   // false
NaN >  1      // false
NaN <  1      // false

Position and negative zeros, however, are defined to be equal!

+0 === -0  // true, using the traditional JS equality
Object.is(+0, -0)  // false, using the "SameValue" equality

In Cpp, we can tell them apart by looking at its sign bit:

#include <cmath>   // signbit

cout << (+0.0f == -0.0f);     // 1
cout << std::signbit(-0.0f);  // 1
cout << std::signbit(+0.0f);  // 0

IEEE-754 64-bits Double-Precision Floats

https://en.wikipedia.org/wiki/Double-precision_floating-point_format

Now, the 64-bit versions floating-point number, known as double, is just a matter of scale:

       (11 bits)            (52 bits)
sign   exponent             fraction
  0

 63   62 .... 52    51 ....................... 0

IEEE-754-2008 16-bits Short Floats

The 2008 edition of IEEE-754 also standardize the short float, which is neither in C or C++ standard. Though compiler extension might include it.

It looks like:

1 sign bit | 5 exponent bits | 10 fraction bits
S            E E E E E         M M M M M M M M M M

References

Data Representation - Integer

Fri, 19 Jun 2020 00:00:00 +0000

Integers, or whole number from elemental mathematics, are the most common and fundamental numbers used in the computers. It’s represented as fixed-point numbers, contrast to floating-point numbers in the machine. Today we are going to learn a whole bunch of way to encode it.

There are mainly two properties to make a integer representation different:

Size, of the number of bits used. usually the power of 2. e.g. 8-bit, 16-bit, 32-bit, 64-bit.
Signed or unsigned. there are also multiple schemas to encode a signed integers.

We are also gonna use the below terminologies throughout the post:

MSB: Most Significant Bit
LSB: Least Significant Bit

Prerequisite - `printf` Recap

We will quickly recap the integers subset of usages of printf. Basically, we used format specifier to interpolate values into strings:

Format Specifier

%[flags][width][.precision][length]specifier

specifier
- d, i : signed decimal
- u : unsigned decimal
- c : char
- p: pointer addr
- x / X : lower/upper unsigned hex
length
- l : long (at least 32)
- ll : long long (at least 64)
- h : short (usually 16)
- hh : short short (usually 8)

using namespace std;
int main()  {
  cout << "Size of int = "<< sizeof(int) << endl;
  cout << "Size of long = " << sizeof(long) << endl;
  cout << "Size of long long = " << sizeof(long long);
}
Output in 32 bit gcc compiler: 4 4 8
Output in 64 bit gcc compiler: 4 8 8

`inttypes.h` from C99

Also in cppreference.com

// signed int (d or i)
#define PRId8     "hhd"
#define PRId16    "hd"
#define PRId32    "ld"
#define PRId64    "lld"

// unsigned int (u)
#define PRIu8     "hhd"
#define PRIu16    "hd"
#define PRIu32    "ld"
#define PRIu64    "lld"

// unsigned hex
#define PRIx8     "hhu"
#define PRIx16    "hu"
#define PRIx32    "lu"
#define PRIx64    "llu"

// uintptr_t (64 bit machine word len)
#define PRIxPTR   "llx"

Unsigned Integers

The conversion between unsigned integers and binaries are trivial. Here, we can represent 8 bits (i.e. a byte) as a hex pair, e.g. 255 == 0xff == 0b11111111.

#include <stdint.h>    // uintN_t
#include <inttypes.h>  // PRI macros

uint8_t u8 = 255;
printf("0x%02" PRIx8 "\n", u8); // 0xff
printf(  "%"   PRId8 "\n", u8); // 255

Signed Integers

Signed integers are more complicated. We need to cut those bits to halves to represent both positive and negative integers somehow.

There are four well-known schemas to encode it, according to signed number representation of wikipedia.

Sign magnitude 原码

It’s also called “sign and magnitude”. From the name we can see how straightforward it is: it’s basically put one bit (often the MSB) as the sign bit to represent sign and the remaining bits indicating the magnitude (or absolute value), e.g.

  binary   | sign-magn |  unsigned
-----------|-----------|------------
0 000 0000 |    +0     |     0
0 111 1111 |    127    |    127
...
1 000 0000 |    -0     |    128
1 111 1111 |   -127    |    255

It was used in early computer (IBM 7090) and now mainly used in the significand part in floating-point number

Pros:

simple and nature for human

Cons:

2 way to represent zeros (+0 and -0)
not as good for machine
- add/sub/cmp require knowing the sign
  - complicate CPU ALU design; potentially more cycles

Ones’ complement 反码

It form a negative integers by applying a bitwise NOT i.e. complement of its positive counterparts.

  binary   |  1s comp  |  unsigned
-----------|-----------|------------
0000 0000  |     0     |     0
0000 0001  |     1     |     1
...
0111 1111  |    127    |    127
1000 0000  |   -127    |    128
...
1111 1110  |    -1     |    254
1111 1111  |    -0     |    255

N.B. MSB can still be signified by MSB.

It’s referred to as ones’ complement because the negative can be formed by subtracting the positive from ones: 1111 1111 (-0)

  1111 1111       -0
- 0111 1111       127
---------------------
  1000 0000      -127

The benefits of the complement nature is that adding becomes simple, except we need to do an end-around carry to add resulting carry back to get the correct result.

  0111 1111       127
+ 1000 0001      -126
---------------------
1 0000 0000        0
          1       +1     <- add carry "1" back
---------------------
  0000 0001        1

Pros:

Arithmetics on machien are fast.

Cons:

still 2 zeros!

Twos’ complement 补码

Most of the current architecture adopted this, including x86, MIPS, ARM, etc. It differed with one’s complement by one.

  binary   |  2s comp  |  unsigned
-----------|-----------|------------
0000 0000  |     0     |     0
0000 0001  |     1     |     1
...
0111 1111  |    127    |    127
1000 0000  |   -128    |    128
1000 0001  |   -127    |    129
...
1111 1110  |    -2     |    254
1111 1111  |    -1     |    255

N.B. MSB can still be signified by MSB.

It’s referred to as twos’ complement because the negative can be formed by subtracting the positive from 2 ** N (congruent to 0000 0000 (+0)), where N is the number of bits.

E.g., for a uint8_t, the sum of any number and it’s twos’ complement would be 256 (1 0000 0000):

1 0000 0000       256  = 2 ** 8
- 0111 1111       127
---------------------
  1000 0001      -127

Becuase of this, arithmetics becomes really easier, for any number x e.g. 127 we can get its twos’ complement by:

~x => 1000 0000 bitwise NOT (like ones’ complement)
+1 => 1000 0001 add 1 (the one differed from ones’ complement)

Cons:

bad named?

Pros:

fast machine arithmatics.
only 1 zeros!
the minimal negative is -128

Offset binary 移码

It’s also called excess-K (偏移 K) or biased representation, where K is the biasing value (the new 0), e.g. in excess-128:

  binary   |  K = 128  |  unsigned
-----------|-----------|------------
0000 0000  |   -128(-K)|     0
0000 0001  |   -127    |     1
...
0111 1111  |    -1     |    127
1000 0000  |     0     |    128  (K)
1000 0001  |     1     |    129
...
1111 1111  |    127    |    255

It’s now mainly used for the exponent part of floating-point number.

Type Conversion & `Printf`

This might be a little bit off topic, but I want to note down what I observed from experimenting. Basically, printf would not perform an implicit type conversion but merely interpret the bits arrangement of your arguments as you told it.

UB! stands for undefined behaviors

uint8_t u8 = 0b10000000; // 128
 int8_t s8 = 0b10000000; // -128

printf("%"PRIu8 "\n", u8);          // 128
printf("%"PRId8 "\n", u8);          // 128 (UB! but somehow it's got right)
printf("%"PRId8 "\n", (int8_t)u8);  // -128

printf("%"PRId8 "\n", s8);          // -128
printf("%"PRIu8 "\n", s8);          // 4294967168 (UB!)
printf("%"PRId8 "\n", (uint8_t)s8); // 128

printf("%"PRIxPTR "\n", s8);             // ffffff80
printf("%"PRIxPTR "\n", (uintptr_t)s8);  // ffffffffffffff80

Char & ASCII

Traditionally, char is represented in the computer as 8 bits as well. And really, ASCII is only defined between 0 and 127 and require 7 bits. (8-bit Extended ASCII is not quite well popularized and supported.)

It’s more complicated in extension such as Unicode nowadays, but we’ll ignore it for future posts dedicated for char and string representation.

So how is a char different with a byte?

Well, the answer is whether a char is a signed char (backed by int8_t) or a unsigned char (backed by uint8_t) is… implementaton-defined. And most systems made it signed since most types (e.g. int) were signed by default.

N.B. int is standard-defined to be equivalent to signed int. This is not the case of char.

That’s why you often see such typedef such as:

typedef unsigned char Byte_t;
typedef uint8_t byte_t;

to emphysize the nature of byte should be just plain, unsigned, bits.

References

My Programming Languages Spectrum

Tue, 05 May 2020 00:00:00 +0000

React Hooks 是否可以改为用类似 Vue 3 Composition API 的方式实现？

Fri, 03 Apr 2020 00:00:00 +0000

这篇文章转载自我在知乎上的回答

不能，因为是很不一样的心智模型（Mental Model）。我觉得很多同学只关注到了这两套 API 在功能上都能复用逻辑的相似点，而低估了两个框架体系「大背景」上的差异。

正文开始前我先声明一下，

一是本文观点不代表公司。我是觉得圈子里不认同 Hooks 的声音太多了（比如 @徐飞叔叔、 @贺师俊贺老、 @题叶同学等老朋友 no offensive），所以自愿出来平衡一下。
二是我确实好久没有实际写前端了，React Hooks 实战还不多，Vue 3 只草草略读了 Composition API RFC 与之前中文的 Vue Function-based API RFC（所以对细节并不太熟悉。）欢迎大家务必指正、补充（与要求补充）。

引言

「框架/库是编程语言上的抽象」，并不意味着框架的设计就无法跳脱出其实现语言的习语（idioms）与编程范式（paradiams）。

得益于 JavaScript 几个非常 Lisp 的特点：一等公民函数、动态类型、一定的宏支持（比如 Babel），这几年前端框架的发展可以看到很多编程语言设计的思路：框架成为了由 DSL 与 API 构成的特定语法（syntax）、从 JavaScript 中扬弃以及由 API 附加的语义（semantics）、支撑这套体系运作的运行时（runtime）、以及所表达的心智模型（mental model）的结合。

Vue 3, “Reactive (Closure-based) OOP”

先来看 Vue（本文中的 Vue 主要指使用 Composition API 下的 Vue）

const Counter = {
  setup(initialProps) {
    const count = reactive({count: 0}) // or `ref(0)`
    const inc = () => { count.value++ }
    return {count, inc}
  }
  template: "..."
}

Vue 为组件挑选的语义是「对象」：Composition API 的setup 只会调用一次并返回一个对象合并到 Counter 组件上，这个对象与其成员全都是持久的引用，包括保存在 inc 闭包中的状态 count 也是持久的。渲染则是对组件上的template 域的具象化。

Vue 附加的核心语义是（基于可变数据的）「响应式（reactive）」：状态 count 是一个响应式对象，inc 进行状态更改的方式是对 count 直接修改，状态更改的结果是执行所有观察者（watcher）的逻辑，包括重渲染和执行副作用（watchEffect) ，都是基于这个语义纳入数据流。

有的同学（比如题主）说，如果改成返回一个 render 函数，直接利用闭包来保存组件变量，你还说这是对象的语义吗？

return (props) => <a onClick={inc}>{count.value}</a>

是的。Vue 的实现需要保持这个函数与其闭包的引用不变（referential identity）来满足状态被持久化的语义，是 JavaScript 用闭包模拟对象私有属性的经典模式[1]。（「闭包是穷人的对象，对象是穷人的闭包」）

为了帮助你理解，如果我们有一门假想的 Vue 语言的话……

// hypothetical Vue lang
component Counter (props) {    // constructor
  @reactive count = 0          // field
  inc() { count.value ++ }     // method
  render() { return <a onClick={inc}>{count.value}</a> }
}

是不是有基于类的 OOP 内味了？只不过 Vue 的对象是基于单例（或者闭包）而非类（或原型）实现，以及成员是被施过 reactive 魔法哒！这里我们展示了如何从概念上将 Vue 归约到 OOP 的心智模型，不过需要注意得是，Vue 整个体系（考虑状态管理、数据流控制）的心智模型有很多 FP 的东西在里面，仍然和传统观念（比如 Java）的 OOP 有很大差别，[2][3]。

Vue 运行时的核心是 dependency tracking（依赖追踪），首先它使得 reactive 语义对用户相对 implicit（隐式），依赖都是自动收集的，大大降低了用户的心智负担。其次呢它非常细的跟踪粒度配合 Vue 使用静态化程度比较高模板使得重渲染自动就可以做到非常精准。

总结起来，Vue 在组件方面的心智模型仍然是「拥有数据与行为且自响应式的对象」，只要照着这个思路去想，就比较好理解「为什么 Vue 的状态可以使用可变数据结构」、「为什么 Vue 需要ref 包装值类型」，以及 RFC 在对比 React Hooks 时提到的「为什么 Vue 更接近大家习惯的 JS 」（这点比较主观就是了）、「为什么 Vue 的 GC 压力会更小」、「为什么 Vue 不需要手动声明依赖」等优势的由来了。

React, “Purely (Semi-Monadic/Algebraic) FP”

再来看 React（本文中的 React 主要指 Hooks API 下的 React）

function Counter(props) {
  const [count, setCount] = React.useState(0);
  const inc = () => setCount(count + 1)
  return <a onClick={inc}>{count}</a>
}

React 为组件挑选的语义是「函数」，每次渲染都是对 Counter 这个函数的一次真实调用。每次 useState 都会执行并从 React 那取出当前的状态给 count，每次也都会创建一个新的 inc 函数（故其闭包中捕获的也是新的 count 值）。

React 附加的核心语义是一个副作用受控的「执行上下文（evaluation context）」，通俗得说就是 React 这个运行环境：状态 count 每次都要从 React 上下文中取出，inc 对状态更改的方式是用 setCount 更新上下文里的内容，状态更改的结果是这个函数会被重新调用，调用时函数就会从新的上下文中获得新的状态、进行重渲染和安排上（schedule）受上下文控制的副作用（useEffect) 。

为了帮助你理解，如果我们有一门假想的 React 语言的话……

// hypothetical React lang Ⅰ
component Counter = (props) =>      // function
  @context.state(1) {                  // context provides `get_or` and `put`
    count <- get_or(0)              // get from context (or use default value)
    let inc = () => put(count + 1)  // callback can update the context
    return <a onClick={inc}>{count}</a>
  }

是不是有基于 Monad 的 Haskell 内味了？只不过 React 把 API 做得完全不需要你弄懂这些复杂的东西[4]。如果你不熟悉 Monad 这个纯 FP 的概念，我们可以先不严谨[5]得把它当做文中的「上下文」。扔出 M-bomb 的原因是大家通常把它作为在纯 FP 中处理副作用的标杆，帮助我们展示如何把 React 归约到纯 FP。

有的同学（比如@题叶）会疑惑，这怎么跟我认得的「纯函数」不一样呢，这也是「纯函数式编程」吗？其实如果我们把语法糖展开就会变成：

component Counter = (props) =>
  context.state(1).get_or(0).then([count, put] => {  // `then` is monadic bind.
    let inc = () => put(count + 1)
    return <a onClock={inc}>{count}</a>
  }).unwrap() // assuming it's safe.

有没有想到同样被称作 Monad，具备异步上下文的 Promise？

再（过度）简化一些，你可以想象成最直白的 state-passing 风格（实际上 2018 年时 React 团队就这么考虑过类似的 API [6]，也是 Seb 的理论基础之一[7]）:

component Counter = (props, stateMap) => {
  let count = stateMap.get(1, or=0);
  let inc = () => stateMap.set(1, count + 1); // functional update
  return <a onClick={inc}>{count}</a>
}

不过，React 从实现到 API 设计都更靠近与追求[8]的心智模型是一个相对较新的纯 FP 概念 —— Algebraic Effect（代数作用），虽然名字听起来相当迷惑，但其实它在描述副作用上比 Monad 反而更不花哨（少一些 ceremony），理解起来也更加容易，Dan 有一篇给 JSer 看的很易懂的博文[9]并且有中文翻译[10]。我们可以先把它当作「可以重新恢复的 try-catch 」

为了帮助你理解，如果我们又又又又有一门假想的 React 语言的话……

// hypothetical React lang Ⅱ
component Counter = (props) => {
  let count = perform getState(1),or=0); // 1. `perform` "throw" effects to the context
                                                // 4. resume with the continuation to here
  let inc = () => perform putState(1, s=count + 1);
  return <a onClick={inc}>{count}</a>
}

// call site
try <Counter /> handle  // 2.try-handle pattern match effects
                        // 3. get state from the context and then resume
| getState(key, or) => resume with context.state(key) ?? or
| putState(key, s) => context.state(key)=s; resume with void

是不是有感觉一些了？我们从组件里「扔出去」去更改「执行上下文」里的状态，然后再「恢复」回来……

即便 React 已经很努力的降低了 API 的门槛，但其思维的愈加纯函数式确实会在更多程序员眼里非常「离经叛道」。

所以为什么我们需要「纯函数式编程」？抛开大家可能已经熟悉的声明式、数据流清晰、局部推理、易于组合外，其背后的学术理论支撑使得其在编译期静态分析与优化、运行时高并发高并行友好方面都有极高的理论上限和上升空间（近年编程原理的理论研究完全是被函数式编程霸占得）

React 现在运行时侧重的核心是 cooperative multitasking（协作式多任务），来为 React 加入 concurrency（并发）、schedule（调度）等底层能力。很多同学只听说过后端的高并发，其实像多任务操作系统这样的「终极 UI」就是一个高并发且依赖诸如分时（time-slicing）、优先处理（re-priortizing）等进程调度的场景。React 希望把这些技术带给 UI 开发者（比如 Suspense，比如 Selective Hydration，比如 RN 新架构中的 Fabrics），第一步是运行时用 Fiber 架构重写不依赖原生调用栈，第二步就是用 Hooks 解决 Class API 在纯度上约束力不够的问题。不纯的组件在 React 并发模式下很容易出现数据竞态（data race）的问题。

总结起来，React 在组件方面的心智模型是「副作用受上下文托管的纯函数」，只要照着这个思路去想，就比较好理解「为什么 React 中倾向于使用不可变数据结构」、「为什么 useEffect 默认会执行 cleanup 来保持幂等性」、「为什么 React 需要 useRef 这样的跨渲染 ref cell 机制来做 mutable ref 」、「为什么 React 的性能优化是 useMemo, Memo 这样 FP 风格的 memoization 」、「为什么 React 需要 useMemo useCallback 来保持 referential identity 」、「为什么 React 需要用依赖列表来进行 cache invalidation」等问题了。

补充

2016 年底时我就觉得 React 和 Vue 的（一个）终极区别在于「可变」还是「不可变」。

Seb 在 Hooks 发布后收到一些质疑的 brain dump[11] 里写到：

It’s interesting because there are really two approaches evolving. There’s a mutable + change tracking approach and there’s an immutability + referential equality testing approach. It’s difficult to mix and match them when you build new features on top. So that’s why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we’ve decided to focus on this direction and see where it leads us.

不全部翻译了，说得是整个「大前端」社区里最主要的两条道路分歧：

可变 + 变更追踪。包括 Vue，Angular，
不可变 + 引用相等性。包括 React，Elm，(Flutter?)

这个分歧其实与我之前行文的侧重点「为组件挑选的语义」其实是对偶的：

前者是对传统 Imperative Programming（包括 OOP）思路的一种增强，加入了 Reactivity。
后者则是传统 Functional Programming 在 UI 开发领域的发扬光大（Functional Reactive Programming?)，只不过 React 是用一种比较「超越 JS 语言」的方式去实现得。

这两条道路从底子就很不同，所以才造成了 React 和 Vue 在大家眼里的渐行渐远吧。

不过最近多看了一些 Svelte、 SwiftUI[12]和 Jetpack Compose[13]也开始有了一些殊途同归的感觉，Props 无论是跟着 View 销毁还是函数参数总是暂时性的输入，States 无论跟着组件实例还是置外总必须是持久化的，至于怎么判断更新，像 array.push 这种 mutable state 的场景总是不好 track 得，于是就只能各显神通了：React 想通过 reference equality 自动、Vue 3 想通过 Proxy 自动，但其实只要能把 change set 搞出来就行，Vue2/Svelte/SwiftUI/Compose 这些让用户手动给提示得不是也工作得好好得吗？只要能把变更集算出来传递给视图层，那视图层就只管更新（rerender/rebuild/recomposite）就是了。

补充 2

如果是在重度依赖 Flux (Vuex/Redux, whatever) 的场景，可能 Vue/React 会更像是一个只负责渲染的 dumb/passive layer，这种时候上文说的 Vue/React 的差异会显得不明显，因为大部分的状态管理（state management）都已经扔到更外层去做了。

不过，考虑需要组件内聚的场景（即组件自己有私有状态，需要 self-conatined）以及 React Hooks / Vue Composition APIs 开始接管更多（除状态之外的，比如 IO）副作用，这种差异只会变得越来越明显得。

以上。

参考

JavaScript 模块化七日谈 - 黄玄的博客 Hux Blog https://huangxuan.me/2015/07/09/js-module-7day/
如何理解尤雨溪在 2019 VueConf 上所讲的 UI 类框架很少使用面向对象的特性这件事？- 黄玄的回答 https://www.zhihu.com/question/328958700/answer/714287394
前端是否适合使用面向对象的方式编程？- 黄玄的回答 https://www.zhihu.com/question/329005869/answer/739525268
React Hooks的引入会对之后的React项目开发产生什么影响？- 黄玄的回答 https://www.zhihu.com/question/302916879/answer/536846510
React 上下文的组合是通过调用顺序在运行时里维护一个链表而非基于参数化多态的层叠（比如 Monad Transformer）来表达，可以看到都是线性的。
State-passing Style Hooks https://mobile.twitter.com/acdlite/status/971598256454098944
https://github.com/reactjs/react-basic
可以把上下文或者 Hooks 的调用视为一次 stack unwinding + resume continuation。同样，考虑 row polymorphism 也是线性的。
Algebraic Effects for the Rest of Us https://overreacted.io/algebraic-effects-for-the-rest-of-us/
通俗易懂的代数效应 https://overreacted.io/zh-hans/algebraic-effects-for-the-rest-of-us/
Why React https://gist.github.com/sebmarkbage/a5ef436427437a98408672108df01919
https://swiftwithmajid.com/2019/06/12/understanding-property-wrappers-in-swiftui/
https://developer.android.com/jetpack/compose/state#remember

2019 年 PWA(Progressive Web App) 凉了吗？

Tue, 19 Nov 2019 00:00:00 +0000

这篇文章转载自我在知乎上的回答

作为 PWA 在国内的早期布道者与实践者，我觉得挺凉的。以下都是主观感受且 opinion is my own。

PWA（甚至整个 Web）似乎被 Google（Chrome）与「第三世界」绑到一起去了。「这世界还有多少人没上过网、没有 4G、没有 3G……印度、印度尼西亚、非洲、乌干达……」这便是这两年的 Chrome Dev Summit 的主旋律了。

而这或许也是现在整个 Google 的主旋律吧，于是便成了 Chrome 和 Chrome 的产品经理们的 KPI（OKR），美其名曰「为了互联网的下一个十亿用户」。我不是说关心第三世界这事不好，但问题在于你一边嘴上说着「Open Web、大家的 Web」，一边身体上却只想着把 Web 变成「你想要的那个 Web」，然后把其他 Web 的发展方向都「耽误」掉了。

PWA 的商业案例至今为止，我感到 legit（正当）的仍然只有 twitter，是真正在按一个「给所有用户都能用」的标准来做的。Airbnb/Pinterest/Spotify 可能能及格，而其他的则要么是商业互吹（吹一波走人），要么就是利益（市场导向）一致（Instagram 以及逐年增多的印度系产品）。

我相信很多开发者和我一样对 PWA 的期待本来是作为 RN/Flutter 等跨平台开发的 alternatives（替代品），结果现在连几年前的 hybrid 方案 Cordova (Phonegap)、Electron的实力都没到，不要说国内各种自家魔改的 Webview（容器、小程序）了。两年的时间本足以做大量这方面的工作 —— 留学前我还担心是不是两年后我就跟不上 PWA 的发展了，结果现在根本就没什么大动静 —— 每年 CDS 确实都仍然会扔几个新的有关 capability 的 API 出来，但是跟了这么多年 Chrome Dev Summit 我也算是看清了这秀场的节奏 —— 每年扔出来的东西吧，第二年弃坑 2/3，剩下 1/3 就是遛狗 —— virtual list 说了几年了？类似 portal 这样的 navigation-transition 说了几年了？file system API 说了几年了？我吐槽的点在于，Google（Chrome）你年年画大饼，最后大部分有真正投入资源的，全是你那「第三世界」新兴市场相关的。作为 Web 开发者你一定知道，有多少新 API 落地到我们日常开发了？

Don’t just take my word. 你应该自己去听听这两年的 Chrome Dev Summit，是不是绝大多数的场次都围绕着对「低配」内存、CPU、网络环境的优化 —— 俨然一副「Web 就只适合在这么不行的地方用」的气息，你一个 Web 开发者都要针对 L1/L2 Cache 优化了你说我们怎么不直接写汇编呢？而单纯谈论 CSS/JS 等 Web 技术的发展，不带使用场景 bias 的场次比例一年比一年少。至于 WebAssembly/WebGL/WebXR？—— who TM care? 人家连网都上不了你还想玩 3D/VR 游戏？人家连电脑都没有你还想在 Web 上做生产力工具？WebAssembly 场靠着 Google Research 有点 AI 项目讲了讲 thread 和 SIMD 都能让我感觉到一种与整场会议违和的尴尬……而 3D, VR and AR 总共加起来就做了个六分钟的小短片播，把我乐得。

所谓的 Fugu Project（PWA 项目在 Google 的代号）在我眼里就是 Google「让 Web 成为他们在第三世界的开发平台」而准备的一个项目：官方提及 PWA 最爱提的用户场景不是 Web 的可索引性、可链接性、甚至都不是即开即用（on-demand），而是「用户因为没有流量和 wifi 所以不愿安装原生应用」。那几个 dev advocate 反正每年就做些 P 用都没有的玩具在那里自娱自乐自 high，做个扫雷游戏然后说我们这个一路支持到功能机用键盘来玩哦……一向亲 JSer 的 Addy Osmani 的 Adaptive Loading 场也来一句「我们要为开 Data Saver（省流量模式、无图模式）的用户做优化！」，这世界大概是又回去到了 WAP 的时代吧……而项目带头人 Alex Russell，即便我仍然很感激您过去对 Web 的影响和贡献，但您这两年来动不动就是「怼框架怼友商怼空气」—— 你们这些垃圾框架，居然要 50 KB！你们这些垃圾开发者，用什么框架，Use the platform！（i.e. 用我们的 Web Component （的框架）！）你们这些垃圾浏览器，还不快点支持我们要的 API！ —— 都是你们伤害了我的 W(K)e(P)b(I)！司马昭之心，路人皆知。

quote @尤雨溪

他们在乎的是「下一个十亿用户」，中国显然不在其中呢

即便你也是 Web 开发者我也是 Web 开发者，但显然我们已经不是 Google（Chrome）想要支持的 Web 开发者了：当无数 Web 开发者起来为 JS 社区在应用框架的先进性上探索，当我们想要证明 Web 在今天的硬件上终于可以挑战 Native，当我们想要在动画和交互上挑战当年的 Flash，当我们认为 Web 技术已经可以胜任众多桌面软件，当社区期待 Web 能够积极跟进下一个新兴技术（whatever that is）甚至担当重任，当国人在谈论着 5G 的到来 Web 开发者应该做什么时 —— 这个当年挟 Web 以令 OS，推动 Web 平台 state-of-the-art 的 Google（Chrome）却变得让我不认识了。

Web 自诞生以来便就是个同床异梦的地方 —— Web 也因此永垂不朽；而对于 PWA 能在当前 Google 的主导下迅速发展成一个有竞争力的跨平台开发解决方案这事儿，或许只是其中的又一黄粱美梦罢了。

补充两点：

我支持「小程序」的产品价值，也支持 PWA 作为 Web 开放标准一部分的技术价值。
PWA 目前主要靠 Google 推动是客观事实，且 PWA 的发展必须依赖平台（浏览器）的参与。

Younger Blog

使用Vercel进行blog部署

Github Pages 在中国大陆的访问速度较慢，并且在博客更新后，部署速度很慢，对于静态资源的更新不利。

Vercel 拥有更好的访问体验已经更快的部署速度，因此弃用Pages而使用Vercel。

Intro / 说明

Usage / 用法

Openwrt building config maker

Usage

Advanced Usage

Openwrt编译配置生成工具

用法

进阶用法

Credit / 鸣谢

Config Maker 介绍

这是我Github中的一个项目的介绍及使用方式

Config-Maker

Intro / 说明

Usage / 用法

Openwrt building config maker

Usage

Advanced Usage

Openwrt编译配置生成工具

用法

进阶用法

Credit / 鸣谢

编译一个Openwrt固件

Openwrt 固件编译

安装编译环境依赖

首次编译

两种编译方式：

云端编译（仅制作.config文件）

配置编译选项

通过以下命令获得 seed.config 配置文件

使用 GitHub Ac­tions 云编译

本地编译

配置编译选项

下载编译所需的软件包

编译

二次编译

更新本地编译环境

清理旧文件

编译

利用x86架构在Vmware中进行测试

安装qemu-img并转换

创建虚拟机

修改内网配置

配置外网访问

《JavaScript 二十年》推荐语

作为一个前端，看不懂@黄玄 的几乎每一个回答，只有我自己吗？

我也看不懂。

作为一个前端。

回答。

结语。

参考

Data Representation - Floating Point Numbers

Terminologies

IEEE-754 32-bits Single-Precision Floats 单精度浮点数

Demoing Floats in C/C++

C - Unsafe Cast

C - Union Trick

C++ - reinterpret_cast

Representation of Non-Numbers

More on NaN

Equality of NaNs and Zeros.

IEEE-754 64-bits Double-Precision Floats

IEEE-754-2008 16-bits Short Floats

References

Data Representation - Integer

Prerequisite - printf Recap

Format Specifier

inttypes.h from C99

Unsigned Integers

Signed Integers

Sign magnitude 原码

Ones’ complement 反码

Twos’ complement 补码

Offset binary 移码

Type Conversion & Printf

Char & ASCII

References

通过以下命令获得 `seed.config` 配置文件

使用 GitHub Actions 云编译

作为一个前端，看不懂@黄玄的几乎每一个回答，只有我自己吗？

C++ - `reinterpret_cast`

Prerequisite - `printf` Recap

`inttypes.h` from C99

Type Conversion & `Printf`