dvsilch

https://github.com/GitAlias/gitalias
除了 diff 会用 IDE 以外，基本还是通过命令行 alias 完成 git 操作

策划运营要有这种想法，开发真享大福了

举个例子：游戏业界逐渐开始使用的 ECS 架构就是以面向数据编程为核心搭建
具体介绍看 https://github.com/SanderMertens/ecs-faq

@LaTero Unity 7 前几天刚说要 Unified Rendering 了，但感觉也得过一两个 LTS 才能用

@songunity 老项目咋用华佗啊，拆 dll 拆到死

3999 拿下无界 15x 暴风雪，屏幕颜色有点偏黄得自己调，键盘背光的设置也有点问题（关闭了但时不时会被恢复成打开的状态，而且开机时设置不管用一定会亮，估计不是写进 bios 里的？），只有白色外观让人不爽，除此以外都挺不错的

@tsanie
是我笔误了，确实是 CancellationTokenSource(cts)，C#里可以做到外部内部各提供一个 cts ，初始化时将两个 cts link 然后将 ct 链式传递到各个异步任务，需要中断时任意一个 cts 直接 cancel 即可，会立刻走到 catch OperationCanceledException 的分支

但我看了一下 AbortController 似乎只能做到对 fetch api 执行中断，不是特别符合我当前的业务场景...不仅仅是网络请求，还有一些文件的读取、以及等待用户另外输入的 Promise 。这部分如果取消不掉的话，我能想到的形式就是要么把各个 reject 动态推入移出队列，要么就是每一轮异步任务结束后判断状态。两种做法都感觉不太合理，所以目前的做法是暂时跟 #9 #15 一样写一个自定义的 generator 来统一这部分逻辑，有空再去研究研究 rxjs 的实现

@jones2000 是的，其实跟上面使用 generator 的思路一致

@pursuer
@amlee
看了下，AbortSignal 大概也需要在没做支持的异步任务上套一层 Promise 或者每次异步结束前做状态检测，也不是很好

@rabbbit
@Projection
rxjs 之前也有看过，无奈确实是经验不够一眼瞎。目前看来对我而言修改起来最简单的方式，就是自己写一个 generator 然后来手动判定是否执行下一步了，至少把状态判断统一在了 for 循环里，少写不少东西