OO_Unit4 大结局
Part 1 两阶类图在正向建模过程中的作用 OO_pre 的惨痛教训告诉我在着手写代码之前理清楚架构是非常有必要的，但具体怎么理是个问题。我在前几个单元的训练中已经形成了一套自己的设计习惯，大致上是设计文档 -> 手绘草图 -> 代码骨架 的流程，所以刚开始接触 UML 这种很高级但很死板的模式就让我有点消化不良了。所以我依旧遵守了自己的设计习惯，把 UML 的绘制放到了最后的最后 —— 完全由 AI 完成。 架构 && 对比分析最终的代码设计和UML模型设计之间的追踪关系 图书管理系统涉及到两方：人和图书馆，书（BookCopy 类）和预约（Appointment 类）被他们用来周旋，Library 类作为人和图书馆之间的沟通渠道，一方面管理图书馆麾下的 BorrowReturnOffice、Bookshelf、AppointmentDesk 和人员信息表 UerTable，一方面为人类读者提供各种办理业务的接口。 
OO_Unit3
Part 1 两阶类图在正向建模过程中的作用 OO_pre 的惨痛教训告诉我在着手写代码之前理清楚架构是非常有必要的，但具体怎么理是个问题。我在前几个单元的训练中已经形成了一套自己的设计习惯，大致上是设计文档 -> 手绘草图 -> 代码骨架 的流程，所以刚开始接触 UML 这种很高级但很死板的模式就让我有点消化不良了。所以我依旧遵守了自己的设计习惯，把 UML 的绘制放到了最后的最后 —— 完全由 AI 完成。 架构 && 对比分析最终的代码设计和UML模型设计之间的追踪关系 我的 UML 是跟着代码一起更新的，每个 HW 只在最后更新一次。 大模型辅助正向建模 我很快意识到大模型不太会画 UML，而且鉴于我没有去学 UML 的规则，我也没法指导大模型学习。 把学长/学姐的 UML 源码和我写好的代码一起喂给 AI 是一个相当不错的选择，不过很偷懒。 我在这里第一次接触了 skill 撰写，整合了 UML 绘制的基础要求与 OO 作业的特殊要求（关键词、MainClass）。 Part 2 架构设计思维的演进 测试思维的演进 在这个学期开始之前，我对评...
OO_Unit2
OO_Unit2 [TOC] 架构 && 迭代 在 如何让系统结束 上，我起初采用了递进式 kill：MainCtrl 判定总队列空且已经输入了 NULL，就 kill 自己并把信号传递给所有电梯，电梯接收到 kill 信号后根据自身进度决定什么时候结束。这个方法很不靠谱，导致我互测被刀了。我后来根据水群里大佬们的分享改成了计数器：维护一个 cntRest 之类的东西，+1，-1，当 cntRest == 0 并且已经输入了 NULL 就全终止，优雅又省心。 锁 && 同步块 总结分析三次作业中同步块的设置和锁的选择，并分析锁与同步块中处理语句之间的关系 调度器设计 我在 HW6 一共写了 4 种调度器算法，在 HW6 跑了 2000 轮数据排名：影子电梯 > (自由竞争，随机) > 均匀。所以我在 HW7 只迭代了影子电梯。 我没有尝试纯启发式，但互测的时候看到我们房多数人用了纯启发，不过没有发现性能很好的。不知道有没有人纯启发很成功的。 均匀分配 均匀分配全方位倒第一，所以很快就被淘汰了。 Random 随机性能挺好的（...
OO_Unit1
架构 && 迭代 应用最显著的是递归下降的设计思路。 我的代码分为三块儿大陆：Parser 负责解析，ast 负责整理，algebra 负责输出。三块儿大陆各司其职，立志于不做重复的工作。Parser 里的 Expr 类是它们的交通枢纽。 定义两个数据结构：ast 语法树（以递归下降的形式存储表达式），和 algebra 多项式（以标准输出结构的形式存储表达式）。 如图：尾缀带 Factor 都是继承 Factor 类的（这里无疑用接口更好，但问题不大就懒得改），其中 NumFactor 和 VarFactor 是叶子Factor，别的都是非叶 Factor。Expr 很特殊，它既包含非叶 Factor 的方法，又包含根节点的方法。 Factor 需要实现的方法，最初只有一个：toPoly。 algebra 的标准输出形式最初是 num*x^exponent。 对于输入的表达式字符串，我首先通过 Parser 将它转化成 ast 的形式来存储。ast 是一棵树，它会自动把表达式整理成递归下降的结构，可以通过根节点 Expr 访问。在 Expr 实现 toPol...
OS_lab4
内核在哪里 这其实是早在上上个 Lab 就该明白的问题，但由于本人的懒惰和得过且过当时想想算了就这样吧。 内核并非只有一个（指针指着）。虽然对我来说内核很像一群不靠谱的小朋友背后的大家长，一旦小朋友（用户进程）做了什么非法操作（访问不该访问的东西）或者打起来（都想拿 CPU）就要弹出来收拾残局，然后默默撤离。但实际上，内核和用户进程并非众星拱月的关系，而是进程包含内核的关系。**内核是存在于所有进程地址空间中的一段代码，每个进程的页表里，都包含对同一份内核空间的映射。**这样相比于 “众星拱月” 的好处在于陷入内核时不必费劲切换到另一个地址空间（经历了上个 Lab 的狼狈就知道这个操作挺麻烦的）。当然虽然内核映射一直存在于进程页表里，但平时是不能访问的，要陷入内核才能访问。 当然，这只是操作系统的一种设计，并非绝对，不过现在的主流操作系统一般都是这样设计的。 进程与内核间的关系并非对立：在内核处理进程发起的系统调用时，我们并没有切换地址空间（页目录地址），也不需要将进程上下文（Trapframe）保存到进程控制块中，只是切换到内核态下，执行了一些内核代码。可以说，处理系统调用时...
OS_lab1
Thinking 1.1 尝试分别使用实验环境中的原生 x86 工具链（gcc、ld、readelf、objdump 等）和 MIPS 交叉编译工具链（带有mips-linux-gnu- 前缀，如 mips-linux-gnu-gcc、mips-linux-gnu-ld），重复其中的编译和解析过程，观察相应的结果，并解释其中向 objdump 传入的参数的含义。 写了一个 night.c 程序作为实验对象： 123456#include <stdio.h>int main () { printf ("Night fall...\n"); printf ("Sleep well, wake well."); return 0;} 1gcc -E night.c 前面补上一大堆 typedef 、struct 和 extern 1gcc -c night.c night.o ： 反汇编： 1objdump -DS night.o > night.s 文件格...
神秘 bug
在注入里修改了夜间模式下的头像，后又突发奇想在本土 iml 下启用了头像旋转效果。然后我得到了……一轮旋转的满月。 特此纪念。