doxygen 确实正解，楼主想 diy 的话也可以考虑直接用 `clang++ -ast-dump=json` 这样的方式把语法树导出成结构化的文本，然后自己处理。

这事你问业主业主也一堆希望临停车费贵一点的，所以别指望业主委员会了。。。我们业主群前几天聊这个事来着，最激进的是希望禁止外部临停的（怕剐蹭了找不到人），车位比例 1:1.2 的情况下，车位并不是很紧张，依然一堆人对临停车是一种反感的态度。

plantuml 应有一席之地，然后 kroki 作为一个 diagram as code 的集成服务，可以指数级提高生产力。

可以实现这样的业务，区块链也可以有效防御权威节点作弊，但如楼上所说，美国大选这种规模的活动，面临的主要问题并不是这个，区块链技术也解决不了它面临的实际问题。

这个技术其实存在更有价值的应用场景。

手持 m1 max 的 mac studio 一点都不香了

set 关键字应该是正解，其次应该是 set 的含义在 dict 这个场景并不能很好地表达这个方法的目的。

dict 是键值对的集合，往集合里添加内容应该是 put 或 insert 。

没有实际游玩，听楼上的描述感觉像是服务端对局复盘演算的问题，斩杀的时候触发结算，结算前需要演算这场对局的战斗有没有人作弊，这个演算逻辑不管是因为计算资源不足还是代码 bug 导致请求超时都有可能造成短暂的闪断，然后排队机制又不让你断掉之后马上连上...

@guyeu 当然这个要求并不难实现，多部署无线网关就可以了。

@katwalk WiFi 就是举个例子，智能开关也有 2.4G 走 WiFi 的。除了华为那个电路载波的方案以外，市面上的智能开关都是无线控制，所以就要求无线覆盖到所有有开关的角落

都有服务端了，那肯定是有客户端的，在已有客户端的基础上封装一套 bot 来跑压测并不复杂。
我比较想知道 TCP 的话就不是 request-reply 那种消息模型了吧，传统的响应延时这种指标就不太好使了，你们用哪些指标来评估服务器的性能表现呢？

@diagnostics #50 默认情况下一个 runner 同时只会执行一个任务，所以不会出现任务之间互相影响的情况。速度的话，Linux 上的 docker 和 Mac/Windows 上的 docker 不是一个物种，具体情况还是要具体分析。

@diagnostics #46 gitlab 的 cicd 并不是必须用 docker 跑，gitlab-runner 支持很多种环境，而且允许用户自己注册自己的 runner 。docker 跑也不见得天然比 Jenkins 慢一个数量级。。。

release 的 ci 和 merge request 的 ci 可以用 rules 区分，rules 支持的规则就很多了，分支、事件源等等。。。这方面 Jenkins 使用的 webhook api 是很难和 gitlab 本身比的。

写 Kotlin 、Scala 和 Java 甚至还带点 C++的混合项目，用了 gradle 已经回不去了

1. 多模块的支持比 maven 好，虽然 maven 有优化这方面的计划，但随意增减模块不用先`mvn install`就可以成功构建体验感会好一些；
2. 增量构建在日常开发中的加速效果明显，如果你不用 IDEA 这么高级的东东，随时修改随时编译随时允许 UT 的体验感 maven 是比不了 gradle 的，如果用了 IDEA 这种高级货，那么 IDEA 的编译和 maven 的编译是基本上是冲突的，IDEA 编译会破坏 maven 的编译，两边就都没办法“增量了”；
3. 项目越花哨，对构建脚本的功能性要求就越强，就势必要自己写一些扩展，这方面 gradle 很容易，简单处理的话直接在 build.gradle{.kts}里写函数就好，但是 maven 就复杂多了，基本上都得新建项目（另外，现在 gradle 支持 Kotlin ，有 Android 开发经验的同学几乎没有上手难度）；
4. 依赖的管理，用 maven 的话，有一种操作是在 pom.xml 里定义许许多多版本号的 properties ，然后在各种地方用，但是没办法跨项目用，gradle 有一个更优雅的搞法叫 versionCatalogs ，写一个 TOML 文件之后可以把它导入到各个项目；

然而 maven 这种完全声明式的构建机制是最简单，人类读起来也最没有心智负担的，如果项目的复杂度没有到一定程度，maven 就是最棒的（虽然 gradle 也在发明自己的声明式 DSL ）

Vertx 的下一个大版本就有 @ProtobGen 了，这个不会干这种奇怪的事情

Conan 可解你忧

@284716337 操作系统，文件系统是什么？

你的目的是不要线程池阻塞？这里的阻塞不是一个很清晰的表述，假如它是指避免一个任务长期占用线程：
1. 对于计算密集型任务，唯一实际可用的办法是在逻辑里去检查线程的内部状态然后按照业务去处理（早期版本可以用一个叫`Thread.stop`的方法来暴力停止，但这不是一个生产可用的选项）；
2. 对于 IO 密集型任务，合理的实现都会响应`interrupt`信号，因此`cancel`方法就足够了。

实际上，更常见的需求是避免任务堆积导致内存压力，这种情况下：
1. 限制阻塞队列的长度，并设计合理的拒绝策略；
2. 解决资源瓶颈，缺 CPU 就加 CPU ，缺消费者就增加消费者节点。