Smach 是一个相当好用的 ros 上的基于状态机的任务级调度框架，但是在 ubuntu20.04 上能够运行 smach 核心程序但是却无法运行 smach_viewer 去调试状态机，解决方法之一是可以通过 ros 分布式通信机制和另一台 ubuntu18.04 的 melodic 机器建立分布式通讯，在 ubuntu18.04 上运行 smach_viewer 去调试状态机。或者也可以通过虚拟机代替 ubuntu18.04 的实体机。还有一种解决方案就是将上述虚拟机更换为更轻量级的 docker 容器。 smach 的作者在 github 的一篇 issue 上回答如下， For reference: I’m using ROS Noetic and SMACH visualization is something I wanted to have to display the current state of my FSM for easy introspection and bling. I could not update it to work in Noetic fo ...

出现该问题的原因是因为Ctrl+5为Fcitx重新载入配置的全局快捷键，删除该快捷键即可。

自上而下的语法分析 面临的问题 文法左递归 一个文法是含有左递归的，如果存在非终结符P P→PαP\to P\alpha P→Pα 当产生左递归时，词法分析流没有向前进行任何的推进，而语法树却在不断地进行扩展，此时会使得分析器陷入死循环，故需要避免左递归。 回溯问题 每一步的语法分析，都面临这多个侯选式的选取问题，分析过程中，当一个非终结符用某个候选匹配成功时，这种匹配只是暂时的，当下一步出错时且无路可选时，不得不进行“回溯”操作，而这种回溯操作需要恢复先前的分析结果比较消耗性能。 构造不带回溯的自上而下的分析算法 消除文法左递归 直接左递归消除 P→Pα∣βP\to P\alpha|\betaP→Pα∣β 其中α、β∈(VT∪VN)∗\alpha、\beta\in(V_T\cup V_N)^*α、β∈(VT​∪VN​)∗，β\betaβ不以A打头 则可改写为如下右递归形式 P→βP′P\to\beta P'P→βP′ P′→αP′∣εP'\to \alpha P'|\varepsilonP′→αP′∣ε 推广 假定关于P的全部产生式 ...

LL(1)文法 构造一个不带回溯的自上而下分析的文法条件 文法不含左递归 对于文法中每一个非终结符 A 的各个产生式的候选首符集两两不相交。即，若 A→α1∣α2∣...∣αnA\to \alpha_1|\alpha_2|...|\alpha_n A→α1​∣α2​∣...∣αn​ 则FIRST(αi)∩FIRST(αj)=ϕ(i≠j)FIRST(\alpha_i)\cap FIRST(\alpha_j)=\phi (i\neq j)FIRST(αi​)∩FIRST(αj​)=ϕ(i​=j) 对文法中的每个非终结符 A，若它存在某个候选首符集包含ε\varepsilonε，则 FIRST(αi)∩FOLLOW(A)=ϕi=1,2,3,...,nFIRST(\alpha_i)\cap FOLLOW(A) = \phi \newline i = 1,2,3,...,n FIRST(αi​)∩FOLLOW(A)=ϕi=1,2,3,...,n 如果一个文法 G 满足以上条件，则称该文法 G 为 LL(1)文法。

​ 这段时间，我读了一本书《轻松Scrum之旅》，这是一本小说般的一本技术书籍，作者使用了小说的形式来介绍Scrum的基本概念，并且使用了一个完整的项目来向读者呈现出书中的主人公关毅在实行Scrum框架中遇到的各种问题以及解决思路，使读者产生更加感性的认识。 ​ 在传统的瀑布模型中，我们需要按部就班完成从需求分析，软件设计，编码实现，软件测试到软件交付与维护等一系列步骤，一般前一个步骤完成不了后一个步骤就无法推进，而这层层推进需要对文档有着很强的依赖，然而软件开发中变数太多，有时经常会遇到客户的需求发生变更等异常情况，所以提前预测变得相当困难，故如今瀑布模式的软件开发已经不适用了，现在比较流行的软件开发方法就是敏捷开发(Agile)。 敏捷宣言 对于敏捷开发宣言中的每一项，我的理解如下： 个体和交互胜于过程和工具，这句话强调以人为本。 可以工作的软件胜于面面俱到的文档，这句话强调了文档的地位在敏捷开发中的地位被削弱，每个环节的沟通一般采用最有效的方式沟通，即面对面的交流，能产出能用的产品才是重要的。 客户合作胜于合同谈判，这一点强调了敏捷开发中，客户不能像订购日用品 ...

敏捷开发Scrum开发模式 Scrum与传统瀑布模式开发的区别 Plan 瀑布模式开发通常要花几个月时间来规划产品 Build 再花几个月时间研发产品 Test & Review 接着进行产品的测试与评审 Deploy 最后发布产品 ​ 瀑布模式的重点在于要求每个活动的结果都必须经过验证，并且只有经过验证之后才能作为后续开发的基础，这使得瀑布模型特别重视模型与文档，因为这是在可执行代码产生之前唯一能够用来验证的东西，所以瀑布模型被看做是“文档驱动”的，即按照文档的划分、产生和验证来规划、组织和控制开发活动。 ​ 如果市场需求或技术环境发生了变化，那么此时研发出的产品很可能无法满足市场需求，瀑布模式的开发在遇到这种变化时会出现很多问题。 ​ 首先，产品规划必须早于后续工作之前完成，在绝大多数案例中，规划环节结束时，并没有完全理解项目，但研发工作已经完成了。通常情况下，整个项目必须送回规划阶段，然后从头再来，否则研发人员就会因为不明白产品规划而受到批评。这种情况会反复出现，比如研发完成后，进行产品测试，发现问题就要重新开发，有时甚至需要重新规划产品。 ​ 同理， ...

First/Follow/Firstvt/Lastvt 集合 设文法 G G=(VT,VN,S,P)VN为非空有限的终结符号集VT为非空有限的终结符号集S为文法的开始符号或识别符号,代表语言最终要得到的语法范畴P为产生式规则G = (V_T,V_N,S,P) \\ V_N为非空有限的终结符号集 \\ V_T为非空有限的终结符号集 \\ S为文法的开始符号或识别符号,代表语言最终要得到的语法范畴 \\ P为产生式规则 \\ G=(VT​,VN​,S,P)VN​为非空有限的终结符号集VT​为非空有限的终结符号集S为文法的开始符号或识别符号,代表语言最终要得到的语法范畴P为产生式规则 2 型文法（上下文无关文法） 设文法 G，对 P 中的每个产生式限制形如 A→αA \to \alpha A→α 其中，A∈VN,α∈(VT∪VN)∗A \in V_N, \alpha \in (V_T \cup V_N)^*A∈VN​,α∈(VT​∪VN​)∗则称文法 G 为 2 型文法。 First 集合 设 G 为上下文无关文法，则 FIRST(A)={α∣A⇒α...,α∈VT}FIRST(A) = ...

MyBatis的基本使用情况的一次记录 添加依赖 Maven 中添加如下依赖 123456789101112131415<dependencies> <!-- MyBatis --> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.7</version> </dependency> <!-- PostgreSQL数据库驱动 --> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <version>42.2.24</ve ...

第十二届蓝桥杯C-C+±B组省赛-第一场-试题C-直线求解 首先定义表示一个顶点的结构体 1234567891011struct Point { int x, y; Point(int x, int y) : x(x), y(y) { } //向量减法 Point operator-(Point &point) const { return {x - point.x, y - point.y}; }}; 根据两点确定一条直线，我们可以写一个表示直线的类，使用直线的一般式Ax+By+C=0，表示任意的一条直线，其中数据成员有A,B,C三个系数，为了数据精度以及便于判断相等，尽量避免使用浮点数运算。 那么，已知两个整数坐标表示的点P1(x1,y1),P2(x2,y2)P_1(x_1,y_1),P_2(x_2,y_2)P1​(x1​,y1​),P2​(x2​,y2​)我们可通过两点式按如下数学推导，计算出直线方程。 根据两点式 \begin{equati ...