乐水榭 | 论极语易-Vonfry 博客

shell、eshell与工具

Sun, 13 Apr 2025 15:17:00 +0800

前言 Link to heading

近日，我对自己的 dotfiles 做了一定的调整。抛弃了用了多年的 alacritty，也抛弃了前一段刚刚切换到的 fish。而是转为使用 eshell 做为主力的 shell。在此，想就此决定的考虑进行讨论。

什么是 Shell？ Link to heading

最直观的想法，就是通过一条条指令来完成工作的一个黑乎乎的工具。在一个熟练工的手上，这一行为会比使用 gui 更加的高效，并且有更高的自由度。什么是一条条指令？本质上就是一个个非常小的程序，或是 shell 本身自带的一些指令。这些指令与工具，提供了与系统内核交互的能力。将需要通过 syscall 完成的事情，包装成了一个简单的程序，通过 shell 这一载体来完成程序调试从而给用户提供与操作系统交互的能力。所以，一开始学 Linux shell 时，学习就是这些非常小的工具与 shell 内置的指令，而它们基本上就是 linux 里常用 syscall 的直接包装。通过一些定制化的参数从而来提供对用户更加便利的控制。

所以，它被叫做壳，一个内核的壳。

为什么在 shell 中完成日常工作？ Link to heading

与 GUI 应用相比，在 shell 内我们面向的工具粒度更细，有更多的可控制项，以及最重要的，我们有可编程性的控制能力。GUI 能不能完成这样的行为？当然能，但是这非常依赖于开发者对整个程序的设计。而 shell 这一种行为，以非常简单明了的方式，直接提供了高自由度与系统交互的能力。并且这一行为通过脚本的方式可以直接进行批量操作，完成自动化。对于 GUI 程序，要完成这样的行为需要大量的设计，而且局限性会很高。shell 的语法设计同时保证了简单场景自动化的编写与用户交互的使用。相较于图形界面，它可以让我们脱离鼠标，并且在更加丰富的参数中按需使用。

当然，参数设计是由人来设计，图形界面也能完成这样的事情。就像不同的图形界面有不同的设置方式，shell 里每个程序的参数也有不同的设计风格，不论是哪种形式，都需要通过文档来进行知晓，程序也需要提供相应的可配置项。得益于历史发展，大部分命令行中的程序，其可控制参数的设计要优于图形程序，它们提供了更多选项。

C++ 异常与 stack unwind

Sat, 15 Mar 2025 20:20:29 +0800

Stack unwinding Link to heading

C++ 及一些编程语言的异常处理，需要涉及多个部分，比如待回收资源的信息、确定上层调用栈与处理回调位置等¹。通常他们通过 stack unwinding 的方式进行实现²，这主要是由于程序的执行基本都基于调用栈设计³。在编译生成的产物，会产生额外数据信息与异常处理相关的外部函数调用。在执行期，会有额外的数据查找、call stack 切换、资源管理等。

本文仅放置一些用参考资料，并不会在此处进行详细的说明。

其它的一些补充 Link to heading

像 rust 等语言本身不提供异常这一设计的语言，也可以通过直接使用 unwind 相关的 api 来完成异常。但通常，他们会使用其它的方案来处理这类问题，像 haskell 基于 monad 抽象的 maybe/either/... 来控制错误信息，rust 的 Result/Option/... 等。语言本身一般也设计了对应的语法糖。这类方法基本等同于手动判断错误信息，它们需要开发者有明确类型信息才能完成流程控制，但同时弱化了运行时的额外依赖，让开发者对代码有更好的控制。像 monad 这样的抽象，又同时可以保证较好的可读性。当然，这种设计会增加对开发者的门槛，在不具有相应的知识的情况下，可能会完全错误得理解程序逻辑。

像 go 这类语言，则就需要人工的来完成流程控制，需要显式的编写与处理。这一过程始开发过程中不可避免要编写大量的重复代码，显得冗余。但保证了程序员只需要较少的预备知识就可以充分理解代码逻辑。

虽然异常处理可以使编程便得非常方便，但不应该在语言中大量使用。因为异常处理的过程涉相对复杂，且开发者较难以细致的控制具体流程。同时，异常处理也会增加阅读代码时，对执行流程理解上的困难，特别是多层级传递与逻辑分支控制。进一步异常处理流程中使用的类型与正常流程会有差异，它们是非显示的，涉及跨层级与交错调用处理时，会减小整体流程的可读性。在高性能场景中，不应通过异常处理来进行正常的流程控制，因为这会产生不可控的资源管理与大量敏感的额外调用开销。对于性能并不是特别重要、仅在最外层提供用户交互下使用、单独设计的基于异常处理的行为控制层等场景，则可以较容易的形成易于编写与理解的功能。对于性能非敏感的场景，通过定义异常行为与正常行为的处理差异，明确异常行的为处理流，分离异常行为的处理层与控制逻辑，这类良好的设计可以有效的提高对程序的理解、框架的使用等，例如 langchain 中对于 agent 调用通过异常来做处理、http 框架中，通过异常来提前返回认证错误等。 ↩︎
stack unwinding 有多种实现方法，在此我们主要讨论的是 Hewlett-Packard 定义的一套 libunwind API。大部分语言一般会使用自己定义的 api 与 stack unwind 实现，如 common lisp 标准定义了异常处理的接口，以便于编写更符合其语言设计与实现方式的解决方案，而避免在通用 api 下完成较为复杂的功能，或是额外生成冗余的 CFI 信息。在 ffi 时，需要使用提供对应的结构信息与处理回调才能正确的截获异常。 ↩︎

Haskell 里 Generics, Template 与 Typeable 的一些杂思

Mon, 06 Jan 2025 19:32:20 +0800

前言 Link to heading

Haskell 提供了多种 meta program 的方案。就突然有点好奇，为什么会有这么多，实际使用的话以合优先。就随便思考了一下。

思考 Link to heading

TH 的特性在于编译期代码生成。类似于 rust 的 macro 与 lisp 的 macro。提供了输入的语法解析，然后再变换生成所需要的代码。理论上来说，所有有规则的生成都可以用 TH 来完成。但在一部分场景下这样的做法可能过于麻烦。最直接的使用就是基于给定的参数来生成相应的代码。即输入直接影响输出的代码。

Generics，典型的应用就是 aeson 这样的序列化库。我认为主要目的是观测不同结构的值进行变换，得到相似结构的值。相较于 TH 中去自己解析、创建相应的变换，Generics 可以直接通过输入对象的结构，来完成我们所想需要的工作。它更加针对的输入的结构，且输出的处理是跟随这一结构的。

Typeable 主要用于处理类型。如 Servant 库就通过类型标记来完成一些语义上的说明与代码生成。这里又可以分为运行期的与静态可确定的信息。类型本身在这里也可以比较判断，从而提供了更加灵活的运行期逻辑控制。相较于 TH，主要优点就是可以方便的拿运行期的值，与类型（静态的）相比较判断，从而进行分支。而分支的目标可能是由用户提供扩展，而非 TH 那样直接生成的特定代码（当然，TH 也能做到接受一些代码，给你包起来）。它更加注重的是运行期数据对应的行为，参数只是决定了计算的类别，而不决定具体的行为。

不论何种方式，TH 的方法基本可以处理所有问题，但生成代码也就意味着要处理的事情会更多。而 Generics 与 Typeable 则是针对一些不同场景而做出的特例。

dioxus中的hooks与runtime的scope

Fri, 27 Sep 2024 12:07:02 +0800

版本信息 Link to heading

由于写此文时 dioxus 还在快速开发中，内部实现和功能相对不那么稳定。本文所述此针对 0.5 版本而言。

前言 Link to heading

dioxus 是一个类似于 react 的响应式框架。其中 hooks 主要用于状态的处理。在官方文档中提及 hook 的声名必需是有序的，框架会依这个顺序完成一些事情，并区分 hook。但并没有说为什么得是有序的。再加之给出的例子说明均是 signal 等，而这些本身又是智能针对（或者说是基于引用计数的共享指针），就会让人困惑：已经使用共享指针了，为什么还需要使用这个 hook 的顺序呢？这一指针不已经保证了唯一性了么？

Scope Link to heading

通过阅读源码，可以发现 use_hook 本身是对 runtime 的一个包装，里面核心的点在于 scope 与其中的 hook。

首先，我们要明白什么是 scope。这也是文档中未详细提及的。简单来说，就是每个 vnode 与 component 创建时，都会创建一个 scope。而 scope 就像栈与树一样会进行层级嵌套。每个 scope 会管理自己内部的 hook 及各种状态的生命周期。

什么是 hook Link to heading

hook 其实就是一个初始化的块，会在第一次声名时加入到对应的 scope 中，并进行执行。执行后返回的必定是一个 State，而这个本身就是一个引用计算的智能指针。说白就是通过 scope 与 hook 来保证某一对象在相联的结点的生命周期内一定存活。

C++ 中结构体成员名的反射

Sat, 21 Sep 2024 16:17:20 +0800

起因 Link to heading

glaze 库可以实现

Read/write aggregate initializable structs without writing any metadata or macros!

是怎么做到的呢？

编译器的魔法宏与特殊处理 Link to heading

最开始我以为这是完全由语言自身特性实现的，但其实不是。这里面包含了编译器一些特殊处理。关键点在于 __func__、__PRETTY_FUNC__ 和 __FUNCSIG__。这些宏放在函数内会被编译器替换为函数名。如果函数是模板的话，实例化的类型信息会带进来。这样我们再加以配合 constexpr、consteval 可以拿到类名了。这样就能静态得完成类型名的反射。

但这样并不解决成员名。对于可以使用 aggregate initialization 的 POD 结构，我们可以通过模板的一些 trick 拿到初始化列表参数的长度。思路就是通过模板迭代配合 decltype 来检查是否可以初始化来得到最终的长度。有了成员数量后，就可以将结构体转为序列后使用变为 tuple 并使用 get 来取得对应的成员，当然就也可以取得这个成员的地址。把这个地址扔给上面那样特殊包装后的函数，就可以得到对应的名称了。当然，这个实现是受编译器具体实现影响。

阅读参考 Link to heading

glaze 源代码中 include/glaze/reflection/get_name.hpp
一篇如果用 aggregate 方式反射成员的博客，这是archive 链接。
一篇使用上述特殊宏完成类型名反射的博客，这是 archive 链接。

未来 Link to heading

现在的标准里有一个实验的 reflection TS，通过 reflexpr 与相关的模板函数可以方便的直接拿到成员信息，就不再需要这样绕圈了。

2024 始记

Sun, 14 Jan 2024 08:33:43 +0800

杂谈 Link to heading

又是新的一年，这个月也已经要过半了，最近总是回想一些过去的事情，就干脆写这么一篇博客，需要明确这是一篇非常个人的文章，内容也会比较杂乱。

Link to heading

自研究生毕业工作以来，总是会回想一些在读书时的事情。思考的原由主要自于业余时间的安排。初高中时期，业余基本都在干自己的事情，基本不会存在有特别无事做为的时间。大学与研究生期间则是沉迷与各类娱乐与定制化的系统，业余相对充裕。但自工作以来，经常就会出现无事所为的情况。这种现象以前当然也会出现，但很快就会避免了。这样的行为我认为有这么几点因素。首先以前在业余学习的东西都非常简单，回馈性强。因此可以连续的学习下去。再加上小时对新事物的好奇心更重。而现在学习的事物相较以前更为复杂，可能要用上几天的业余时间才能解决一个小问题，因此动力会渐渐消去。对于此，需要去寻找一个能重新激发动力的方案。一定得要认同的是，现在的水平与学习能力，相较以前是成长的，并非能力的下降，而更多的原于学习内容的困难增加与深入与源动力的激励。

第二个回想的主要点在于交友。最近发现其实我并没有特别能长期交谈的友人。初中一个，高中一个，大学没有，研究生一个。而高中的这一位基本已经失去了联系，毕业后也想去其有频繁的交流，但苦于没有话题，也想尝试聚会，但苦于时间安排，最终苦于不知对方对于我的态度，渐渐得有种无法交流的感觉。最近因为这件事让我很是苦恼。

交友 Link to heading

自小到大，都没有特别关注过人际关系。从来就是身边有哪些人就和哪些人交往，然后有话题了就在一起，没有话题了就一笑而过。自大学起，开始明确了哪些是不会长期交往的，哪些是可以长期交往的，但长期交往的往往也没有持续下去。如今，开始回想过去，初中的好友会在交往是因为对方的主动，与高中时的一些缘份，让我们现在还在保持着联系。而高中的朋友，在大学初期还有连续，而读研之后就慢慢变淡。没有话题，也从未在意，再想要去交谈时，发现和陌生人没有什么差异了。在现代可以随时沟通的环境下，离别有时并非那么显然，而是随着时间推移而产生的。当意识的时候，可能已经无法挽回了。

要如何才能保持交流呢？我认为分享是必要的，分享自己关心的，接受他人关心的。不一定得是双方共同的话题，因为我们已经通过某一话题产生了联系，现在已经过去了相识的阶段，又何必去强求呢？但是分享要从最开始就存在，淡化的关系，就算去谈论这些是否也不合适呢？是否他人已不在想要维继这段感情呢？是否他人只会觉得烦琐呢。对方也没有向我来分享，那么我对他而言可能已是过客。可能未来的某一天，我会在很久之后才得知以前的某件事情，甚至永远都不会得知。不可强求，否则对大家都不会愉快。

最近读了维特根斯坦传。就像罗素在初期的重要，在中后期几乎不在书中出现。而像《尼采在哭泣》一书，主角通过催眠的方法意识到了自己所求，又重新取回了生活。这都是一种选择。问题在于，现实生活要从合入手呢？开始是最难的。去年有一部我非常喜欢的片子，分离的乐队、重组的乐队，渴望一生的友谊。谁又不希望这种关系呢？可是，又如何去维持这种关系呢？真希望有这样一种缘份，能让我们重拾过去。但强求来的感情，又有何意义。亲密到陌生，再重回亲密感觉已不在可能，但又只能如此放弃么？放下是不易的，但更重要的是，不应轻言放下，至少需要一个能放下的理由。可以有悔恨，但不应该留有遗憾。

数据备份 Link to heading

这两日 sourcehut 被频繁的攻击。因为其不使用 js 的界面与邮件列表的开发流让我比较喜欢，近两年将我的个人项目全部迁移至此。而写这篇文章时，sourcehut 的服务器是 down 掉的，写完之后的 ci 与 page 也难以运行与同步。除此之外，再加上上述对过去的回忆，让我对数据备份有了一些想写的内容。

近日发现，我在高中时间的数据基本都丢失了。我最初的日记，是使用实体笔记本进行编写的，现在自然很好得保存在我的身边。自初三左右开始，在 win 上使用一个类 word 的一个软件编写，好像是叫 office diary。写了大概一年左右。高一使用 mac，切换到了 mac 上的一个软件，那个软件是通过 xml 格式进行存储的，但我已经完全忘记其软件名了。这两个日记的数据，在当时是有保存的。但于大学更换移动硬盘与软件期间导致了数据丢失。现在已经完全无法找回了。高三开始的日记是通过 mac 的 diary one 进行记录，一直持续到了研一。这部分数据后来导出到了 pdf，现在同时备份与我的移动硬盘内。同期还有使用印象笔记，那部分数据导出为了 html 与 pdf，现在也同样保存。现在的笔记与日记均基于 org-mode 与 git 了。会定期的归档备份。当然这个 git 仓库是纯本地的，仅在几台个人电脑间进行同步，且同步不是经过中央服务器，而是 ssh 反向代理等直接连通的方案。因此其数据丢失产的影响也会不小。不过现在已经比较注重这一方面了。

C++ 模板参数逐个处理

Sun, 19 Feb 2023 10:38:46 +0800

起因 Link to heading

想把 tuple 封装进一个自己的子类里，在构建函数时候传入我想要的参数，直接 move 进 tuple 容器。

问题 Link to heading

模板参数的展开与 fold expression 只是对每一个参数做同样的操作，但我现在希望把里面的值取出 move 进另外一个 tuple 里，这个过程无法直接用上述方案处理，因为 tuple 里的索引是编译期传入的，没有办法通过循环等方式处理。

解决方法 Link to heading

思路很简单，template 的编程与函数式编程相似，那么我用递归不就好了。最终封出来的类大致如下：

template <class... T>
class Foo {
public:
    Foo(std::vector<T>&&... args)
        : tpl(std::forward<std::vector<T>>(args)...)
    {}

    Foo(std::pair<T*, std::size_t>&&... args) {
        init_tpl<0>(std::make_tuple(
            std::forward<std::pair<T*, size_t>>(args)...
        ));
    }

    std::tuple<std::vector<T>...> tpl;

    template <size_t I>
    void init_tpl(std::tuple<std::pair<T*, std::size_t>...>&& args) {
        using std::get, std::back_inserter, std::copy_n;
        auto& p = get<I>(args).first;
        auto& n = get<I>(args).second;
        auto& v = get<I>(tpl);
        copy_n(p, n, std::back_inserter(v));
        if constexpr (I + 1 != sizeof... (T)) {
            init_tpl<I + 1>(
              std::forward<std::tuple<std::pair<T*, std::size_t>...>>(args)
            );
        }
    }
};

如果希望把每个 tuple 的元素做为参数传入某个函数，正常使用 expansion 和 comma operator 就好。

一种出现内存崩溃错误的现象

Sun, 06 Nov 2022 12:32:14 +0800

现象 Link to heading

在某处进行内存申请或释放时，会提示内存崩溃（memory corrpution）（windows 系统）。申请或释放内存使用的是 malloc 或是简单的 new T[n]。

遇到的场景 Link to heading

在高性能计算时，可能会大量使用指针及相关偏移来进行访问以减少索引的计算等因素。但如果出现访问内存非法时则会出现各类错误，常见错误如 linux 下的段错误或是 winodws 下的 0xC0000005（访问出错）。然而有时并仅仅是写入而不读取则不会立刻报错，而是在后续其它内存相关操作（如申请、释放内存）时才会出现错误（即本文出现的情况）。

原因 Link to heading

出现问题的地方并不是申请与释放内存之处，而是这之前通过指针写向了非法内存空间。因为操作系统是以页为单位对内存进行管理的，当写入内存而没有进行读取时，Windows 并不是会判断地址的合法性，而是会直接对内存进行写入。但当下一次出现对内存操作时，则会因为上次操作的非法而导致内存验校失败，从而内存崩溃。其根本原因是由于操作系统对内存管理与检查的策略导致了此错误报告的延后。

物理场仿真相关算法记录

Sun, 23 Oct 2022 13:30:28 +0800

只列名词，相关内容可以网上搜索到非常多资料。

几何相关 Link to heading

用于在几何空间进行快速搜索、过滤等。在建立结构时，根据空间与数据特性进行分组。

R 树
KD 树
BSP 树
八叉树

算法相关 Link to heading

网格、离散、子问题合并等。

FDTD （时域差分）
FEM （有限元）
FMM （快速多极子算法）
BEM （边界元）
FDID （时域有限积分）
拓扑优化

一些开发库 Link to heading

建模 Link to heading

OpenCASCADE
C3D

几何 Link to heading

CGAL

矩阵计算 Link to heading

Eigen
intel MKL
Spectra
arpack-ng
FEAST

数据结构 Link to heading

xtensor

为什么 haskell 的 monad 定义使用 a -> m b 作为输入

Mon, 28 Mar 2022 11:41:32 +0800

问题说明 Link to heading

在理解 monad 时想到的部分，为什么 haskell 定义 monad 时要使用 a -> m b 作为输入函数？

什么是单子 Link to heading

自函子范畴的幺半群。

Haskell 现有的定义 Link to heading

现在的 monad 定义无疑是符合单子的定义。a -> m b 是对象，pure（return）是幺元，多个 >>= 操作是可结合的。

其它定义 Link to heading

除现有定义外，还有其它合适的定义，比如通过 join 和 pure。

为什么对象是 `a -> m b` Link to heading

如果对象是 a -> b 或 m a -> m b 时，在现有定义下也可以通过 Functor 来完成相应的行为，并有 monoid 的定义。但使用这种定义我们就无法对返回值进行更进一步的控制。考虑 Either，我们对返回的是用 Left 还是 Right 呢？这两者均属于 Either 这个范畴内，可是最终只有一个被使用了。换句说话，我们没办法 =look inside=，即除了值以外的信息被丢弃了。

CPS and monad and function

Wed, 15 Sep 2021 14:58:28 +0000

更新 Link to heading

几年后再回顾，发现当时编写的内容大量是错的，因此重写。

起因 Link to heading

学习 CPS 实现过程中对单子的思考。

说明 Link to heading

ConT 主要的优点在于可以传递计算结果，和 monad 下用 lambda 传递不同，这个传递是可以显示中断的。因为单子约束的是 Monad (Cont r)，a 每次计算输入的值，也就是上一次计算的结果值，对最后一层则就是输出的结果，而中间传递的是最后做为输出时计算的最后一步。

以 Monad Maybe 为对比，后续计算的 lambda 是当前 bind 的分支，由当前 bind 处理完（前一次计算）输入后调用。实际逻辑与过程式相似，很直观。

Cont 是通过 lambda 包装来实现的。不同于 Monad 的逻辑，它是将当前操作包进一个新 lambda 里，由新的调用者来接收这一参数。对于后续计算 lambda 的编写来说，与 monad 是一样，都是接受一个参数。但因为其包装方式的不同，可以对每次重新包装时的 lambda 做修改。callCC 就是在这样的前题下，通过重新包装的 lambda，来忽略传入的值，仅返回指定的值，就可以绕过后续所有的计算。

其实 Monad (Cont r) 与正常的 monad 是一样的，关键在于 callCC 的重新包装与 lambda 配合产生了提前结束的效果。与 Reader 的 ask 和 State 的 set 等是同样的手法。

临时文件目录空间导致的编译失败

Tue, 18 May 2021 18:09:38 +0000

起因 Link to heading

使用 nixpkgs 中定义的 tensorflow-gpu 时，编译过程中出现了 /build ... no space 类似的错误。

原因 Link to heading

原因很简单，/tmp 使用的是 tmpfs，而不是硬盘，从而空间不足，因此会产生这样的问题。习惯上 /tmp 会是内存大小的一半。

进一步，我上述的问题并不是因为 /tmp 空间不足导致的，而是其 inodes 不足产生的。

解决 Link to heading

临时的解决方案就是调整尺寸和 inodes 数量重新挂载一下 /tmp 就行了。

mount -o remount,size=80G,nr_inodes=0 /tmp

其中 nr_inodes 调整的是 tmpfs 的 inodes 数量，为 0 即不限制。具体的内容可以参考内核中 tmpfs 的文档。

NixOS 特例 Link to heading

在 NixOS 中，如果使用 boot.tmpOnTmpfs 来配置 /tmp 挂载为内存的话，其大小是在 <nixpkgs/nixos/modules/system/boot/tmp.nix> 中定死为内存一半的，如果需要更换大小需要使用 mkForce、mkOverride 等方式来更换启动时挂载的大小。

haskell: fix point

Tue, 13 Apr 2021 16:24:27 +0000

问题说明 Link to heading

fix 函数是基于 Y 子、定点理论等原理进行设计及使用的。

Ref. [3] 为例，

fibMemo = fix (memoize . fib)
        = let x = (memoize . fib) x in x
        = (memoize . fib) fibMemo
        = memoize (fib fibMemo)

这里最后一个等号是定点理论的结论/推论，如果没有这一步，程序只会是无限的对函数进行展开，那么编译器是如何做到的？

推测 Link to heading

首先，haskell 得益于惰性与函数式，编译过程可以将一个个函数全部转换为 lambda 表达。根据 [1] 可知，定点理论 f (fix f) = fix f 是通过 Y 子等方式得到的产物，而这一产物是通过 beta 归约完成的。那么，只要编译器会做这些归约就行了。 [4] 中说明了 beta 规约的过程，因此推测 ghc 在编译过程中会对表达式进行规约。而根据 ghc 的文档，似乎确实会做规约 [5]。

sha256 等 hash 算法结果长度

Thu, 10 Dec 2020 15:56:43 +0000

sha256 在不同场景计算出了不同长度的字符串，类似的也存在于其它 hash 算法中。

计算结果及字符 Link to heading

计算结果是二进制值，长度由算法决定，如 sh256 结果是 256 个二进制位。

字符通常是将这些二进制以一定规则转换成字符，方便书写。

转换规则 Link to heading

一般字符串长度有 52、64 等。长度主要由一个字符代表几个二进制位来决定。

如以十六进制字符（0-9A-F）转换，那么一个字符可以代替 16 位，二个字符为一字节。计算可知 256 位即 64 个字符。

如以 BASE32 转换（一个字符有32个值），一个字符代替 5 位，256 位即 51.2 个字符，进位得 52。

类似的还有 BASE64 等。

中文排版标准

Wed, 11 Nov 2020 18:24:00 +0000

之前做一个repo时，提到了中英文混排时的规范问题。

REF Link to heading

简述 Link to heading

上述内容足够完全了，我想主要提的是注意中英文混排。使用空格分隔方便阅读与排版的美观。

使用 Link to heading

使用方面主要是纯文本与富文本两种情况。

富文本 Link to heading

html ，可以通过样式等方式进行排版。
latex的ctex包会自动处理这一样式，不需要用户担心（额外一提，ctex会处理中文折行且不引入多余空格）。

纯文本 Link to heading

只能手打了。或者看看有没有好用的插件。

编程语言语法的思考

Thu, 15 Oct 2020 15:25:51 +0000

不同编程语言有不同的语法，语法主要影响可读性与编写效率。大部分语言的语法都比较相近，但一些语法设计上的细微差异会对编程过程产生不同的体验（特指程序员的心情，不是指思考方式、算法实现等理论知识）。

本文会提及如下语言C++、rust、go、python、ruby、haskell、lisp，但其中rust、go仅仅学过语法，没有实践过，所以观点非常片面！所以观点非常片面！所以观点非常片面！

前言 Link to heading

不同语言有不同的使用领域，这主要取决于他们的底层实现、语言特性以及领域上的支持（指开发工具、库等）。比如elixir特别适用于大量并发和软实时的场景，python用于系统脚本、数据科学等领域，perl主攻文本处理等系统工具，ruby的RoR等。

但本文想要讨论的是语法、社区风格和一些特性的实现方式，而不是所有的语言特性。我将要讨论的内容主要是程序的表达/表述方式在编写过程中的快感、便利性等，这不在上述内容中。

表达/语法 Link to heading

对编程语言的语法，除了解析外，另外一点就是阅读与书写。也就是其表达能力。我们在这里说的不是单纯表面的语法规则。语法规则大家都是比较相近的，讨论这些没有意义。重点是语法之下带来阅读与书写的体验。同时语法带来的一定程度思维的导向。

不同语言都有相类似的控制结构、类型结构、函数定义等方式，他们在本质上是相类似的。不同的语言使用不同的实现方式带来了不同的特性，比如haskell的惰性计算带来了函数便利的composition，lisp的list式的语法拥有非常强大的macro等。ruby和perl使用大量了语法糖简化了相同目的代码编写，并且提供了不同的编码风格。python用较为简单（单一）的语法来减少程序员（编写过程时）思考的负担。这些设计提供了不同的编码风格与哲学，如There’s more than one way to do it，There should be one—and preferably only one—obvious way to do it，metaprogram等。

非常显然，perl、ruby这种语法糖的设计为编写带了非常多的乐趣。因为我们可以自由的选择代码的编写风格。而python就相对死板，在大部分场景，我们仅有唯一的方案来实现需求。动态语言带来了变量、对象便利地创建与调用，但又引入了调试时较难追踪的问题。同时，java/c++的静态类型有一定安全保证，可使得在声名函数、临时定义变量等方面稍显冗余（为了处理这一问题，引入了一些语法糖，比如c++11的trailing、auto等）。rust/go意在解决安全/并发问题，使用简洁的语法带来了干净的代码，但简化就意味着需要编写更多的代码（但得到了性能的提升，这种时候这一问题也不是问题，毕竟每条语句对应更少的机器码）。lisp主要是命名风格有点糟糕，因为缺少描述语义的类型（特指类、结构，虽然cl支持对象，但还是有点区别），为了避免冲突或者描述函数功能时使用命名显得非常非常长，同时，冗余的语法带来的感观的痛苦（虽然理解起来不难）。

R语言在data.frame使用了attche等手法来简化了列的选择，并且可以使用多种方式来赋值。这种针对R主要用于数据分析而设计的语法就非常的合适与灵活。

冗余 Link to heading

适当的冗余可以提高代码的阅读效率，比如ruby、perl等使用一些符号或者关键字来提示信息，同时这种符号也可以用作上下文信息的选择。但冗余不应该过度（指明明一个静态语言，却还在变量定义时需要指明类型，明明已经调用类的初始化函数）。

符号表达 Link to heading

如python，使用if-else做为三元操作，同时还有and和or等作为逻辑操作符，这更多的习惯问题，但是这种纯文本真的必要么？适当使用符号表达可以提高代码的整洁度。符号会在一定程度上对阅读代码的人产生负担。因为必需去符号的定义有一定了解。但是符号在阅读时可以产生分隔的效果，非常明显的分离子表达式。当然关键字高亮也可以做到同样的事，但直观上不如符号清晰。更加激进，我们可以各自使用符号，比如haskell，符号还充当了语法解析时的分隔符。并且使用符号可以将一部分频繁使用的函数表达弱化，从而加快理解，比如>>=、<$>、<*>。当然，这无疑增加了程序员的负担，可是一定程度的负担可以提高对整理程序的表达，我认为这是值得的（个人比较喜欢这一口，但我也明白，这是比较奇怪的喜好，相当一部分人应该讨厌这种）。

强制缩进 Link to heading

缩进是必然的，因为为了使语言可读，但python这种强制缩进就显得很微妙，因为全文缩进无处不在。haskell的缩进针对不同上下文可以自由缩进大小，因为在一个块内其缩进必然是相同的，但不同块间的缩进可能产生差异。python这一点与haskell相同，可是haskell是一个函数式语言，他编写长段代码的时间要小于命令式语言，更多的部分是可能函数组合。单子用得非常多时，缩进方面却也没有python带来的那种异样感。原因可能出在haskell缩进大多时候只有一层至二层。而python如果需要减少层级就得定义额外的函数调用，在haskell里，通过where额外函数定义会非常方便，但python中虽然有局部函数的作用域，但这反而会加长函数体的长度，lisp也是同理，辅助函数不得不进行分离。而且需要注意到，haskell的where语块，一般是放在函数末尾的，就是说辅助函数定义不会影响到阅读当前函数。而对lisp与python，在函数当前的作用域内定义就难以避免去影响阅读代码，在外部定义，又会污染环境（在上层环境命名辅助函数有时有非常痛苦的，并且辅助函数通常只有本函数会用到，语义明确的场合姑且不论，当层级过深不得不分离层级却又不存在明显的语义时，这就比较难受了。当然，后者的情况大概率是抽象不够或者耦合过高导致的）。

efi、systemd-boot与grub及双系统问题

Wed, 30 Sep 2020 23:16:21 +0000

最近在工作站上装nixos遇到了引导问题。大概为我配置了grub，但是开机却不能引导，行为是直接启动了windows，简直就像是uefi没有查找到linux的efi一样（事实也是的）。

这个问题其实之前也有遇到过，但当时因为不明不白的给跳过了，所以没有详细去理解，甚至没有发现这个问题。因此在此记录。

原因 Link to heading

原因很简单，grub不会生成efi文件，他会生成一个给efi使用来调用及grub自己的配置，但不会生成efi本身，efi本身的生成需要使用systemd-boot来生成。因此这二者的关系就非常明确，systemd-boot提供给uefi查找的efi，而grub则让systemd-boot启动后不是直接进入系统，而是调用grub来完成后续的引导，或者说，是由grub来生成供efi引导的entries。

问题注意点（针对NixOS） Link to heading

NixOS的boot不像是etc、run等目录一样严格管理的。boot目录是非纯的。因此，在最初安装系统时，会自动为你配置systemd-boot与efi，那么他们就一直会存在，除非你自己去删除boot目录下的文件。哪怕你之后把systemd-boot设置成了false也是会存在的，因为他不是使用软连接等方式，也不保证是纯的。

grub查找系统 Link to heading

wiki上有提及正常的efi会自动查找到其它系统，但这里有个大前提，就是所有系统使用的是同一个efi分区，然后各自写入自己系统的efi文件。但是当你是多硬盘的时候，操作系统的efi经常会写入自己硬盘内的efi，这个过程是比较难控制的（你需要挂载其它硬盘，这在linux很方便，但windows是很难选择efi分区的吧。至少我不太清楚是否可以选定efi分区）。而如果我们使用windows的efi分区做为引导的话，那么systemd-boot可能就会成为不需要的东西了（没有测试过）。

所以grub配合osprober与efibootmbr可以自动查找系统并加入entries（efi分区不共用的情况）。只不过当grub不使用legency时，必需要有一个efi boot才可以使用，grub本身并不存在这个功能，这点需要明确。当然，不使用grub，而是人工来使用efibootmbr等工具来创建efi的entries也是可行，只是不如自动化来得舒服就是了。

引导修复（针对nixos） Link to heading

非nixos可以直接livecd启动然后挂载、chroot、重建引导就行了。

但nixos在chroot时需要一些trick。详细的可以见wiki。但也是可以的，而不需要你每次去做一遍nixos-install（最初尝试失败时，为了时间效率，直接install了。）简单来说，nixos提供了nixos-enter就是用来干这个的。手工过程可以参考脚本或者前面的wiki。

haskell中fmap, liftM, mapM, traverse历史问题记录

Sun, 02 Aug 2020 12:16:45 +0000

问题 Link to heading

fmap与liftM看起来做了相同的事，只是类型约束不同，实现上也不一样，但结果是一样，且后者的实现，可以归约到前者。那为什么使用了两种不同的命名，分别实现？同样的还存在于mapM与traverse等地方。

资料 Link to heading

so: traverse archive

so: fmap archive

wiki: amp archive

说明 Link to heading

简单来说就是历史问题，以前的Monad等并没有受Functor约束，在2010的Haskell中已经改正了，但因为历史因素没有删除这些多余的命名。在使用中，推荐使用约束最少的那一个，比如说fmap和liftM，使用fmap。虽然实现上会有点区别，但最后的结果应该是一致的。

建立v2ray透明代理时遇到的问题记录

Fri, 24 Jul 2020 20:22:34 +0000

记录几个小问题，主要内容请参考文档。

dns回环 Link to heading

为了处理污染的问题，所以v2ray监听的53端口，但我的设置一直在导致回环。

原因 Link to heading

dns处理localhost是直接转发出去，然后又进iptables过滤再回来。由于是直接转发，不经过任何outbounds，所以自然也不会有tag。处理方法大概两种，使用显示的国内dns（内网dns的话就也只能手加，比较麻烦了。），第二种则是使用cgroup来处理。

cgroup的处理方式会比较友好，在v2的cgroup中，还可以使用目录进行match，也非常方便。

解决 Link to heading

方法很简单，像官方的教程那样加上dns的ip的路由就行（我一开始没这样做是因为觉得没这个必要，因为不路由匹配是会自动走第一个outbound的，而其实不会，原因如上）。

但这个方法并不好，因为你的dns可能有很多，比较好的方法是用dns配置里的tag然后在路由里把这个tag进行路由。

这时有几个注意点。最重要的就是路由的顺序。一定要把这个放在53拦截的前面。第二点是localhost这个路由，这个只能用ip来单独处理（如果使用了过滤ip，比如中国ip直连这样的设置，且路由在53端口路由的前面，那么可能你就不需要处理这个了）。

docker网络 Link to heading

参考：url archive

不过这里他的方法不是特别优，可以使用iptables的interface过滤来处理，比如$iptables -t mangle -A $tproxy_chain_name -i docker0 -j RETURN。至于interface的名字，基本上就是docker加一个数字，数字取决于你的docker服务数量。

nixos install

Tue, 14 Jul 2020 09:47:08 +0000

记录几个nixos安装时的问题。

关闭bios的secure boot，这是windows强制默认开启的，但这会导致U盘无法启动
关闭fastboot，这也是windows的，这会导致内核模块iwlwifi无法被加载，从而无法使用无线网络

nix derivation

Tue, 30 Jun 2020 18:34:33 +0000

今天在想要不要把home-manager内的zsh plugins换成impurer的fetch时想到的问题。nix derivation是怎么计算hash的，为什么使用fetchFromGethub这类由stdenv定义的fetchur就没有问题，而原装的就不行呢？

简单来说就是看源代码。

nixpkgs的fetcher Link to heading

定义在<nixpkgs/pkgs/build-tools/fetch...>中。主要关注fetchgit和fetchurl，因为其它的大部分是基于这两个的，会发现他们最后得到的是个drv。即，通过drv来判断文件是否符合我们所需。

nix的drv Link to heading

需要先明确，stdenv.mkDerivation就是在nix的基础上加了些参数，使得定义更加方便和直观，没有太多的trick。所以直接理解nix的drv就行。

nix的文档中有提及outputHash这个参数。由于没有去查看nix的源代码，所以这里仅是猜想。当这个参数提供的时候，以这个参数做为drv的hash，否则计算所有的参数，由这些参数来计算hash。而这样一来，当我们在一个drv里使用了nixpkgs的fetcher时，这个fetcher的drv就做为了其计算值，而这个drv又由其outputHash来生成drv（理由见下方drv格式的说明），而不需要在计算hash时去下载文件。因此，我们可以在仅当使用这个drv时，才会去下载我们需要的文件。但使用buildin的fetcher时，由于最外层的drv，即我们所用的包是不显式定义outputHash的（这样也会比较方便，因为只要我们改动了一点，hash就自动变了，而不需要去人工担心。可以这样的原因是由于drv的文件格式，其hash计算是基于这一文件进行计算的。），所以需要计算hash，而计算hash时就需要每个参数进行展开了，当然这里用的buildin的fetcher就得执行了。

上述的过程中有个关键就是drv的build，如果build drv的时候，还是需要所有的参数，那么nixpkgs的fetcher也会和builtin的一样，需要拉取文件了。所以关键就在于drv构建的时候，只需要其所有必要的信息，即这个drv生成后的hash和这个drv包含的指令。虽然打开一个drv文件，会发现其实是一个纯文本，其格式定义于nix源代码中。可以看出，这个文件就是把所有的drv转换成了其对应安装后的目录。所以nixpkgs的fetcher生成的drv也会变成其安装后的目录，而获取这个目录，我们需要的仅仅只有hash和包名，最多加上其对应的drv。由于drv内只需要目录和脚本信息，所以nixpkgs的fetcher的drv生成时，由hash得到目录，而内部信息通过url和脚本进行lazy，也就不需要有下载这个过程参与了（下载的行为定义于build脚本中，而脚本使用了drv定义的变量来传递下载的地址等信息，因此达到了构建drv不需要下载，而安装时进行下载的行为）。这样计算外层drv的hash时需要的fetcher得到的信息就不需要下载后才可计算了。

调试器与软件启动过程

Sat, 20 Jun 2020 13:53:33 +0000

起因很简单，在弄emacs的调试器，然后想到的问题。本文主要思考了CC、haskell、python与ruby的调试器。在IDE中，在源代码窗口中打断点其实就相当于在对应上下文或调试器启动时，增加给编译器或解释器使用的中断信息，如C语言中的调试用宏，lldb/gdb/ghci中break相关命令的参数，ruby中的byebug等。

对大部分程序这一过程运行良好，但是对于从外部启动的程序（特别是web应用，如rails、django），他们的外部启动器（如django server，rails server）会附带额外的启动配置，并且调用我们所编写的项目内容。我们无法先打开调试器（或解释器）来直接运行我们的程序进行调试。同时，这启动过程中，可能是再次通过外部程序来调用的，如rails server中使用exec来调用后续代码。相当于一个新的进程，在这个进程中，哪怕与原程序是同样的语言，但是运行环境不同（父子进程不共享内存，何况子进程不一定是同样语言环境，虽然这里是相同的）。调试器难以获取其内部的信息。

我所写的启动器是指包含了整体程序的入口程序并调用了开发者所编写代码的模块。我要强调的是入口。当入口不为我们所直接调用时，这会影响到调试器来进行设置，如下所言。

在编辑器中，就难以仅仅通过一个公用的接口来完成不同情况的调试，比如解释行语言ruby，我们无法使用inf来简单的直接去调试rails代码（在最开始的时候，我们一般得从web接口开始，去查看问题出现于哪个点，并且dump出上下文环境。有了上下文环境才可方便的从解释环境中仅加载相应的模块来进行测试）。我们需要从rails server中来主动浮出解释环境，方便我们查看上下文。

Haskell与Yesod Link to heading

Haskell是一个编译型语言，但他有一个解释环境。当然这个解释环境不同于一般的解释型语言，他是比较特殊的，与实际的执行环境存在差异（因为整个解释环境都在IO单子内）。而Yesod的使用，是通过Template来实现的，即我们使用了宏来编写了入口。入口是定义在我们自己编写的文件中的。换句话说，我们自己的程序才是主体，通过调用了外部的框架来快速实现了一些功能。

当然，在haskell中就可以使用ghci来load我们的入口，从而直接执行整个程序。由于这些代码是不是通过调用外部程序调用的，调试器当然可以读到所有的上下文。

CC与GDB/LLDB Link to heading

C家族的编译器，可以在编译时选择调试选项，把源代码内容编译进二进制包中。而调试器则通过查看这类信息，来快速定位。

而对于C家族的语言来说，必需需要编译，那么启动器必然是编译入你所生成的二进制文件中的。即，整体代码的启动入口一定是与我们编写的代码，在同一程序中。并不会出现上文所述的子进程。所以不论如何，调试器都可以获取到运行的上下文。

类似于MFC、CLS、Qt、macOS的开发等，他们其实都是隐性的使用了固定的入口，然后在编译前生成这些文件与我们所编写文件的关联，最后得到执行文件。虽然入口隐藏了，但入口还存在于我们最后所得的执行文件中。其本质上与haskell是相同的（从时间上来讲，应该是haskell与他们是相同的），只不过是由开发环境在编译前自动处理了。

Python/Ruby与Django/Rails Link to heading

这类是解释型语言，非常不同于上述两种情况，我们的程序是客体，是由外部程序来调用管理的。即启动过程不为我们所直接/间接控制。那么我们就不可以像ghci或gdb那样，来加载一个包含入口的程序来进行调试。需要注意，这里是入口，如果我们不使用入口，直接从我们所编写的子模块开始调试（手动准备所有的参数）当然是没有问题，但对于最开始的时候，我们需要dump出错误产生时的上下文来观察奇点是什么。否则我们直接从子模块开始调试的话，要如何准备那些参数？

现存的调试工具如pdb、byebug或pry，都是在代码中添加调用，到执行时，来浮出交互式的解释器。因为我们无法控制入口，当然没办法从解释器中调用整个程序（当然其实可以，只不过非常麻烦，就是我们要用代码来调用一个个boot，而这些boot一般是通过环境的PATH来查找的，手动加载就等于得把这些全部手动写入。另外如上文所提，如果启动器本身是使用了子进程，那么最后仍是无法获取到内层的上下文）。

所以浮出是一个好的方案，即执行到我们需要调试的点了，浮出一个交互程序，这个程序与启动器是不相干的（只包含我们现在的执行上下文，同时不会受父进程的影响）。

调试器 Link to heading

现在理清关系后，问题来了，我们要如何针对第三种情况来操作调试器？因为emacs的交互用的是单独的mode，从eshell中转入会失去交互mode的特性，当然，可以人工切换，但这很不值得。比较好的想法是，把交互mode的运行指令改成对应启动器的启动，然后用人工的方法来添加浮出交互的代码。当然，这样就推动了从源代码窗口打断点的方便性了。但这个打断点的原理很简单，其实就是相当于加了额外的执行语句，封个函数就行，但emacs中并没有这样的操作就是了。因为现有的断点都是以调试器指令的方式来添加的，而不是通过添加实际代码的方法，而添加代码又会出现缓冲区与保存的问题，执行是需要先保存到硬盘的。

结论？结论就是我们修改交互的启动命令就能在emacs里做一样的事了。

haskell caf

Tue, 19 May 2020 14:54:36 +0000

haskell中，会对特定的form进行缓存。从而产生出了一些使用无穷列表等方案的技巧，用于缓存运行结果。避免重复计算。最典型的例子就是斐波那契数。

几个参考：wiki: memoising Constant Applicative Form(caf) The Fibonacci Sequence let and where eta conversion fix and recursion

简单来说，就是符合caf的形式，在其执行时，会根本不同的情况对其值进行缓存。比如无穷列表的map会对列表进行缓存，这里主要是使用一个叫Float bindings outwards的东西，这是什么我也没查一，只知道ghc里面有一个FloatOut模块是用来做这个的。

如果不依赖caf，可以参考上面wiki的方法，使用各种trick进行缓存记录。

foldl,foldr,foldl'

Tue, 21 Apr 2020 22:12:22 +0000

fold是合并列表等重要的操作，其中主要有foldr和foldl，也即从右向左和从左向右。一般来说，后者会优于前者。但在haskell中，并不是这样。

基本结论 Link to heading

haskell wiki

主要内容都写在上面的wiki里了，这里仅做一个简单的小结。

由于惰性求值的关系，在haskell中foldl并不比foldr性能更好。
foldl'是立即求值版本，效率效高，但没有惰性的关系无法配合haskell的部分特性，如无穷列表。
foldr在haskell中也意义着right method。
foldr相较于foldl可以更好的适用于惰性特性，如无穷列表。特别地，其可以应用短路求值，而foldl不可。

关于第四条的短路求值，是默认使用foldr的一个主要理由。

深入讨论 Link to heading

foldr Link to heading

比如：

[ .., c, .., b, a,]

forall x. c * x = c

(.. * (c * (.. * (b * (a * x)))))

这里从左至右计算（即右侧惰性），所以当一开始遇到了c，就直接停止。特别应用在haskell的类型匹配方面。可以带来一些通过无穷列表实现的trick。

foldl Link to heading

那么，引入了一个新的问题，如果我左侧惰性，即优先根据右侧返回结果，是不是可以使用foldl呢？

REFS code is engineering, types are science

Mon, 06 Apr 2020 14:58:44 +0000

Origin

nix计算目录sha值访方法

Mon, 02 Dec 2019 18:38:56 +0000

nixpkgs有一个fetchFromGitHub的方法，里面需要计算sha值，但是但是是但是文档里没有说这个值是怎么算出来的，不同于一般的文件是很容易计算的，这里是一个目录啊，文档上还写着”extracted directory“。很是迷惑。

解决思路，读源码。

主要源码为pkgs/build-support/fetchgit/nix-prefetch-git中。通过阅读可以发现，他在计算时是删掉了.git文件的后使用nix-hash计算的。而nix-hash计算也很简单，就是把所有文件拼起来，然后计算。可以读一下文档。当然除了拼接外还增加了两行信息，但问题不大。对于单个文件，加上--flat参数就行了。基本上来说，nix-hash大致等于find <path> -type f | xargs cat | sha256sum这样，实际上是nix-store --dump <path> | sha256sum，其实dump这个过程和cat差不多，只不过增加了些信息，以及进行封装确保文件列出顺序相同，以及二进制文件相关的处理。当然，还有一些使用了base32的转换就是了。理解完这一点后就轻松了，剩下的自己打几个命令试试就明白了。

转：haskell如何让你的生活更简单

Mon, 02 Dec 2019 08:33:24 +0000

REF: How dose haskell make life easier

nix setupHook和一些tips

Sat, 30 Nov 2019 16:03:27 +0000

之前已经写过一篇关于nix的配置相关的博客，这次是再一次遇到了新的问题，而对setupHook进一步理解后写出的。主要针对NIX_CFLAGS_COMPILE和cc-wrapper等内建的hook进行了一次理解。问题首先为成两个主要部分。

cc-wrapper是何时被调用的，在cc-wrapper的setup-hook里没有调用到cc-wrapper，且stdenv/setup.sh内也不存在setup-hook以外的特殊脚本调用。
setup-hook内，以及各种build-support内，没有任何对NIX_CFLAGS_COMPILE进行配置的地方，在nixpkgs也是同样（除了部分configure等有兼容性问题的地方）。那么nix是如何使用这个变量，而又不去设置CFLAGS等变量的（其实有点剧透了，因为最初的想法应该是何时把NIX_CFLAGS_COMPILE传过去的）。

这两个问题其实是同样的，因为都是wrapper的内容。这两个问题之外，就是一些小细节了。

cc-wrapper/bintools-wrapper Link to heading

注：下文以cc-wrapper为例，其它的wrapper也大同小异。

这类内置wrapper本质是一个drv，也就是一个软件，而所谓的cc-wrapper根本不是setup-hook，在nixpkgs文档内这部分写到了setup-hook内，但他setup-hook的是自动加入依赖进NIX_CFLAGS_COMPILE，而不是给GCC等传入这个参数。当然传入参数这一过程也是由这些wrapper实现的，但不是由setup-hook实现的。那么是哪里现实的呢？

答案在cc-wrapper的drv里。在installPhase内，有一个wrap的shell函数调用，而这一调用就是把cc-wrapper.sh这一文件进行的替换。把gcc、clang等常用的一些编译器，用cc-wrapper替换掉了，而cc-wrapper干了什么？那么去看cc-wrapper.sh，其实就是把NIX_CFLAGS_COMPILE等NIX_的环境变量直接传入给wrap时打包的程序。比如，wrap了gcc，那么cc-wrapper最终就会执行gcc $NIX_CFLAGS_COMPILE ...这样的语句。当然，wrap不止做了这些，但这是我所关注的，此外做的还有一些参数的传递、hook的调用等。

这样做除了可以传递CFLAGS外还有什么好处？在configure后一般会生成Makefile，或是有些Makefile内会需要你人为设置一些CFLAGS，而这些CFLAGS可能会因为各种原因被覆盖，比如Makefile的强制赋值。常见的就是configure会生成Makefile.inc，里面包含固定的CFLAGS。除非我们人为了去修改Makefile.inc（通过patch等手法），或者在configure之前设置CFLAGS，才有可能使编译正常。而CFLAGS在configure的过程中是可能被修改的，这样有可能导致部分依赖的丢失或错误。那么我们把编译器做个wrap，所有的$(CC)还是存的编译器的名称，如gcc，但gcc不是纯粹的gcc这个程序，而是先对参数进行处理再传递给gcc，在兼容性方面会有更强的优势。不同于使用CFLAGS等变量带来的不稳定性。

做个对比：

echo $(CC) # = gcc
cat $(which $(CC)) # = gcc-wrapper which call gcc with NIX_ variables
# equal: gcc $NIX_ ...
$(CC) $CFLAGS ... # CFLAGS may break by configure or configure-hook.
# equal: gcc $NIX_ ... $CFLAGS ...

与

echo $(CC) # = gcc
cat $(which $(CC)) # = gcc
$(CC) $CFLAGS

tips Link to heading

今天要写的主要是环境变量和./configure。

引用：haskell相关文章列表

Mon, 25 Nov 2019 08:58:43 +0000

Ref: A LIST OF HASKELL ARTICLES ON GOOD DESIGN, GOOD TESTING

nixpkgs configre与build相关思考

Wed, 20 Nov 2019 14:12:57 +0000

问题主要在于nixpkgs的mkDerivate都干了些什么，为什么可以自动处理cmake等构建。以及在最近，nix使用placeholder "out"来代替了$out。不知道这里的原因。

最近突然想到nix的包一些原理，有点好奇就去看文档，但nix一套的manual太过于简单了，同时部分内容编写有点混乱，或者说比较难查到想查的东西。比如override和callPackage需要看pill才能理解，而pills里写的内容又非常有限。而setup-hook的选项和和一些内建的setup-hook是分放在不同的两个章节且没有跳转或说明。

mkDerivate Link to heading

setup-hook Link to heading

首先，在nix里的derivate会使用bulider。在nixpkgs里，这个被自动设置为<nixpkgs/pkgs/stdenv/generic/builder.sh>内，这个文件主要使用了同目录下的setup.sh和genericBuild。这两处在nixpkgs文档里有提到，另外，文档里还提到的有setup-hook和一些内建的setup-hook。在setup.sh中，仅仅定义的hook的注册和运行，并没有具体的hook，这些具体的hook是什么时候从什么地方如何注册的呢？

我的第一个问题，如何处理cmake的configure，就是这里解决的。这些setup-hook分布在各种包内，然后mkDerivate有一个setup-hook的参数，这个参数就是用来说明将对应的hook进行注册到运行环境中(nix-support内)。所以当我们在nativeBuildInput中包含cmake后，在安装cmake过程中，这个hook就被自动安装了。对应其它的wrapper也是一样的。

outputs Link to heading

很多nixpkgs的包内有多个outputs，但没有显示给出对应outputs的install或者使用他们，这一过程被也被mkDerivate自动化了(<nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh>)。这一过程主要有对outputs相关shell变量的设置和configureFlags。当然，这只是针对默认configure的情况，而其它比如cmake，可以查看cmake下的setup-hook。会发现，同样也做了对应的支持。因为前者已经配置好shell变量了，后者只要直接用就可以了。

placeholder Link to heading

我最初的理解，这个是内建在nix内的，而$out依赖于bash变量。可以较好的分离开二者。

现在在discourse上提问中，等等回复吧。

大概理解一下，主要就是提供了一种在shell外使用那个目录的方法。没有太大的区别。

对逻辑与物质的思考

Wed, 16 Oct 2019 16:40:04 +0000

源:《自然辩证法》作业

感觉写了点东西，随便放一下。

本学期学习了《自然辩证法》，在短短的几堂课内，老师为我们介绍了自然辩证法的历史发展到具体内含，再到自然辩证法在科学发展中的使用。自然辩证法主要为两大方面，即自然观与自然科学观。提出了“透过现象看本质”，“本质是事物的内部联系”和“联系是普遍的”这样的观点，我想就这几点进行探讨。本文将粗略得基于维特斯坦的《逻辑哲学论》和《哲学研究》为代表的逻辑经验主义和实证主义与自然辩证法中“现象与本质”和“联系”进行思考，并加以本人专业（计算机科学）中的面对对象与函数式编程进行分析。本文余下内容全部是基于我对这几者的理解并进行扩展，会存在其内容与原作者意图存在差异的情况。

自然辩证法（或者马克思主义哲学）中，世界是由物质构成的。而运动物质经由某种特性（性质，属性）被人们所感知，即我们称之为现象。通过科学的手段，我们对现象进行研究，看到事物的本质。而事物的本质即他自身内部的联系，在我的理解中，这种事物的内部，就是这一物质所拥有的属性，内部的联系即属性间的一种关系，可以看成是一种方法（method，对物质所拥有属性的一种操作）。进一步，不同的物质必然存在着的某一种方法使得他们联系在一起，这种联系可以是多种多样的，比如聚合，又或者是派生。在我的认知中，派生更加适合于这种联系描述。所有的物质存在着某些共用的方法，可以将这些方法抽象出来构成某一抽象的概念物质（不实际存在），而通过一层层概念化的派生，构成我们实践中所能直接认识的物质，最后整个物质世界，形成一颗非常庞大的树形关系。

在《逻辑哲学论》中，世界并非由物质，而是事实构成。而事实又可以分为真实存在的，与不存在的。实际的世界，就是由这些真实存在的事实构成。而事实是由对象（物质）与事态的组合而成。同上述相同，对象具有各类的性质，但这些性质不是由对象自发的表现出来，而是由事态进行呈现，最终表现为一个事实。对象本身是不具有自发的运动性的，而运动是由外部给予的。这一外部就是事态，事态可以看是是导致某一运动的法则。《逻辑哲学论》中，诸事态构成了逻辑空间。与逻辑空间相对应的是逻辑图像与逻辑。逻辑即数理逻辑。逻辑图像即由诸命题所有构成，而一个简单的不可分割的命题，就是这个世界上最基本的法则。简单命题又是由真值联结词、真值函项进行构成，最后形成逻辑常项构造出所有的逻辑命题。而复杂的命题由各种简单的命题进行复合，最后作用于对象，形成事实，构成我们的世界。命题的逻辑图像就是我们的思维，而思维又经过我们的语言进行表达。以此界定了我们思考的边界，也就是世界的界限（世界是逻辑图像、逻辑空间描绘的）。

这里我们不讨论哪种正确（我们也无法讨论，因为世界的真假是要在世界之外进行讨论的，这超出我们思考的界限），我想主要表达的是我们思考的方式。也就是在编程中会提及的面向对象编程与函数式编程，是对象（物质）优先，还是函数（逻辑、事态）优先。需要明确，不论是哪种，对象与逻辑必需是并存的，只是思维的优先度的不同。对象优先更加适合现代的思维方式，也更加贴近我们所直接观察到的世界，但是使用逻辑优先的思考，可以让我们以一种更加抽象，更加数学化的方式去认知与构造我们的世界（程序）。将操作从对象中分离，就意味着，对象不是受约束的，可以根据需要随意的修改。我们约束点从对象变成了逻辑（函数）。在现实中，我们使用的是对象，但我们真正需要的是某一逻辑在这一对象上产生的结果或过程。真正的关注点可以说是逻辑。更进一步，对逻辑进行抽象，某一群可以被多个对象共有的逻辑可以视为一个群（更严谨来说，是范畴），而对象视为集合。在范畴内，对象们可以拥有各样的映射关系，而范畴间，又可以构成单子、函子这样的关系进去映射，最终构成我们的世界（程序，或真实世界）。

把思考从对象的约束中，构建一个由范畴、逻辑、数学组成的世界，最终应用于自由的对象。这一过程中，虽然部分基本要素不同于“自然辩证法”，但是联系、本质这些观点也是存在的。所有范畴就是一种联系，不论是什么样的（哲学）系统，总是会存在一种系统内的“联系”的思考方式，去构建这一系统本身。本次课堂内最大的体会就是对“联系”的认知与发展。

Why modality and chording

Tue, 15 Oct 2019 11:12:10 +0000

From: noctuid/dotfiles

转：你是否有编写haskell的能力

Fri, 11 Oct 2019 12:00:01 +0000

原文：you-are-already-smart-enough

category theory
lambda calculus
lazy evaluation2
lenses
monad transformers
effect algebras
recursion schemes
type programming
Template Haskell
proof languages like Coq and Agda
language extensions other than -XOverloadedStrings

From time to time, it will feel frustrating because you will know how to solve the problem in [some other language] but not in Haskell.

What do you need to write real Haskell? The core of the language is extremely simple. If you understand how to write and use

类型类、逻辑与哲学

Tue, 01 Oct 2019 14:13:20 +0000

起因 Link to heading

之前因为作业，写一个多项式计算的实现（来自课《计算机代数基础》，教材料《Ideals, Varieties and Algorithms》）。其实遇到了些问题，在data构建中，传入了太多子类型的参数，又将操作类型类化，导致实例化时出现了编译不通过（主要为无法deduce），根本原因在于对于一个forall的返回值类型，在其它函数中调用时，如果存在约束条件，是无法duduce的。哪怕不是约束，只要存在一定的类型限制就是不行的。这其中查找了相当的内容，也有解决方案，但并没有直接去修正。这源于我对类型类的一些理解问题。

实践 Link to heading

实践中如何使用类型类是非常明确的。它提供了一种类似于函数重载的功能，但同时也具有自动推演、对不可控data进行instance等能力。这类信息网上能查到非常非常多，可以看一下y2b中的_typeclass vs world_这个视频。同时haskell的类型类除了针对不同数据结构提供同样语义的操作外，还包含了自动推算和约束等功能。

这里想说明几点，一些教程里会将类型类类比为虚函数或者接口。但这是非常不正确的。一是在继承中，我们继承下来的东西，是一种可以使用，但在子类中必需要被调用的存在（指在子类的成员中被调用）。而类型类的约束不同，约束是需要你使用的，不然就不存在意义了。对象描绘的是物体，而类型类是一种逻辑、算法。

解决方案一 Link to heading

这仅仅只是理解了类型类，还没有处理起因。处理起因最直接的手法有两种，一种是在类型类的类型变量里增加参数，另一种是使用type families。前者会引出另外一个问题，instance时的类型匹配，如果构造的数据存在过多的聚合，会导致匹配困难（哪怕开起扩展），也会使得实例化的参数显得冗长。如：

newtype V a b c = V { V :: a b c }
newtype V2 b c = V2 { V2 :: Seq b c }

当然这样的做法对haskell里是没有意义的（理由下面再说），但是对V2进行实例化时，就会因为Seq等参数原因导致instance非常冗长，不然就是使用type families。而type families起引也是用于处理类型问题存在的。因此这样一来对于存在如下的代码，就可以使用type families来进行处理。

class C a b c where
    f :: Ord b => a b c -> b
    func :: a b c -> a b c -> Bool
    func x y = f x >= f y  -- ^ compile error: cannot deduce 'f x' and 'f y'

-- | use type families
class C a where
    type OrdC a
    f :: a b c -> OrdC a
    func :: Ord (OrdC a) => a b c -> a b c -> Bool
    func x y = f x >= f y

思考 Link to heading

寻找上述解决方案时，去stackoverflow上问了相关问题。说到了是否有必要使用类型类。让我就去查起来了各种资料。

haskell pettern synonyms and view

Fri, 20 Sep 2019 20:05:59 +0000

最近需要写一个多项式相关的东西（代数课练习），而正好看到一个人用pattern做的方程解析，就有点好奇是怎么做到的，然后查找各种资料后得出了结论，主要是用到了ghc的扩展，这里小记一下。

主要扩展 Link to heading

PatternSynonyms和ViewPattern

文档：PatternSynonyms与ViewPattern

PatternSynonyms Link to heading

这是主要实现自定pattern的扩展，语法格式查看ghc文档就行。大概分为单向、双向和显式双向。

单向即只用于pattern
双向就是可以用于正常表达式
显式双向就是单向和双向使用不同的操作。

主要语法 Link to heading

单向：

pattern <pat_lhs> <- <pat>

双向：

pattern <pat_lhs> = <pat>

显示双向：

pattern <pat_lhs> <- <pat>
  where
    <pat_lhs> = <expr>

说明 Link to heading

这里先考虑一点（也是写本博的重点），我们pattern时，是将某一个参数做pattern，可以看做pattern是一个函数，而第一个也是唯一个参数隐式的，即我们需要去匹配的那个data。，正常使用就和一般函数相同了，左侧有几个参数就是几个参数，传给右侧进行计算。

注意本质，这里使用灵活，因为存在大量的隐式传入参数的可能。

对单向而言，就是将传入的值与其进行pattern（增加绑定，不然就是隐式将原值直接传入），然后传给左边。

而正常表达使用则是看作一个普通的函数，左面是绑定右面是实现。

大部分情况，只有左面的操作与正常data构建时的pattern相同时，可以使用非显式双向（相当于data的构造，可以封装部分参数）。

本质上来说，右式就是一我们对于这个pattern传入的原值。但使用上，<pat>经常使用view pattern，因为我们要对某一data构建pattern，自然我们需要将内部的数据取出，而取出这一过程基本上就伴随着pattern（注：这里和单子等无关，因为我们需要明确右式最终传入的是一个值）。但也可以只是一种很简单的匹配，比如Poly包里的pattern X <- ((==) var -> True)这种，通过类型约束来隐式的传递参数。当然，右式不一定得是pattern（猜的），只要有办法把你要的参数给弄出来就行。但除了pattern没什么方法吧。因为我们是要将右式的参绑给左面，非pattern的情况没办法显式给出参数吧？不然哪来的下面的要写的东西，所以结论是，右式应该只能只是pattern。

ViewPattern Link to heading

这个扩展是查看containers这个包里Seq的pattern时发现的。

毕设遇到C语言相关记录

Fri, 17 May 2019 08:32:01 +0000

起因 Link to heading

最近做毕设，题目是以ARM与Linux为基础的一些设计，由于是第一次接触嵌入式设计，再加之C语言学完已经有快7年了，平时不怎么用。虽然当初刚学习的时候看了相当多C/C++的书籍，很多知识细节也知道，但真写起来还是遇了不少坑，在此记录一下。

交叉编译 Link to heading

使用的开发板默认提供的是gcc4.4.1，各种编译不通过，最后是使用docker才完成的。但其实可以编译高版本的gcc，但是这种情况下，需要重新链接libc库。

此外，默认提供的交叉编译器使用的是全局硬编码的方式写入工具链和库，而不是动态查找的方法，在NixOS上无法正确运行，必须进行虚拟化。

在设计软件时，进可能使用动态编码查找相关数据，命名约定的存在就意味着存在非标准的情况。根据约定的使用环境不同，特别是系统这类大型环境，必然存在想法不一样的设计思路。

2019-09-20增：如果需要编译低版本的编译器，主要有两种方案，一种是拉取二进制（如docker或通过旧的发行版），二是高版本一步步编译出低版本，过大的跨度是不行的，需要一层层向下编译，同时编译过程中需要注意编译选项等操作。

链接时报错：重复定义 Link to heading

使用#ifndef等手段，可以有效避免头文件被重复包含导致全局变量被重复定义，但是编译过程中是针对每个文件进行编译，最后再进行链接。也就是说，如果多个c文件包含同一个头文件时，每个c文件生成一个obj，都会对这个头文件内的全局变量分配命名，链接期就会出现重复定义的问题。

解决方法有两种，一种是用static进行修饰。原理是static修饰的情况下，只有第一次定义会明确分配命名，而后面再出现，并不会。这一手法比起全局变量，更适合使用在函数体内，比如MFC中的getAppliction（有点记不清是不是这个名字了）。

另外一种解决方法是，头文件内所有声名加extern，也就是仅使用声名，不进行定义。定义放到C文件内，由编译期确定。链接时只会检查多次重复声名，而不会检查到重复的定义，定义仅会存在于一个进行实现的的obj文件内。

minori解散感触

Wed, 13 Mar 2019 12:19:36 +0000

2019/02(上个月)底，gal制作公司minori宣布解散。

minori对我的影响还是很大的。个人喜欢的作品有几部就是minori，特别是那种op的表演方式。当前eden的剧情布置，各方面都震撼到了我。而我推eden的时期，正好没有其它特别让我印象深刻的事，自然minori的游戏成为那一年对我影响最深的一部分。

自sppl后，minori的作品投师就开始下降了，为了生存不得妥协，但就是如此，作品的质量（特别是音乐还有立绘），在市场上来说也是优秀的。虽然不如以前，但也仍让我感到开心。

eden确定的结局，仍然谱写出的爱情，这种明知结局而仍然去表达、去喜爱的故事，比那些结局的悲剧来得更加伤感。但没有遗憾。sppl令人赞叹的op，日后各种轻松中略有压抑的故事，都无法让人忘怀。（什么，你说ef？剧情是不错，但是有点不太对口

在minori宣布解散的网站上，以及各种说明中，都出现了小众派一词。解散的主要因素是内部原因，以及酒井不希望继续做着那些自己不喜欢的游戏。不仅仅是minori，近年来让人眼前一亮的作品渐渐少了。那种从根本上打动人的作品少了。手游、网游各种高收益快餐式的作品多了（当然这里也有好的）。甚至有公司直接转行做手游了（我说的就是八月和typemoon，魔夜二啊）。

对我而言，minori代表着那一年的生活，那一年打动我至今的优秀作品。那如诗般的、理解的、优雅的爱情。我也希望能得到这样的感情啊（但至今为止，我似乎从没有真心喜欢上一个人，没有喜欢，又何谈爱情？）

最后让我引用一句：

We always keep minority spirit.

邮件标签与文件夹

Sun, 17 Feb 2019 21:20:46 +0000

现代电子邮件有着很多功能，比如folder、tags等。但是folder是包含在imap协议里的，而tags则。其中又以gmail最为特殊，完全使用tags，但gmail对tags针对imap进行了folder变换，所以使用上没什么影响。可是对于其它邮箱就不一样了，我们分类应该是用tags还是用folder呢？

tags和folder都可以通过filter进行自动配置，最大的区别就在于后者可以用imap从各种客户端直接访问，而前者不行。

而现在主流的客户端都提供的筛选功能，当然也有folder功能。这样两个功能就显得有点冲突了。我们究竟用什么呢？

我把标签当做一种配置在webmail客户端中的filter，对本地客户端做同样的配置，而folder人为了进行操作，主要保存需要长期保存的文件。

这样做有几个原因，对于一些客户端，他只会对inbox的顶层邮件进行通知（是的，我说的就是airmail!虽然可以配置，但比较麻烦，不如直接设置过滤器）。且在客户端滤器可以同时应用于多个邮箱，在一定程度上可以做到更好的收集。而folder主要就应用于保存长期邮件了，类似于归档吧。但除了gmail中归档于标签配合比较好外，其它的都需要人工设置，那么这样我们就用folder来代替这个过程好了。即可以对想要保存的邮件分类，又可以避免修改原邮件来强制适合过滤器，多好。

nixos使用与开发配置

Tue, 29 Jan 2019 12:14:27 +0000

开始上手nixos，nix与nixpkgs其实相对还好，都没有什么问题。但这之间遇到了相当多问题。大体分为几点。一个是开发环境，nix-shell的沙盒并不能很方便的对lsp等开发过程中使用的工具提供支持（我们不可能在shell.nix中去添加开发开发用的工具），另外一个大问题是部分第三方包的安装。

从文档开始 Link to heading

这里要特别说明，nixos的文档与其它一些文档相比，有点乱。不像gentoo有一个handbook，但是有一个pills。这个pills是一开始被我忽略的东西，本来以为只是一个简单的教程，但其实不是。如果不读这个pills，直接读manual会发现很多东西对不上。或者说感觉文档阅读起来相当困难。manual分为几个，对于日常使用，主要是nixos，nix与nixpkgs。这三个是必需要读全的，且要交错着读，相交内容比较多。先读pills再去接触文档会比较好。因为文档主一些内容只是一句话带过的。比如参数的override，在没有读pills前，至少我并不知道这个参数是从哪里来的（居然是packages定义函数的参数），而且现在nixpkgs并没有可以对这个参数详细查阅的方法，唯一的方法就是看原代码。

pills是以nix，一点点深入，到构建出一个简单的nixpkgs和nixos中的一些概念，换句话说，nixpkgs中的一些理念，要读pills才能明白。仅仅只读manual，用用系统问题还是不大的，但是如果要做大量工具配置就会出现各种问题了。会发现manual中缺少了很多必要的东西。

环境构建 Link to heading

一般一个编程环境，主要有编辑器、编译器/解释器、依赖包等。

以典型的C为例，编译主要有全局的头文件和库，以及编译器。而python、ruby此类语言则是一个可以导入各类包的环境。不论是那种都大量依赖于环境变量，通过各种环境变量进行查找。解释性语言大多又提供了沙盒工具。可以在不污染全局的情况下进行编译、解释。

开发环境主要依赖各种分析工具，比如lsp server会对各种引用文件等分析，一般工具都对沙盒环境会有支持，但在C方面就会比较差了。需要相当多的配置，会比较麻烦。

依赖，是软件开发中相当重要的一个问题。循环依赖是非常头痛的事，而且也很常见。一般可以通过精心配置和选用依赖来消除。但都比较麻烦。特别是当有多个不同工具，依赖同一个库但版本不同时，这就会造成了大量的冲突，一种情况是用沙盒处理，但并不是所有的工具包都有沙盒，或者就是人工添加路径，这样会很麻烦。典型得像gentoo的ebuild就是使用了一个编译过程中的沙盒和slot系统来处理版本问题。但当同slot一些软件对包的限制非常大时，就会出现比较严重的依赖错误了。

nix/nixpkgs Link to heading

nix本身是一个语言，用于描述一系列包及其构建。而nixpkgs是基于nix，进行扩展与添加了大量默认包的一套包管理系统。不同于其它包管理，nix最大的优势在于环境隔离。nix的所有包构建会自动隔离，但又不像一些沙盒隔离得非常彻底，可以使得在依赖不被多次重复安装，但又可以隔离环境，同样的软件包在系统中可以存在多个版本。思想很近似于haskell的stack，但不同于stack，stack并不提供一个全局清理方案，唯一的方法就是人工删除每个项目的沙盒。而nix通过link方式，对这个做到了非常好的处理。

nix-shell/nix-build Link to heading

此二者是nix的子工具，前者提供一个shell环境，后者则是对包进行编译。默认下shell是使用的build环境，特别注意，是编译环境，也就是说，是不包含编译后的东西的。对于python等解释类语言一般仅仅使用nix-shell就足够了。nix-build更多是针对编译类语言的，或者对解释类语言项目进行打包时使用的。

特别注意，nix-build提供的是编译环境沙盒，而不是运行环境沙盒。运行环境沙盒可以使用nix-shell进行构建。具体的可以读阅读文档。

如果需要运行环境隔离，更近一步，还是使用容器更好。当然，nixos本身提供了一个自身的容器，可以更加方便的使用。

NixOS Link to heading

完全基于nixpkgs构建的系统，不存在任何传统的一些目录，系统大部分目录也是只读的。最激进的就是完全把全局环境移除了。这样就带来了大量问题了。没有全局环境，就意味着所有非nixpkgs的第三方软件包管理，只要有依赖到全局库编译就一定会失败，特别是pypi、gems、cabal这种，而python大部分包在nixpkgs都进行的提供，所以可以轻松安装，但请注意，库与软件是分离的，就是说安装python与python的库，并不能在python中导入库。处理方式就是建立新包来把这几个包的关系建立起来，而对于ruby，官方提供了详细文档进行说明。node则不需要。因为node包并没有编译的过程，也没有在安装过程中依赖到第三方环境。

问题产生 Link to heading

上面这样一说就出现了一个很关键的问题，开发环境。对于使用系统，并不需要开发的各种库，所以没有问题（其实也有问题的，因为有些工具仅在第三方包管理上，只是这类工具也大部分都是开发用的）。对于项目依赖的包而言，使用nix进行构建，不仅提供了环境隔离，而且可以方便处理依赖，这就非常轻松了。但是我们还存在一类工具，它们是帮忙开发使用的，比如lsp，他们本身或许不需要依赖什么包，但运行时，是需要依赖到开发项目的依赖的，来提供解析等。这类工具我们不可能放置到项目文件中，而如果从nix-shell中跑一个emacs，每当环境重建这个emacs也要重开，就非常麻烦了。当然也是有解决方案的（不然我写这文章是干什么的）。另外一个问题上面也提了，就是一些软件仅在第三方包管理中，而我们又不能直接使用这类包管理。

大体归类就是几点：

开发辅助工具需要使用编译/运行环境中的信息
第三方包管理
nixpkgs上的包如何自定义，比如neovim加入python支持

解决问题 Link to heading

direnv Link to heading

nix-shell提供了一种可以导出环境信息的方式，而最直接的使用方法就是通过direnv来完成这个过程的自动化。这样就可以在项目目录中，使用开发环境，又不会污染到全局环境。具体使用可以看direnv的wiki

编程语言的思考

Sat, 12 Jan 2019 20:09:12 +0000

工具？并不 Link to heading

编程语言不仅仅是一个工具，更多的是一种思考问题的方式、信仰和对使用者的自我满足。

编程语言是程序员编写程序的工具，把它们当成一种工具并没有什么问题。但是，考虑一下，为什么还有不同的语言呢？不同的语言有着不同的特性，写出的代码也有不同的风格。他们代表着不同的思考方式，不同的开发风格。用过越多不同的语言，这种感觉就会越来越强烈。各类语言虽然本质很类似，但其背后的韵味是完全不同的。

语言从开发范型上可以分成几种，过程式、面向对象式和函数式等。这也是现在最广泛使用的几种。而在这之后，又有静态类型、动态类型之分，又有弱类型、强类型之分。不同语言，又有不同的特点。我大体学过C/C++ C# LISP Haksell Python Ruby Javascript等，这些是使用过的，以及其它学过但从来没用过的，比如Prel Typescript OCaml等，以及读完SICP后，对LISP以及那种解释方式深深着迷。又了解到Haskell，对类型推导以及无负作用的纯函数式感到欣喜。由于还是学生，并没有特别针对工作用的主要语言，各类语言在各种小玩具以及外包工作中可以随意使用。但最近阅读各类资料后，又读了《黑客与画家》一书后，开始思考不同语言的选择。加之，最近又学习了Rust，对于Rust处理部分内容分配方面又开始困惑了起来。GC or not, 动态类型还是静态类型，自由还是受限的自由。

本文更多是对自我一种认知过程。自我的一种思考。内容大量主观，如果有人有幸读到了这篇文章，可以做做参考，但大可不必认真。

我喜欢的到底是什么？什么是适合我的？不，这种答案我已经有了，或者更多是一种确信，各类语言的区别，为什么我要选择这个。很多语言都有我喜欢的特性，但真要我选一个我认真深入、研究、使用的语言我会选择什么呢？领域特定相关必然没有什么好说的，比如写系统必然是C，现在rust的设计也相当出色，但如果要底层特性，恐怕还没有能与C相比的吧。再比如动态语言，动态语言加上扩展，现今也只有LISP吧。那宏扩展至今也没有语言一样的。对语言的任意扩展，是其它所不可拥有的。那么，我希望的，是什么样的一个语言呢？本文会主要以LISP与Haskell为主对比（说白了就我想从这场战争中选择我想要的）。

指针？RAII or GC Link to heading

C语言家族最大的特点就是指针了吧。指针很好的把底层暴露给了开发人员，目测就我所知，包含指针的语言非常稀少。其它语言都在指针上进行的一定的抽象，比如Java，从编译器方面引入了引用的概念，将这一过程隐藏了。带来了开发的便利，但也失去了对底层的操作性。毫无疑问，在操作系统这类性能优先的地方，指针的方案是最佳的。因为人为对特定问题的优化，必然是要高于编译器对大部分普适性的优化的。同时，指针也带来了大量方便的操作。

可是指针也带来了大量安全问题。这就是Rust的提出，不是引入运行时，而是在编译器自动加入了资源的申请与释放，通过语法和编译器进行各种限制，以保证安全，隐藏掉指针等底层特性同时，又有一个轻量的运行状态。这是我非常欣赏的一种设计。有GC的运行时，我们无法知道资源到底是何时被释放的。释放资源时，为了保证程序运行正常，必须暂停计算。从这一层面思考，似乎只有劣势。GC能存在也是有益的。不同与RAII，他可以更高效的对资源进行申请。同时可以把语言底层的一些结构隐藏起来，特别是针对LISP、Ruby、Python这类语言而言。对于动态类型语言而言，生存周期往往是不明确的。大部分动态类型语言的变量的生存周期，并不像静态类型有明确的周期。或者说他们的周期要更长。变动也会更大。编写期间，同样的命名可以用于完全不同的结构，这是RAII难以做到的，除非像Rust那样严格的限制程序员的行为。动态类型的本意就是减少对类型的关注，到高维度的自由。再加限制就有点说不过去了。

性能要求的情况下，指针、动态分配是最合适的。RAII可以用于中间情况，需要性能，但又不需要对内存过度的管理。而GC更多就是对程序员的一种解放。可是啊，为什么Java的设计是GC而不是RAII呢？我并不觉得对引用在编译期的追踪是很难实现的事情。为什么要把这类工作放在运行时，而不是编译期呢？

是的，主要困惑就在此，编译期还是运行期。不管什么语言，为了运行效率，不应该都将大量优化放于编译期呢？当然，本人对GC的了解也不是很深入，实际管理方式应该也有不同，编译期与运行期应该同时做了优化，不然Java的效率运行效率也不会相对其它一些语言而言那么高了。比如说，编译期做了一次处理，运行时为了效率，并不直接释放，而是内存先存着，等再申请时，不再是直接过系统，可以先用弃用的内存。亦或者等内存不足时，再统一释放、申请。但这么就不完全是GC了，其本质更接进RAII就是了。GC或许就类似操作系统任务管理机一样。最大的好处，这是不可否认的。从这类机械式的工作解放出来，关注到更高层次的开发。比如Python、Ruby这类解释类语言，用GC实现是必然的吧。比起用大量编译期解析，不如放到运行期一点点处理。可这是解释类语言哦！Java、C#、Haskell这类语言，为什么还要有GC的运行时呢？大概查询了一下，和之前所写很接近（方便内存管理，不用频繁去向系统申请）。当然这是很浅的思考。仅仅自我主观，并非真实的实现，等到日后，可以回来再做修改本文吧。

动态类型静态类型 Link to heading

动态类型，无疑有着非常多的优势。它提供了非常高度自由的命令空间使用。LISP就是一个典型的代表。提到LISP，或许就要提提Haskell。而Haskell是一个静态类型。那么静态还是动态呢？

首先静态类型可以很好的自我表达。用类型对数据进行的约束，而动态类型更多的就是一种约定。把约定做到极致的就要说Ruby on Rails了吧。约定依靠的是程序员本身，约束依靠的是编译器以及语法描述。这是很矛盾的一件事。个人对二者都非常喜欢。但对一个程序而言，约定可能会出现大量问题，因为我们无法保证输入是合法的，总是要做大量的检测，但是对程序员的信任而言，约定是非常欢乐的一件事，他可以大量节约掉约束种种限制带来的烦恼。

Haskell就是一种静态类型，它附加了推导，这使得静态类型在一定程度上也可以让程序员从类型中解放出来。由于各种原因，现在Haskell是不可能完全依靠推导的，在一定程度上推导已经失效了。但是我认为静态类型还是一个有益的内容。他可以帮助开发者进一步认识数据。对不同数据做相同的操作，加以编译器的辅助，来帮忙程序员更早的发现问题。而这是动态类型做不到的。约定必需假定使用着所做的都是正确的。大量使用约定，与约束又有什么区别呢？只有合理使用约定，这才会使得使用者从繁多的类型中解放出来，但是这是很难的事。特别是对lisp这种类型可以随意处理的，而静态类型可以非常好的自述，针对Haskell，加上类型类的存在，便得这一描述更加充分。可以节约大量文档的说明。说真的，一个类型的说明，要比一大串文档描述来得轻松的多啊。

之前在stackoverflow还是reddit上看到一个帖子，大概就是动态语言实现一个操作，与静态语言实现。比如是一个加法函数add，对动态语言，可以直接返回参加相加，剩下的交给各类其它实现吧。而静态语言不能。当然，这在Haskell是不存在的。因为类型类的存在。而在C中这是完全难以做到的。除非对类型做高度的抽象，但这种抽象又带来了大量使用困难。当然，就算是对LISP而言，要对不同类型做加号（毕竟LISP没有重载的概念），所以也不能一概而论，还是要在函数内分情况处理，反而不如Haskell的类型类或者操作符重载这样优雅。

大部分情况而言，静态类型还是有着非常明显的优势，而且他们并不是在单纯的限制程序员，也在帮助程序员去解释、抽象。动态类型优势在于可以放下对类型的各种困扰以及编译器的各种错误（但我认为，强类型下的动态类型，根本不能让程序员放下类型，类型还是得去思考的，只是不用像静态类型那样处处小心罢了。）

什么？你说弱类型，放弃那玩意吧。PHP等语言弱类型引起了大量的安全问题。而且从底层汇编方面来说，我认为也是相当不友好的。为什么字符和纯数字数据要用相同的编码啊？

上面的观点主要倾向了Haskell为主的静态类型。但是我也很喜欢Ruby的动态类型（Python什么的走开吧。不是很喜欢Python的其它设计风格）。当然类可以封装做到极点的情况下，很多类型限制也就自然消除了。因为，会到这里来的只有可能是这样的数据了。但是LISP不行。很多说LISP自由，他们的数据是由单独的函数进行创建的。哦，这样啊，请问这和C家族又有什么区别？还是没能逃离数据创建过程的限制，只是把这个过程从编译器转到了人工罢了。又何不像Haskell这样，用类型类带来更多的自由呢。约束与约定并不是绝对的。只有像Ruby on Rails这样，做到十分自然的约定时，约定才能让人舒适。这是有代价的，我们要在设计期间考虑大量的情景。LISP当然也能做到这样的事，在扁平化的函数式中引入这种约定，需要大量的宏。

动态类型需要考虑到输入的各种情况，需要应对非法的类型输入，这需要做大量的工作，或者来一个异常处理。而静态类型，这一工作就可以由编译器来完成了。同时也带来了文档上无需长文说明的好处。当然，毫无疑问，在编写效率以及编写方式上，动态类型要比静态类型更加有益。

简洁、自由、元编程 Link to heading

LISP以简洁自称，C也是一样的。但是这是完全不一样的。LISP全部依靠语法树，他的代码与解析过程中的AST没有太多区别。一个好处就是宏带来的大量自定性。可是他似乎有点简洁过头了。有很多明明可以由语言做的事情，却需要由程序员来处理，当然这也代表着程序员有着更多自由。C相对也是这样的，只是这种自由是对内存等更底层的操作，而不是语言工具本身。当然C的宏也很强大。只是还不如lisp那样，可以先计算再返回。什么？你说C++的模板？得了吧。那东西太过于丑陋。完全就是两种东西。当然，特例化也是一个很有意思的东西，他与类型类可以说是非常相似的。

linux邮件列表的一点记录

Sat, 01 Dec 2018 22:10:41 +0000

记录点事情吧。主要是今天发现突然收不到邮件列表的邮件了。大概查了下。FAQ有几种可能会出现自动退订。以及今天重新订阅出的问题。

自动退订 Link to heading

主要原因是网络拥塞，如果出现几次不达就会自动退订了。这个要注意。得要重新订阅呢。

订阅格式 Link to heading

今天回复邮件时各种报错。出现了一些HTML的问题。有点纠结。感觉最大的问题在于用的邮件服务的部分，毕竟已经确定是使用了纯文本发送了。后来就好了。可能是yandex正在修吧。但这个问题还是要注意。但也有一种可能是linux邮件服务在维护。今天，linux邮件相关的页面还404了一段时间。

以后要注意吧。总之记录一下。

ipv6配置记录

Mon, 24 Sep 2018 18:23:30 +0000

最近配置ipv6，出了不少问题。这里记录一下。

配置 Link to heading

IPv6按协议来说，是会自动配置的。但由于普及以及各种兼容问题。在一些情况下还是需要人工配置的。比如ip分配什么的。可以写在/etc/networks内。

dhcpcd也可以做自动配置，但有可能会出现无法配置的情况，就得按上面说的来了。

连接失败（防火墙） Link to heading

要特别小心防火墙。iptables对应IPv6版本是ip6tables，而一些辅助配置的工具，对ipv6的兼容性还没有那么好。有可能需要适当的配置一下。

其中要特别注意ipv6的一些原理，不同于ipv4，ipv6将各类协议整合起来了。所以防火墙必需要通过mld neigh router（IN与OUT）。

调试与内核 Link to heading

编译内核的时候，不小心把CONFIG_PACKAGE给关了，结果网都连不上了。

调试firehol时，没注意打印提示，以为修改已经应用了，但其实是需要交互一下才会实现。不管是多么熟悉的操作，也需要适当去读一下提示。

调试过程一定要耐心，每一步都要确定后再执行。

macos commandline version

Thu, 12 Jul 2018 09:30:52 +0000

起因 Link to heading

安装llvm时出现了编译错误，准确来说是lldb时。

解决过程 Link to heading

去brew上提了个issue。发了各种信息。

然后发现CLT version是10，而xcode的version却是9。

如何导致出这个情况的还不清楚。但整体来说是两者混合使用导致的。

检查方式 Link to heading

经过查找。在macos上，可以使用pkgutil --pkg-info=com.apple.pkg.CLTools_Executables来检查clt的版本信息，而xcode的信息，可以通过app中的关于或者xcode自带的clang、llvm等工具添加--version参数查看。注：一定是xcode自带的版本，而不是自己安装的其它版本。

解决 Link to heading

现在CLT全部安装在/Library/Developer/CommandLineTools下面，可以直接rm -r掉。不删除应该也ok的。

前网developer.apple.com下载正确的版本。最好是和xcode版本对应。

lambd演算

Tue, 22 May 2018 16:57:17 +0000

目的 Link to heading

主要是做个收藏

连接 Link to heading

Good math, bad math

这是一篇相当优秀的文章，然后国内有人做了翻译，见：

抽卡游戏内购思考

Sun, 20 May 2018 17:58:13 +0000

起因 Link to heading

最近少女前线出了不错的皮肤，想氪一下，结果两单没有出货。心态炸了。而最近很咸鱼，完全没有收入，直接钱包就要空了。学生档还是有点伤不起啊。

就想思考一下，如果在保证游戏运营的同时，给玩家带来较好的体验呢？

对比 Link to heading

同类型的游戏有很多，先说说国内很火的fgo好了。这个游戏的氪金主要要素在于角色，而角色是游戏必要工具。且整个系统决定了玩家的强度。也就是说，这是必不可少的一个环节。就了解而言，氪金量大，几乎没有保底。

少前，皮肤不是必要元素，基本元素可以完全不用花钱，但是皮肤类的质量很高。基本也可以说是少前唯一的大收入来源了。

碧蓝幻想，类似于fgo，但是！它除了角色外还包含了武器等元素，全部需要抽取。再但是！这个游戏的战力是配队方式，而不是稀有度，稀有度高战力会高，但是队伍不平衡单体战力高也没用。一般而言，氪金是必须的，但需求要小很多。氪金量的分级也很明显，玩家层区分度较高。提供了有保底机制，有必得超得还有井。基本上白嫖也完全ok，一定会有自己想的。同类型游戏里出货率最低，但由于活动多，主要在于玩家练度，高练度的合理配置，不要一定需要特殊的人物，所以整体体验非常好。而且基础立绘就很赞了。

机制 Link to heading

抽取系统起源哪里不是很清楚，但这套系统和赌博非常非常像，所以在一定程度上保证了企业的收益。

但从玩家角度考虑，纯随机的抽取是非常不友好的。有一定的保底机制才为好。但这个保底不能过高，比如这次的少前，保底是2000rmb，而且还是在首充（两倍）的情况下。那么如何设定这个机制呢？

少前的机制是样本的期望，与总体期望形成无偏统计。但这样对个人而言，是存在很大问题的。

碧蓝也是类似，但由于有一定的保底，所以相对较好。

我们需要一个保证总体的情况下，对个人进行一定的限定。在一定范畴内就会出现。同时，为了考虑到企业盈利，这个机制除了上限，也需要有一定的下限。是否会存在优于抽取的机制呢？比如碧蓝那样，只要够肝，就一定能有回报。

消费 Link to heading

娱乐消费有高盈利是个好消息，说明国民的整体消费观正在改变。但这个值的大小，或者说，我们需要考虑的盈利对象是哪里？是部分的核心玩家？还是大部分一般玩家。以及部分核心玩家，但是却没有什么钱的？

关于这一点，我的观念应该是，可以为一般用户提供一个低消费可自由获取的物品。这样必然可以增加总体消费的数量。同时，对核心用户，提供多方面的获取，比如全部获取，则就需要相对较高的条件，即存获取的数量和质量是与总消费是非线性的关系。对不同群体提供不同的需求。游戏重要的是开心嘛。

附加产品面向核心外，应该存在一定面向一般用户的获取方式。附加是指的可选，但是当可选要素过优于一般要素，那么这个可选就会变成潜在的必要元素。这里所谓的过优包含游戏内一切的设计，从用户角度考虑，当一个不必要设计成为大部分玩家的需求时，那么这个设计就会成为这个游戏的必要因素，成为最基本玩法的一部分了。或许偏离的游戏设计的本心，但这毫无疑问，在一定程度上是设计者的失败。

当其成为潜在的必要因素后，有必要开始考虑将其设计成基本要素，使一般玩家也获取其体验？

此外，对于核心用户而言，过于压榨是否是件好事？用户的耐心必然会消损，盈利也自然是高的。但对于一个喜欢游戏的开发者而言，希望看到这样的事么？至少我是不希望的。

回归本次活动 Link to heading

说回少前这次的皮肤，皮肤不是必要之物，但是如此明显的刺激消费，至少在一定程度上考虑到玩家的游戏体验，去除核心用户外，也应该思考到部分一般用户，如何双向保证？

zsh启动时间优化

Sun, 29 Apr 2018 15:28:21 +0000

查找问题 Link to heading

添加zmodload zsh/zprof到zsh读取的第一个配置文件最上方，一般是zshrc。然后跑zprof就可能看到详细的加载时间了。然后分析吧。

然后可以使用time zsh -i -c exit;来测试总时间。

主要原因 Link to heading

主要引起加载慢的原因有几点。

compinit，特别是oh-my-zsh，很多插件会反复使用此指令，从而导致运行效率低下，而prezpto则相对好一点。但对于bashcompinit是需要自己执行的。

thefuck等使用命令后eval的，首先这类工具已经相对成熟，不会存在经常变更的情况，所以我们可以把这部分生成需要eval的生成到文件内，然后直接source，而不是每次启动去调用一遍。

ssh-agent与gpg-agent等。特别是ssh-agent，在macOS，如果要使用keychain（此指macOS内置的钥匙串），写ssh-add -K会非常消耗时间，其实这个指令是不用每次执行的，只要每次系统更新后跑一下就行了，然后在config里加上UseKeychain yes就行了。而至于agent可以使用keychain来管理（funtoo子项目），会比直接跑来得方便，但是消耗时间会比较大，而prezpto的gpg就模块比较好用。同时再用gpg去管理ssh-agent，简直完美。

插件管理工具，推荐使用antigen，之前笔者用过zplug，太慢了！静太加载似乎是需要人工设置的。而antigen会自动处理静态加载。只有每次修改后的第一次加载会比较慢。

结果 Link to heading

经过一大部分优化，从oh-my-zsh的7s+优化到使用antigen prezpto的1.2s，最后至0.5s。如果把keychain取消，只需要0.2s呢！只要不觉得慢就可以了。

不过fish的速度还是要优于zsh呢。应该是整个过程中还是存在可以优化的问题呢。不过不太想搞了。google查到一个人，fork了一个oh-my-zsh，优化不要的插件和compinit，启动时间仅要0.2s左右，也是相当出色呢。

数学教育

Wed, 25 Apr 2018 19:29:21 +0000

起因 Link to heading

起因是最近考研了，因为一些问题，而同学里考研也比较多，去问最基本的一些东西，他们却答不上来，而却会去做题目。换句话说，只会做题目用的工具和一些方法，而不知道这些方法的证明与推导。

思考 Link to heading

什么是数学，数学是一门自我解释的学科，通过几个公理，而导出定理与推论。这是一整个层层叠加的过程，演绎归纳出各类其它知识。

我们学习的重点，不应该是一个个题目，而是解这些题目所用的知识点背后的思想。其次是知识点，再其次才是题目。而题目是用来巩固知识的，不是为了考试。

考试本身的形式我们保留观点，但是为了考试而考试，为了工作而学习，我觉得是一种非常愚蠢的行为。毫无自主可言。没有自我思考，与死人何异？然而这是现在中国教育非常非常大的问题。不，应该说是社会的问题。社会整体都弥漫这一种你必须要这样做，不管你喜欢不喜欢，只有这样才能做好。只看表象成果，而去忽略内在的思考方式。教育不应该是这样的。考试也不应该是这样的。人生更不应该如此。

题目可以不会做，考研可以考不上，但，我觉得不会用我不能证明的内容（知识与能力不足是另外一回事）。

宁肯一事无为，亦不可迷失自我，忽视本质。

递归中的栈溢出

Mon, 23 Apr 2018 18:42:56 +0000

起因 Link to heading

起因是一道大数计算的题目，题目在此，我们需要计算第10000000（具体是有多少个零没印象了）。有一个同学，用py写，直接跑不出来了。我觉得应该是递归溢出了，就试着用haskell写了，但是也报溢出了。这下就麻烦了，因为我记得haskell是不会栈溢出的才对！

资料 Link to heading

先来上haskell的wiki，stackoverflow。

理解 Link to heading

wiki面写的很清楚，haskell没有传统C一类的call stack，所以自然不会出现溢出，但是这是针对调用而言的，可是，haskell会出现另外一种溢出的可能，那就是对于列表等类型的pattern，如果过多的匹配就会出现溢出了。

所以我这里出现了溢出的原因是在于使用list导致的。解决方案也很简单，按上面写的换成其它类型就好了。比如set什么的都可以吧。

思考 Link to heading

递归 Link to heading

突然让我引起了一个思考，如果对于大量数据计算，如何保证递归的稳定性？

查找资料，只查到了尾递归一种优化。这次算是有了一定认识，然后我们再转回haskell。对于hs，由于一切都是函数，而且没有传统意义上的命令式的顺序结构，所以尾递归无处不在（会写hs的，应该都不会去写递归除了函数以外的返回值吧），而hs对于使用grand形式的条件返回，配合尾递归有非常优秀的优化能力。

对于非hs这类语言使用递归需要特别注意尾递归等问题，需要保证程序运行的正确性。

而对于hs，更多需要考虑的是其它方面的一些意外。

那么是否存在某种优化，可以处理这种方式呢？除了hs这种从根本上处理掉调用栈外，就目前似乎没有什么优化方法。而hs的调用栈是高度依赖于其语言本身特性的，并不适用于其它命令式的语言。

大数计算 Link to heading

问题本质是大数计算，但过多精力放在了处理溢出上，后来才想到，对于大数如何处理？而目前而言，除了C/C++的基本类型外，大部分语言都已经自动处理掉越界问题了。但在编码的时候，需要了解这一点，不需要关心不代表不需要理解。

nixos试用

Wed, 04 Apr 2018 16:07:14 +0000

在虚拟机大概跑了一下，说一下感觉吧。最后的感觉是暂时弃用了。（至2020年，已经完全切换过来了）

安装，很方便。比arch和gentoo相比轻松多了。只要配好分区，一个nixos-install就行了。就是对于gpt+bios好像有点问题。

使用，全部都是配置配置配置配置！！然而，~~我并不能很方便在系统内查找配置信息，虽然有nixos-options与nix-repl，但这些信息量不全，前者只能精确查找！唯一的方案就是上网页去查。gentoo虽然也有网页，但是完全可以在系统内进行查询！~~文档可以通过本地man configuration.nix或者nixos-options以及nix repl来查看。因为配置带来的其它问题就是很多使用习惯的问题。以及用户配置的语法是一个很大的坑。没有仔细看文档是我的问题，但是部分文档很不全。说明也不充分。但熟悉haskell的话，nix相对来说还是比较友善的。

~~全配置~~nix带来的另外问题就是目录和标准linux不一样。很多系统层只能使用配置来完成，而对于开发，由于没有深入设置，所以不好说什么，总有种感觉配置会和软件本身的配置冲突的感觉。

另外一个很严肃的问题在于，用户的配置也要依赖于全局的配置！而不是用户个人，相关讨论，~~到现在为止，似乎也是这样的，这个不是很喜欢呢，~~虽然计算机一般而言就是由系统管理或者单一用户。多用户对于服务器目的在于管理服务，似乎也不太需要这样那样的需求，但总是觉得什么地方心理不舒坦啊。可以使用home-manager进行维护个人使用的部分。~~这也是放弃使用这个系统最大的因素吧。~~

用户较少是另一个因素，导致有些问题处理不全面，相比gentoo一类的虽然用户少，但是相对而言的少，他是有大量人员在维护的，而nix这方面则弱很多。（nixpkgs的pr合并效率时快时慢。但主要的一些软件都有专门的人在维护。而小版本号的更新也有机器人自动更新。）

最后一个非常重要的就是文档了。gentoo、archlinux或是其它的，都有自己的文档，而且相对全面，不全面的参考archlinux都可以了。但是nix的文档太薄弱了。不说其它的包，系统自身的描述都不明确，很多地方说明不清。需要通过阅读nixpkgs的源代码才可以有较好的理解。或者准确来说，是部分文档以注释写在代码内，但没有生成为单独的文档，至2020年8月，有第三方工具可以查找这些文档。

总体感觉，这是一个不错的思考方向，但日常使用还是先放弃了。以后有机会可以再去试一试。

不过那个包管理还可以，如果不和系统耦合过深是可以考虑一下的吧。主要优势在于可复现，同样的配置文件可以复现回同样的系统。而其它系统可能会需要人为的介入。

EDIT: 2020-08-16 修正部分观点

开发环境debug

Tue, 13 Mar 2018 19:12:20 +0000

说明 Link to heading

最近更新过后，emacs打开各种进入死循环，无法正常进入gui。

原因 Link to heading

查找插件，发现是由于rtags引起的。但是rtags并没有什么问题，也没有查到什么issue，更何况也没有出现error，而是emacs进入了死循环（未响应）

最后把rtags的services重启一下就搞定了。应该原因在于rtags更新后，没有更新services的代码，从而导致了某种不知名的问题。

结论 Link to heading

更新完系统后，更新一下services的文件，linux（大部分情况，比如Gentoo等OpenRC管理的）则是init.d中的脚本（对Gentoo而言，这个脚本会自动处理，或者使用etc-update等脚本进行处理），而macos则于homebrew管理（或者是其它管理工具）

gentoo配置makeopt

Sun, 11 Mar 2018 13:36:25 +0000

问题说明 Link to heading

emerge编译llvm时，各种自动killed，一开始还以为是用的vps限制掉了，后来加上-v后发现ninja居然有-j999的参数

原因 Link to heading

在make.conf中的MAKEOPT，设置-j没有加上对应的并行数，默认情况下，这个参数是给make用的，而make没有并行数，也就是不设置的情况下是无限制，但是在部分makefile中，这样会导致使用其它工具而传入错误的参数。llvm的makefile内ninja的-j是由make提供的，所以必须设置。

正确设置方式 Link to heading

可以查看gentoo文档

简单来说，根据lscpu的返回cpus数进行设置就ok了。

学习与教育，思考其一

Sun, 11 Mar 2018 13:32:12 +0000

随便写写罢了。

中国的教育太过应式，很多情况下，都仅仅只是知识的堆积，好比数学，不少老师都是直接讲知识点，然后应用罢了。虽然这样没错，但是我们为什么要学这个知识点？这个知识是为解决什么而提出的，为什么这个知识点是正确的？

学生们，特别是大学生，很多学习只是为了一份工作，是的只是为了工作，这样的学习有什么意义么？不仅学的不深入，更不可了解这个行业的文化，在我看来没有文化的事物是这个世上最值得辱骂的。

学习，应该是分阶段的。最初是引导，不是让孩子去做什么，而是让孩子知道，“我”想做什么。然后引导至，“我”怎样去做，最后引导至“我”这样学习就可以做到。最后变成自主的学习了。当然这样出来的是专才，而不是一个通才，但是通才本来就是少之又少的。

并不是说其它的内容无用。多方面的学习，对单一学科也是有启发意义的。但这种学习，应该是让学生去思考之间的联系，而不是单门分离，各说各的。

生存是必然的，但为了生存而生存是无意义的。生存的意义，不是生存，而是由自我来定义。

一个人的成长，最大决定因素永远是自己。而外界的压力与社会的氛围，仅仅只有在适度的情况下才能起到激励。而现在，对大部父母与老师而言，他们的“激励”都是负作用的。

Gentoo清理不需要的包

Tue, 06 Mar 2018 22:36:01 +0000

首先，要说明，这里所有的不需要并非指不依赖，本文主要说明如何处理掉未知的依赖项，然后清理掉不需要的软件。

depclean Link to heading

最先跑一次depclean，这是最简单的处理方法了，但如果出现某些情况则不可用了。这时优先去按提示把所有缺失的补上，至少这样可以保证系统正常运行

循环依赖 Link to heading

本文写的主要因素为：有些时候（笔者是ruby），ruby2.3居然依赖到了ruby2.2，准确来说是ruby2.3的某一项被依赖到ruby2.2了。类似的情况还存在于python。

处理 Link to heading

方案一：检查依赖，使用euse -I <use flag>，equery d <atom>与eix --installed-with-use <use flag>进行查看。确认你不需要的内容是否是被其它包所依赖。然后清理之。

方案二：检查use flag，特别是对于某些global use flag，如：doc等。

方案三：方案一得出来的所有包，删掉，然后把旧的删除，然后尝试newuse，当然带上tree，也就是emerge --pretend --newuse --update --tree @world来确认依赖状态。然后再去查use flag，基本上，锅就是flag的。

特别地 Link to heading

有些包，强制依赖到旧的包，大部分时候，会被xx_targets_xx这类变量以及portage捕获到，但有些情况下，比如ebuild写得不完善，会出现没有提示的依赖，这时就只能按方案一慢慢查，然后去决定是否留去。

感想 Link to heading

尽可能不在make.conf等全局use变量中写入use，哪怕是global use。

git文件大小写问题

Tue, 30 Jan 2018 21:50:34 +0000

说明 Link to heading

特别注意，在mac和windows上，文件名是不区分大小写的。mac上可以通过修改分区的方式实现（苹果有提供区分大小写的自家分区格式），但是不推荐，因为有一些软件并没有按标准编写，目录是无视大小写的。

但linux默认是区分大小写的。

在一种特殊情况下会出现一种特殊的问题：

你在mac上修改了一下文件，然后add的时候，用了全小写（但是你上一次提交用的是全大写）。然后push，这时你mac内只有一个目录，但linux上，是两个不同的目录。

处理 Link to heading

把git config中的core.ignorecase关掉就好了，这个的值默认是由系统决定而出现不同的值。

你的第一本哲学书

Sun, 21 Jan 2018 18:30:36 +0000

什么东西真的存在？我们能知道任何东西吧？是否真的有是非对错？生命有意义吧？死亡是结束吧？

哲学思考的过程只是提出问题、论证观点、提炼出观念，同时又思考可能的反驳，并且试着发现我们的概念空间是如何动作的。

我们能否认识意识之外的世界？
我们能否认识他人的意识？
意识与大脑之间的关系是怎么样的？
我们是否有自由意志
语言如何获得意义
道德的基础是什么？
何种不平等是不公正的？
如何理解与面对死亡？
如何思考人生的意义？

哲学家总是彼此有分歧，并且任何一个哲学总理都不止有正反两面。

你唯一可以确定为存在的，就是在你自己意识之内的东西

除了你的内在经验和思想之外，其他一切都离你很远，并且只有通过你的内在经验和思想，才可能为你所知。

唯我论（solipsism）

如果有一个外在世界的话，它和你所看到的世界或许完全不同，或许差可比拟，但是无论怎样，你都对此一无所知。世界怀疑论（skepticism）

如果休证明你不可能是几分钟前才开始存在的，你只有把记忆当作是对过去所发生的事情的记录，而这一信念又依赖于过去的确有事情发生的信念。

一个你永远不可能从中本来的梦压根就不是梦：它就是实在——你生活于其中的真实世界（确证论 verificationism）

自我中心困境

我必须承认：实际上，你不可能真的相信自己周围的东西可能并不真正存在。

你的意识是某种与你的大脑不同的东西呢，还是就是你的大脑本身呢？你的思想、感受、感知、感情和厚望等等，是附加在你的大脑中所发生的生理过程之上的东西呢，还是本身就是这些生理过程呢？

你不只是你的身体和运转的神经系统，而有某种更多的东西。

一个复杂的生理有机体，加上一个完全精神性的灵魂（二元论 dualism）

物理主义，唯物主义

脑是意识的发生地，但是它的意识状态并不仅仅是物理状态。这一观点被称为“双面论(dual aspect theory)”

在世界上有两种完全不同各类的东西：一是属于物质实在的东西；二是另外一些属于精神实在的东西，我们每个人都从他自身的内部经验到这些东西。

一切词语都蝏闭发挥作用的：它们意义实际上在于他们使得句子或表达有意义。

你所用的这个词（烟草），背后有某种别的东西——一个概念、观念、或思想，是这背后的东西以某种方式涵盖了全宇宙的烟草。

这个观念或概念是如何与一切实际的烟草联系在一起的呢？

我们所说的、所写的东西——包括这本书中所有的词语——如何可能具有意义？

在任何情况下，我们行动的各种条件决定了我们的行为，并且使它成为不可避免的。一个人的经验、欲望和知识、他的遗传因子、社会环境、各种选择的性质，以及其他我们尚不知晓的因素，这一切加在一起，共同使得一个在具体情境下的行为成为必然。（决定论 determinism）

对民错的标准对每个人来说都一样吧？人们一般认为道德是普遍的。

如何解题笔记

Thu, 11 Jan 2018 18:35:03 +0000

教师应当帮助学生，但不能太多，也不能太少，这样才能使学生有一个合理的工作量

在还没有看清主要的联系或拟订方案前就投身到具体的细节中去通常是无用的。

你能重新叙述这道题么？

建议必须简单和自然，因为不然的话，它们就不可能不露痕迹了。

我应该从哪里开始？我能做什么？这样做我能得到什么呢？

Simplex sigillum veri（简单性是真理的标志）

聪明的学生和聪明的读者不会满足于只验证推理的各步骤都是正确的，他们也想知道各个不同步骤的动机和目标。

你能以不同的方式推导这个结果吗？你能一眼就看出来它吗？

如果这个题目并不难，那么这种创造就不很重大，但不管怎样它总还是一种创造。

如果我们对纤毛一道题目的基本方法如普遍化、特殊化、类比、分解和重组。

如果一个学生从来没有机会解答一道由他自己创造的题目，他的数学经验就是不完整的。

直观的洞察力可以远远领先于形式上的证明。

直觉领先了，但形式推理能超越它吧？你又能否证明它是正确吗？

一个条件如果包括一些过多的部分，就称它为多余的。

一个术语的定义是指用苦命些被认为已熟知的术语来对它的意义进行表述。

数学定义产生了数学上的意义。

在心里用定义的事实来代替被定义的术语。

笛卡尔：“年轻时，每当我听到一些精妙的发明，我就尝试自己来发明它们，甚至是在没有读过那个作者的文章的情况下。在这样的过程中，我逐渐发现我自己正在使用某些法则。”

我们必须搜索一些联系密切的题目；观察未知量，或者寻找一道以前解过的题目，这道题目通过普遍化、特殊化或类比和要解的题目相联系。

把一个生动的猜想当作已证实的真理则是愚蠢的。

越是宏大的计划，越有机会获得成功（创造者悖论）

莱布尼茨：“没有什么比看到创造的源泉更重要了，在我看来，它比创造本身更有意思。”

Respice finmen，意思是，盯住目标。记住你的目的，别忘了你的目标。思考你想的东西。不要忽视你需要的。记住你要寻求的。观察未知量。观察结论。

文字的使用有助于思维。

符号的使用对于运用推理看起来是不可缺少的。

数学符号的使用和文字的使用是相似的。数学符号就好像是一种语言，“une langue bien faite”（一种构造得很好的语言），它简明而准确，它的规则与通常的语法不同，其中不允许有任何例外。

一个好的标记应该便于记忆、便于辨认。

词语具有双重含义。

在分析中，我们从要求的东西开始，先假定它成立，并从中得出某些结论，从这些结论中又得出另一些结论，直到我们得到可以作为综合的起点的那个点。因为在分析中，我们假设要求做的事情已经做好了（要寻找的已经找到了，要证明的已经证明了）。我们研究要求的结论可以根据什么前提得出，然后我们再研究那个前提又是根据什么前提得出的，等等，这样从前提过渡到前提，直到最后我们遇到了某些书籍的或者公认为为正确的东西。这一过程我们称之为分析，或者叫倒过来解，也可以叫回归论证。但是在结合中，要把这一过程反过来，从我们在分析中最后到达的点开始，从已知的或公认正确的东西开始。我们由它推导出在分析中先于它的东西，并继续推导沿着我们的步骤回溯上去，我们最终成功地到达了我们要求的东西。这一过程我们称之为综合，或者构造性求解，也可以叫作前进论证。现在分析可以分为两种：一种是证明题的分析，旨在建立正确的定理；另一种是求解题的分析，旨在求得未知量。

第一条格式的规则是要有话可讲。第二条格式的规则是，当你碰巧有两件事要讲时，你要控制好自己，先讲第一件，再讲第二件，不要同时讲两件事。

他应该注意寻找正确的典范来模仿；他应该觉察到一个能激励人心的教师；他应该和一位能干的朋友竞赛。然后，可能最重要的是，他不仅应该阅读通用的教材，还应阅读优秀作者的作品，直到他找到一个作者，其方式是他天生倾向于模仿的。他应该欣赏和寻求在他看来简单的或有启发性的或美的东西。他应该解题，选择适合他思路的那些题目，思考他们的解答，并创造新的题目。他应该通过这些方法及所有其他方法来努力作出他的第一个重大发现：他应该发现自己的好恶、趣味以及自己的思路。

为什么我们应该学习或者讲授证明过程？什么更为可取：根本不去证明，或者每件事都证明，还是证明其中一些？而如果要证明其中一些的话，该证明哪些？

用数学眼光看世界笔记

Thu, 11 Jan 2018 18:32:41 +0000

从不确定的信息中作出判断 Link to heading

当我们必须要从不确定的信息中作出判断时，应如何是好？排除合理怀疑，判定有罪从数学的角度体现出学习“经验”（贝叶斯定理）当我们获取新信息，只要根据这些新信息来修改概率，就可以降低不确定笥

回归基本原理 Link to heading

理所当然的常识一一被当作公理，只运用这些公理研究事物也许是一个非常繁的过程。但是正因为如此，数学定理获得了永恒的生命。…这正是马斯克口中“从基本原理思考问题”的含义。结合律、交换律和分配律这3条定律加上“1”的性质，就构成了数九寒天的基本原理。不过数学的做法就是意识到它们存在，分别为它们命名并加以验证。连分数苏格拉底：比起认为自己无法发现未知的事物、无法探索未知的事物，我们更应该去探索自己未知的事物。因为后者能让我们变得更优秀、更勇敢、更勤奋。公元前6世纪的数学家毕达哥拉斯发现，两个音符的频率之比构成的分数越简单，两者的和弦就越悦耳动听。三大几何作图问题

大数字 Link to heading

曼哈顿计划费米问题因为只是粗略估算，所以只要保证位数正确就没有什么问题。对数具有透视自然法则的作用

素数 Link to heading

梅森素数上帝创造的了整数，其余都是人做的工作费马检测卡米切尔数 Rsa，欧拉定理

无限与不完备定理 Link to heading

数学的本质是自由（Das Wensen der Mathematik ist ihre Freiheit）连续统假设自我指涉引发的悖论：我正在肩说谎。我们必须知道，我们必将知道 ——哥廷根由有限的数学语言所表示的公理无法证明所有定理

娱乐，故事，深度，中庸

Sun, 07 Jan 2018 13:33:01 +0000

前言 Link to heading

在本文中想以攻壳机动队、素晴日、玲音、EVA等几部作品来谈谈故事性与深度。然后又想到了以前非常喜欢的仙古，于是又联想到了中庸一事，中庸文化，推向大众。

本文想得出一个优秀的作品中，应该有哪些东西？娱乐、故事、深度或是中庸。主要是围绕着这几个元素进行自思。

这仅仅是突发奇想才想写这个内容，内容非常零散，仅是写给自己看的。

娱乐、故事、深度、中庸 Link to heading

娱乐 Link to heading

什么是娱乐？

现代娱乐可被看作是一种通过表现喜怒哀乐或自己和他人的技巧而使与受者喜悦、放松，并带有一定启发性的活动。很显然，这种定义是广泛的，它包含了悲喜剧、各种比赛和游戏、音乐舞蹈表演和欣赏等等。

对于一个娱乐作品，他的首要因素就是让人感到愉悦。一个娱乐作品让人感到开心了，那么它最基本的功能已经达到了。这一点在我一开始写的几部作品中，都体现的相当不错（除了玲音）。

故事 Link to heading

作品让吸引读者，那么故事就是必然的。一个完整的故事、一个完整的世界才能让观者进入，去体验一段平日中不存在的经历。或让人感动，或让人思考，或让人沉入其中，或仅仅是渡过一段有趣的时间。什么是一个优秀的故事？这不是本文想写的。不过至少也要有丰富的情感、迭起彼浮的发展、人物内心的成长或是事件的处理。

比如素晴日，用三章的视角欺诈，把故事讲到了高潮。种种悬疑，让人寒的卓司，让人心痛的柘榴……这无疑是故事上的成功。

再比如eva与攻壳，都以一个相对全新的世界来讲述了一个完整的故事，而且是一个优秀的故事。

但玲音在几部中相对比较差了。使用了大量意识流的手法，故事虽然完整，但是讲故事的方式并不大众。

深度 Link to heading

一个真正好的作品就需要有一定深度了，但是什么是深度？对，什么是深度？社会或是哲学？人性或是种族？这不重要，这些仅仅是一个题材罢了，有人喜有人厌。就像一个文学作品一样，这只是作者想表达的一个方面，并不重要。那么，什么才是重点？

为什么我会提出这个问题呢？最近补完了《攻壳机动队》的TV（并没有看最老的剧场版），剧情回忆这里就不提了。TV中第一季主要冲突是九课与社会及政府高层。这一季作者表达了什么？社会政治性的黑暗、AI的成长，什么是灵，什么是体？人是什么？集体无意识的存在，在这种情况下，主人公所做出来的行为。

这是一部好的作品，它提出了很多人们很少去思考到的问题，人性至社会，再至灵与体的哲学思考。但是，解答呢？女主的行为，从头至尾就是组织的安排，我所能看到的只有为了存活吧。以及为了正确性将成长的AI送出了组织。AI呢？AI的剧情里也仅仅提出了问题，成长，自我发问，然后……为了喜欢的人而死亡。那么作者在这里到底是想表达什么观点？我并没有看出来，我看到的仅仅只有一条条的问题，而没有作者对这种问题的回复。仅仅在最后少佐与笑面的对答中，提及了一点点，以及内中引用了大量知名作品，或许作者也想通过这些作品来表达一些什么吧，介于能力问题，请让我先保留对一季的观点（见下再思考）。

一个只会提问的作品，最多只是启蒙，但一个有深度的作品应该存在着作者的回答才对。提问谁都会，至少上面的问题，现我看来是很普通的哲学问题，不同人对不同的问题有不同的解答，而真正能引人深思的，是解答，而不是问题。正确来说，应该是思考问题的方式。

这一点在第二季中更为明显，主体基本上都存在于讲故事，AI的自问自答，以及结局，或许是一种答案，一种无法言语的答案。但我不认为这是作者想表达的。无法言语仅仅是我自己所导出的可能。

攻壳tv二作，主要表达的还是基于社会上的意图，哲学意图很薄弱。仅仅停留在了提问的阶段。

当然，一个有深度的作品，确实也应该存在着那种，读者可以根据自己的修养来得出作者所不存在的智慧。在古诗词中这是非常常见的。但是攻壳中，我没有发觉作者的这种意图。AI最后的自杀，仅仅让我感到了作者想让大众去深思，而没有给出自己的回复。

再看看EVA，EVA每一个人都是一个缩影，在同样的事件中，每一个人都给出了一个解答，给出了自己那个独一无二的解答。而作者想要表达的就是所有人这种答案的不同与世界吧。特别是旧剧场版最后，对于人、灵给了一种解释。

玲音，大量的意识流手法，加上最后玲音的选择，让我们看到了作者的思考。

素晴日，这无疑是几部作品中解答最明确了（毕竟这就是以给出自己哲学思考为原因写出来的作品）。什么是自我，什么是认知，什么是生，什么是死，什么是灵，什么是体。我们无法知道，也无法言语（tpl.7.）

思考 Link to heading

一个作品至少应该包含着讲故事的基本能力，连故事都不优秀，那么自然也不要提什么深度了。

使用git查找bug

Sun, 24 Dec 2017 19:32:21 +0000

使用 Link to heading

git有一个指令为bisect，可以使用这个进行commit标记，来进行bug追踪查找对应的提交，从而发现bug位置，当然……前提是你的commit是严格按照一个commit为一个atom这样的概念进行的。

参考 Link to heading

博客：http://www.techug.com/post/git-bisect-debug-method.html

git文档：https://git-scm.com/docs/git-bisect

群居与独居

Sat, 11 Nov 2017 09:36:50 +0000

前言 Link to heading

仅仅是个人随心所想，没有一般意义。

正文 Link to heading

人是活在社会中的，群居是不可避免的。但是群居，这无疑会让人变得习惯依靠，习惯放弃主动思考。身边有太多这样的人了。只有独自一人之时，大部分人才会去被迫思考，去探索。

为什么有那么多人，对于十分初级的问题却要去问来问去，明明只要动动脑子想一想，稍微动手查查资料就有答案的情况，却要去花大量时间去问他人？似乎别人才是正确的一样。大概就是群居带来的负作用吧。

当我们与他人一起生活时，无疑会轻松很多，但时间一长，就会发现，独自思考的时间变少了。同时，也很容易被同化。除此之外，还有一点，我们一个人思考的时间会非常非常少。是的，人，一定要有一个人静下心来思考的时间，否则离“自我”会偏离得越来越远。等回神回来，“我”还是我么？同样的，独居相比群居更容易进入学习的状态，更容易沉入自身的世界，更容易去了解世界，了解自我。

我们不可以否定群居，群居就是社会的缩影，否定也就是否定自我。人，不可能离开社会。但是我们应该去尝试独居，去了解自我，不断提升自我，而不是一味的去寻求外物。

操作系统与IDE或编辑器

Tue, 07 Nov 2017 12:38:47 +0000

最近有点纠结是用ide还是用editor，对应的就引来的操作系统的问题。

首先，由于windows各种支持linux子系统了，所以有点开始想去试试。不过最后放弃了。一：子系统的耦合性没有那么理想。毕竟还不能像mac这样直接对接（毕竟mac是unix的底层啊）。二：他用的是ubuntu。

而ide有相当多可观的优势啊。这些是编辑器怎么也无法做到的。

开发项目 Link to heading

最先要明确一点，写mac/ios，不可能去用windows，写windows也不可能去用mac。写linux的你可以用mac（但如果内核相当过大，也不能用mac）。开发平台相关的SDK，肯定是用特定IDE来得好太多，大量的编译依赖，手写肯定不如编译器官方设置好的来的好。而且也没见哪家提供了非IDE用的makefile什么的。而且也没有人用vs去写Linux内核的是吧。

当然要用编辑器来写SDK也可以，只是会各种不方便。

其它情况 Link to heading

当开发是底层了，和系统无关了。这里就出来很多选项了，是用编辑器，还是用IDE。是用windows，还是用mac或者是linux，更甚是bsd。bsd做为生产环境可以，做为开发环境多少有点不太舒服。工具链不是非常全。

OS Link to heading

这里先说OS。去掉编程用的工具链以外，OS提供的其它工具链是选择的主要选择因素。在这一点上mac会相对占优。omni家的全套，以及alfred的快速查找，都很方便。windows上虽然也有对应的工具，但整体用下来不如人意。再来就是界面。win的界面虽然不然算坏，但mac看起来更舒服。一些软件也针对mac做过界面优化，比如印象笔记。windows上的客户端简直无法直视。

其中，最大的问题就是字体。windows上的字体各种不舒服。当然这和显示器也有关系。

工具链 Link to heading

系统直接决定了用什么工具链，在mac上，主流的linux工具链全部是支持的。对于C/C++的情况而言Clang和llvm也是苹果自家在推的，这一点在感性上要优于ms。现在vs虽然也能使用clang了。但在dos下面用linux这类工具链有点不伦不类的。

这一点mac也相对占优。所有底层的工具全部可以和linux配合，除了dtrace什么的是阉割版本有点让人不太舒服。windows的工具链相对薄弱。而且目前除开ide以外的依赖，有相当是直接放弃windows兼容的。还有那难用的powershell。

编写，调试，分析 Link to heading

编写 Link to heading

写代码是占整个开发时间最短的过程。对于小项目来说，根本没有使用ide的必要，反而过于榜单的系统会降低开发效率。但对于大项目而言，ide相比于编辑器提供了大量的高级功能。但这些功能在现在已经大部分在不同的编辑器上都有实现。至少在代码的跳转与补全上两者差别可以说是非常少了。更何况vsc出了lsp后，怕是已经没有差别了。编辑器最大的问题在于项目管理。跳转与补全，很多只针对于当前的buffer，其实这些也能用插件来处理，只是没有什么人这样做罢了。部分比较优秀的工具上面也已经实现了这些。比如emacs上开发c++用的irony以及haskell的intero，都是基于特定项目来实现的。如果不用这些而去配合lsp更是如此了。只是lsp的功能基本还在开发中，用得不人不多，而且不稳定。

在编写上面ide与编辑器差别其它不大。编辑器还能非常方便的去自定义按键呢。

这里推荐一下本人的dotfiles

调试 Link to heading

vs的调试可以说是非常强大，不过这些功能在lldb上也是有的。只不过我们没有界面罢了。对于这一点而言，界面对于那些不熟悉调试指令的人而言会比较方便，而且更为直观。但对于二者都会的人来说，其实差别不大。再怎么好的工具，也是人去思考原因。只是对于非windows而言，可选的调试器非常的多就是了。

开发工具相关插error记录

Sun, 05 Nov 2017 12:49:38 +0000

最近因为一些原因intero的插件各种报错。后来结果重新安装一下就搞定了。这里特别记录一下。

去查了一下issue，原因似乎是因为某些动态库导致的。

当所用的插件需要编译或者外部依赖时，如果使用过程中出现未知的错误（即不是插件本身输出的errro信息），可以尝试去重新编译或安装一下对应的依赖。说不定就能处理了。

用乘法实现除法

Wed, 25 Oct 2017 12:56:08 +0000

为什么我们需要用乘法来实现除法？首先在计算机运算中，乘法的效率要来得高于除法。其次，除法的实现在电路中非常不容易，而用乘法能实现在一定精度下的除法。

证明 Link to heading

downloads: [pdf]({{ site.url }}/static/images/2017-10-25/testify.pdf) [tex]({{ site.url }}/static/sources/2017-10-25/testify.tex)

假设 $$ Q = \frac{N}{D} $$，则：

$$ \begin{align*} Z &= 1 - D \ Q &= \frac{N}{D} = \frac{N(1+Z)}{D(1+Z)} \ &= \frac{N(1+Z)}{(1-Z)(1+Z)} \ &= \frac{N(1+Z)}{1-Z^2} \end{align*} $$

用$$ K = 1+Z^2 $$重复这个过程

$$ \begin{align*} Q &= \frac{N(1+Z)}{1-Z^2} \cdot \frac{1+Z^2}{1+Z^2} \ &= \frac{N(1+Z)(1+Z^2)}{1-Z^4} \ \end{align*} $$

重复N次

$$ \begin{align*} & Q = \frac{N}{D} = \frac{N(1+Z)(1+Z^2)(1+Z^3)\dots (1+Z^{2n-1})}{1-Z^{2n-1}} \ & \because Z < 1 \Rightarrow \lim_{N\to 0}Z^{2n-1}=0 \ & \therefore Q = N(1+Z)(1+Z^2)(1+Z^3)\dots (1+Z^{2n-1}) \end{align*} $$

浮点误差

Sun, 15 Oct 2017 16:44:11 +0000

浮点运算不同于整数运算，是存在大量误差的。这是因为在计算浮点时，为了处理下溢问题，引入了“舍入”和“截断”

截断 Link to heading

这是最简单的处理方式，直接截断特定位数后的所有数据。这样会产生诱导误差。而且这个误差是偏置的，所有截断后的数一定小于原数据。

舍入 Link to heading

这个是相对减少数的位数的技术。如果丢弃的位的值大于剩余数最低位的一半，则将剩余数的最低位加1。这样统计总体上而言是相对精确的。

使用 Link to heading

在一般使用中，是可以无视浮点误差。现代计算中，这类误差已经小到几乎可以忽略了。但是在一些科学计算领域或者高精度要求的方面，需要注意这个问题。有必要时可以考虑使用整数（放大）代替浮点。或者自行封闭浮点操作。

使用Gentoo的数个理由及注意点

Tue, 03 Oct 2017 00:00:00 +0000

Gentoo Link to heading

关于Gentoo是什么这里就说了，不知道的朋友请自行查找或者不要使用这个东西了。

Portage Link to heading

这是Gentoo的核心，除此之外一无所有。

通过Portage我们可以做到：

滚动更新 (arch也可以)
自定编译选项（其它包管理是通过子包处理的。虽然都是人为定义的，但是useflag拥有全局配置，可以减少重复，同时gentoo提供更多的选项）
slot(这是什么？这是一个好东西，他可以在你的系统上安装多个不兼容版本的同一软件，而且不产生冲突！主要可用于包管理自动完成库链接，而不需要人为处理。当然，其它包管理也有一些替代方案，如使用包名加版本后缀，但感觉不如slot优雅。是的不产生冲突！其它发行版一般是通过改名大法完成的。但是gentoo不是，内部自行处理，这样带来的另外一个好处就是我们的系统上就算大量滚动更新后，也会有相对稳定的运行。而不会产生像arch那种，大量更新后系统就炸掉了，笑。)
回滚（大部分包管理的回滚都比较麻烦，而且回滚后如果再更新会重写掉，还是会更新。但是portage通过mask可以完美处理。）
很多人说对初学者不友好，但是其实有提供 env-update etc-update fixpackages等大量工具。只要会看文档，总是能处理的。
wiki(虽然arch更好一点)
兼容性。gentoo同时提供大量cpu型号的支持。兼容性可以说是完美的。
系统修起来很方便。就上上面写的回滚。一张livecd上去，改改mask然后changed-use，就可以了。不像其它系统搞不好你还得回滚到之前的发行版本
测试分支与稳定分支可以混合。至少这点在其它系统上很少见，或者得人工操作，包管理本身提供非常少相关的部分。我们可以只对我们需要的部分使用测试分支，其它不关心的用稳定分支就行了。同时保证了需求与稳定性。
通过patches和hook可以实现部分操作的自动化。

注意点 Link to heading

清理，定期用一个eclean是个好习惯。不然空间可能会炸掉。原因在于slot以及你安装了大量可能不会用到的包。删包时记得要depclean。
默认全部是使用编译安装，需要节约时间的请查文档：quickpkg
openRC，这是gentoo默认的启动，为什么不是systemd？虽然慢是慢了点，但是你看看systemd那一大串依赖。而且，systemd评价不是很好。如果不是强行和redhat打包，目测没有什么用。实际上如果你不用gnome，根本用不上systemd这种东西。
overlay(如果是以开发环境使用，一定得要使用overlay，部分包是为了系统稳定是旧的。或者至少对部分的mask要进行配置，但是配置过后你会觉得你的系统非常舒服，没有什么是你不需要的。)

EDIT: 2020-08-16 修正部分观点

gentoo USE 注意点

Sun, 03 Sep 2017 15:43:07 +0000

Use flag注意点 Link to heading

大部分在文档里都写了，但是有一些内容，并没有在文档中详细说明，可是如果不这样做，会经常出现问题的！！！

不要包含在global flag内 Link to heading

doc ( 这个非常重要。特别是对于ruby以及python等语言来说，会引起大量的循环依赖）
test / debug ( 这个应该没有什么太多要说的必要 )
source / examples ( 并没有什么太大问题，就是有点浪费空间，还是请针对性的使用 )

通过ssh连接虚拟机

Thu, 31 Aug 2017 16:52:39 +0000

需求 Link to heading

在虚拟机里直接跑还是不太方便，一个是键盘我们得重新设置，另外在没有界面的情况下，看起来也不舒服，各种不如ssh来得方便。

虚拟机配置 Link to heading

使用NAT网络（也就是共享本机网络）就可以了。VM等网上教程很多，这里主要说的是Parallels Desktop。

网络段 Link to heading

网络段分为A,B,C,D四个。其实A段中的10.x.x.x是子网，也就是本机内部网络。如果不使用NAT，也可以使用桥接等方法与C段网络，也就是局域网配置。

通过各种工具来得知ip。然后ssh就行了。其中，最主要是得知道10.x.x.x的网段是本子的，一开始还差点以为这个地址是外部网络，才以为不能连接呢。

在vps中安装gentoo

Tue, 29 Aug 2017 14:17:23 +0000

基本过程和平时安装一样的。参考Handbook就好了。需要注意的有几点。

分区 Link to heading

对于虚拟化的情况，硬盘使用的是/dev/vda，而不是家用机中的sda。在fstab配置的时候，也没有必要去配置cdrom等没关的东西。

内核编译 Link to heading

大部分情况下，需要开启VIRTIO_PCI与VIRTIO_MMIO，以及其它的几个选项。参考：Wiki

Grub2 配置 Link to heading

注：以下本人使用的grub2并没有对应参数。。嗯。有点迷。。可能是文档有点旧的原因。

如果在硬盘使用为vda的情况下，需要添加并修改/boot/grub/device.map。同时需要使用grub-install --device-map。参考：Wiki

开启Docker Link to heading

参考：Wiki

吐槽：选项真多。要是有什么脚本一次处理就好了。

haskell包管理处理

Wed, 16 Aug 2017 08:19:27 +0000

cabal 与 stack Link to heading

stack没有什么好多写的，这就是一个自管理数据库的泥沙盒。和一般的虚拟环境不太一样的是，由一个用户管理其所有的全部环境，所以不会存在同一软件多次被安装而占用空间的问题，同时也可以使得多个工具可以共存。但是这个工具有一个问题，就是不太好清理，想清理得自己进目录下面来一删。而且删除时，也会影响到依赖数据库。

cabal是haskell本身所提供的，但这并不是一个传统意义上的包管理，准确来说，这不是一个管理工具，~~只是一个安装工具！~~只是一个构建工具，构建内包含了安装依赖的过程。是的，它只提供了install。想删除，也得自己进目录去删。同时update只是针对list，而不是packages。如果在全局安装的话，update后要人工进行一次reinstall。

haskell软件发布应该像c家庭那样，由专门的包管理工具或者自行编译安装。不论是cabal还是stack，都不是以管理包为目的，其是以开发构建为目的设计的，不可以弄错根本。所以不论二者那个，都不建议在全局安装库包。对于执行工具而言，开发工具直接使用stack会比较好。比如intero或ghc-mod。因为stack是全局管理唯一，再配合插件使用会相对优秀。自动初始化。

~~但对于hoogle一类工具而言，使用cabal安装会比较好。配合全局ghc进行使用。或者针对项目进行一次install~~

而cabal虽然也能使用sandbox，但这样一来得手动处理PATH目录，stack会自动将文件放至~/.local/bin中，当然这样带来的另外问题就是我们得需要安需install一次（但其实配合开发插件，一般这个过程会自动完成）。

宏，eval，函数

Thu, 03 Aug 2017 22:51:21 +0000

本文以lisp为主

函数(function) Link to heading

函数就是一个子程序，执行即运行求值

eval Link to heading

求值，不过工作于用户层

宏(Macro) Link to heading

与函数类似，但是不是用来求值，而是计算求值过程。然后调用后执行求值过程。

但又与eval不同。eval是在执行中解析且运行，而宏是编译期先计算过程，之后同函数一样。这个与C语言一样，编译期展开，所以在效率上要高于eval。

emacs自配置或使用spacemacs

Thu, 03 Aug 2017 00:46:30 +0000

为什么使用emacs或vim Link to heading

高定制性
编辑特性

为什么有公用配置文件 Link to heading

快速上手（开箱即用）
减少成本

思考 Link to heading

我们使用emacs这类软件，目的是为了可以高度定制性。我们在这些软件中可以控制一切。而emacs因为lisp的特殊性（这个软件就可以说是一个emacs lisp环境），基本可以做到任意程度的定制。

如果我们使用了一个配置好的文件，开箱即用了。这个配置，做了什么，以spacemacs为例，它包含了大量插件，以及使用配置。同时也提供了一个配置接口，让我们可以二次配置。可是这些大量插件我们需要使用么？唔……不好说啊。虽然我们可以禁用他们，但是不用的东西还存在干什么？

可是这样有什么意义？了解emacs？了解vim？确实有用，但是不深入，入门可以，但不应该做为最终长时间使用的工具。何况这个过程中，对lisp或者vimscript真的了解很多了么？

和在用那些IDE或者其它编辑器又有什么差别呢？因为这于使用类似于atom或者vs code又有什么区别呢？我们打开他们和spacemacs后，都包含了大量插件以及定制好的操作。没有什么区别吧。而且其它的现代编辑器，在各种方面还要优于emacs吧。

通过自己配置，可以做到只留需要的部分，而且自己写的代码，就算很差，也能有自行维护的能力。更何况，我相信能自写配置的人，代码编写能力不会太差的（对于vim而言，其配置思想主要是变量，在难易度上要比emacs更容易上手与配置）。想要做什么修改也很方便。更不会出现用到一半出现了bug，为了维护却要先花大量时间去阅读代码。

而且，对于一个可配置的东西，我却用别人配置过的再配置一次，这能叫定制么？

更深入一点，我们用linux，大部分人应该用的都是发行版（可以自己下内核编哦～不过太麻烦了，还是算了吧）。而大部分发行版都是按版本，以及内含大量工具的。确实在生产中会很方便，但对于个人而言，用着这大量你不需要的工具，你内心不痛么。当你接触过gentoo或者arch。从分区到内核编译再到全手工定制，这种快感以及控制性，真是太棒了！！咳咳！比如ubuntu的apt-get，虽然易于上手，但在各种其它方面都不尽人意，特别在于编译配置方面，同样的，yum与dnf也是一样。后二者是通过同一软件分多个子包来完成。这个方法，真是不敢恭维。而对于一些编译选项集合，可能就会出现无法同时使用的情况呢。自己下代码编译？不错，但是更新管理会比较麻烦。这时arch与gentoo就体现出来了。特别是gentoo，因为是纯手工编译定制，还提供了更新。arch是二进制，但也可以高度定制。这不妙哉？

结论 Link to heading

没有耐心或者学习精力，却又想要用emacs的，就用这些配置吧。只是，我认为毫无意义。
快速上手，用于学习过度，但不适合长时间使用。
最终转向自行配置，学习优秀配置文件的思路。比如spacemacs的结构已经layers思想。
折腾是一个hacker应有的精神。不是自己定制的东西，能叫定制么？

从vim转至emacs的理由

Wed, 26 Jul 2017 10:23:17 +0000

笔者以前是使用vim写代码，因为vim和emacs一直处于被讨论的情况，所以很自然就去了解了一下，最开始是spacemacs，然后弃了（不管怎么说，这不过是在用别人的配置。没有意义，这样不如直接用atom什么的）。后来去学习了一下emacs操作。了解了evil。以及elisp（如果学过scheme或者common lisp的话，elisp可以直接上手，基本上没有太大差别。就是文档习惯有点不太一样）。

为什么从vim转至emacs Link to heading

编辑器本身的效率

这个最大的问题就在于执行上面。vim上对于php以及html的高亮有着致命的效率问题（也有可能是本人使用的高亮差件优化问题）。当文件过大时，在移动等方面也存在问题。对于项目而言，如果开启了过多的buffer，也会导致一定上切换不流畅（强迫症患者）。
开发效率

emacs被称作没有编译器的操作系统。在emacs里面可以做到任何事情。当然，对于vim而言，是非常符合unix风格，一个工具只做一件事。但是对于项目开发而言，我们想要的是在一个界面下做到大部分事情。而不是切来切去（不过在命令行上面做各种其它事情未必比emacs上慢）。

最主要的原因还是在于项目目录处理上。vim有一个工作目录。以此为基准，虽然也衍生出了非常多的项目管理插件，但总体而言，都不如emacs来得舒服。
界面

emacs存在着非常好的GUI，而vim没有。
emacs能尽乎完美得模拟vim

是的，emacs是我现在对于vim行为模拟最完好，而且能和vim各种操作完美转换的。对于其它各种编辑器，除了在编辑过程是是vim外，其它比如文件切换啊等等，还是主要依赖于编辑器本身的一些快捷键或是鼠标。

如何选择 Link to heading

服务器端，必然是vim
项目开发，emacs首选
小文件、脚本编写，vim来得方便

结论 Link to heading

说白了还是外观和效率，vim在一部分表现上面确实不如emacs。但是vim相对emacs从配置到使用（这里的使用是忽略编辑器那个hjkl什么的特性）要简单。

所以，vim和emacs都得使用。vim主要进行简单的编辑，所以在配置上不用过于复杂，有一定基本就行了。而emacs则能完则完。不过嘛……就个人习惯而言，虽然用着emacs，但是配置不是很全，而且还是会习惯性切回终端来操作，毕竟打命令还是来得要方便点。

不过更多的时候还是看心情来使用吧。毕竟emacs虽然很强大，不过有一些东西还是在GUI上操作比较方便，比如GTD什么的。

最后上一个笔者的配置文件：dotfiles

求值环境模型

Sun, 09 Jul 2017 15:43:01 +0000

记录为主 Link to heading

本博文是以SICP第二版3.2节内容为主进行的记录。

概述 Link to heading

在所有编程语言中，调用函数时，会有一个上下文，这个上下文中包含着我们的环境变量。这是没有任何疑惑的地方。比如说，用C/C++写了一个函数，调用其，实际参数会赋值给形参（形成一个拷贝，指针的情况，就是把这个地址进行了拷贝，不是地址的内容罢了），然后所有的操作，在这个拷贝的环境中实现。也就是局布环境框架。

思考 Link to heading

这是对于大部分主流的编程语言来说，没有问题。是的。看起来很美好。让我们思考一下，如果我们可以以函数人作为返回值，我们在这个返回值中，修改了外层环境的参数会怎么样呢？

详细 Link to heading

See more: SICP Article

先拿lisp来说事，就以sicp上的scheme代码为例。

(define (make-withdraw balance)
  (lambda (amount)
    (if (>= balance amount)
        (begin (set! balance (- balance amount))
               balance)
        "Insufficient funds")))

;; Let us describe the evaluation of

(define W1 (make-withdraw 100))

;; followed by

(W1 50)
50

深度优先，广度及迭代深度优先

Sat, 13 May 2017 20:31:10 +0000

在学习搜索的时候，对这三个，主要是后二者有一点点混乱，所以这此记录一下。

深度优先 Link to heading

优先遍利子支的最深层。

广度优先 Link to heading

优先遍利每一层，之后再遍利子支

迭代深度优先 Link to heading

就是加一个限制，以到某一层为界，然后进行深度迭代。非常像广度优先，但是！！有一点不同！！当深度增加后，不再是遍利完所本层再进行子支，而是优先子支。这样一来，当深度不段增加后，与广度优先的区别就会越来越大。

比如， a -> b0 -> b1 -> c0 -> c1是广度优先，那么迭代到第三层后，就会变成a -> b0 -> c0 -> b1 -> c1。这么种感觉。当深度越大，这种区别就会越大。

一般而言，可以用迭代深度优先替换广度

参考 Link to heading

深度优先，广度优先和迭代加深搜索算法

连接本地docker内的mysql

Sat, 06 May 2017 19:57:49 +0000

问题描述 Link to heading

docker开起一个对本地的mysql后（Port已设置），但运行mysql -u root -p后会出错

解 Link to heading

其实是mysql对localhost这个地址，会自动检查本地的进程，然后不是通过一般网络访问，而是直接进行套接字串输，而对于我们用docker，当然没有sock文件和对应的进程啊！！

解法一种是改Mysql设置，把配置中的sock文件改改，改成docker中的。或者最简单的，在连接时，显式把host设置成127.0.0.1，或者其它本机ip。这样就可以了……

Haskell类型限制

Sun, 23 Apr 2017 13:06:18 +0000

起因 Link to heading

起因其实是关于catch以及catchIOError。对于catch，一开始，博主怎么弄都是错误信息，最后的原因是在于lambda中第一个参数的类型是非确认而引起的。

catch和catchIOError的原型：

catch   :: Exception e
        => IO a         -- ^ The computation to run
        -> (e -> IO a)  -- ^ Handler to invoke if an exception is raised
        -> IO a
catch act = catchException (lazy act)

catchIOError :: IO a -> (IOError -> IO a) -> IO a
catchIOError = catch

官方文档中对于catch的用法给了一个例子

catch (readFile f)
        (\e -> do let err = show (e :: IOException)
                  hPutStr stderr ("Warning: Couldn't open " ++ f ++ ": " ++ err)
                  return "")

【想通问题之前的博主言】这样一来，问题就出现了，为什么官方的例子中没有限制e的类型，确可以实现呢？

分析 Link to heading

从最根本一点点来思考吧。

函数式编程语言之多语句思考

Wed, 19 Apr 2017 16:00:23 +0000

函数 Link to heading

先来说说一函数吧。对于大部分编程语言来说，函数是一组语句（准确来说是表达试）的集合。对于这些语言来说，语句是基元。

函数式 Link to heading

对于函数式编程语言函数才是基元。那么，一个函数只干一件事，就是一个表达式。如何执行多条语句？我们总不能全部放到全局域下吧。而且，全局域下，也会只有一个入口点的（我们不要说Common Lisp）。

这样一来，如何在一个函数中处理多条语句就是一个大问题了。

lisp Link to heading

对于lisp而言，所有都是list，语句也不过是list。那么这样好办了。把所有的语句当成参数传进去，然后参数当做一个list，遍利去运行。这大概就是progn的做法（当然，从编译器层面做的可能性更大，因为这样会比较高效点？）

这个完全依赖于lisp本身的语言特性

Haskell Link to heading

Haskell不同的lisp，他是有类型的。所以当然不可能像上面的方法来做了。当然，你要是说把所有操作当成lambda封到[]里，然后再去遍利，我也是没有话说。

不过先来看看官方的做法。学过Haskell都知道do语法。而do的核心是单子。这样一来就相当于无限多个函数嵌套了。

先想一下单子的操作符>>=，原型是x >>= f = join $ fmap f x，然后再考虑一下Haskell的函数式特性，我们每一次传递一个新的函数后，只是不断的去整合函数，然后返回一个函数。只有当最后一个参数提交上去的时候才会正式执行。相比于lisp，要优雅得多啊。变量还能向下传递的。可以和let说再见了！

不过可能需要担心一下调用栈吧？好象不用太担心……因为没有人会写那么深的函数吧。呃。。这个博主也有点说不太清楚，嗯。要学的东西还很多。。

笔记使用工具

Wed, 19 Apr 2017 11:52:13 +0000

最近对使用的工具整理了一下。一开始是使用印象笔记来做各种笔记整理。后来转到了MWeb，但是因为印象笔记没有比较好的导出方案，所以就还是使用着那个。两者同时。后来学了Org，基本上部分文件从markdown转到的org去了。

不过org有一个很大的部分，就是除了emacs以外，完全找不到能读取的工具，就连gitLab的支持也让人担忧呢。另外一个很大的问题就是对中文字体的对齐，特别是在表格之中。虽然能设置成对齐吧，但是这样宽齐了高又不齐了，真是让人心累啊。

最后的结论是，文档类还是使用org，复杂的可以使用latex，或者rst。之外日常笔记使用印象笔记，虽然不支持markdown是一个硬伤，但是从同步以及网页的截剪等等都是相当方便。之外日记使用Day one。什么？MWeb，留着开一些markdown文档吧。只能这样了。因为没有必要把那么多文件分开使用不同的笔记文件来做在座啊！！

《上帝掷骰子》-量子力学史话笔记

Wed, 19 Apr 2017 09:28:00 +0000

一个希望与众多科学问题搏斗的人最好还是远离大都市。 —— 亥姆霍兹 to Hz

以太

吾爱吾师，但吾更爱真理

数学解释一切

当你把一切不可能的结论都排队之后，那剩下的，不管多么离奇，也必然是事实。

谈论任何物理量都是没有意义的，除非你首先描述测量这个物理量的方式。

我们测量的对象都是如此微小，以致我们的介入对其产生了致命的干预

当样本数量变得非常大时，概率论就很有用了

我们一直理所当然地使用“观测”这个词语，却没有给它下一个精确的定交。什么样的行为算是一次“观测”。

如果把你“毁掉”，然后在另一个地方“重建”起来，你是否认为这还是“原来的你”。

悖论：一粒落地不算一个沙堆，两粒沙勤务员地不算一个沙土人水言，但10万粒沙勤务员地肯定是一个沙堆了。那么，具体到哪一粒沙落地时才形成一个沙堆呢？

意识不是一个独立的存在，而是系统复杂到了一定程度后表现出来的客观性质。

笛卡尔第一原理：不管我怀疑什么也好，有一点我是不能怀疑的，那就是“我在怀疑”本身，也就是著名的“我思故我在”！

人择原理

虽然上帝神秘莫测，但他却没有恶意

在物理上，过去、现在、未来并不是分得很清楚，至少在理论中没有什么特征可以让我们明确地区分这些状态。站在物理的角度谈“历史”，我们只把它定义成一个系统所经历的一段时间，以及它在这段时间内所经历的状态变化。

我们生活在一个四维世界里，其中三维是空间，一维是时间…最关键的一点是，它似乎是有方向性的！…但在时间上，你只能从“过去”向“未来”移动…这样的猜测的理由还是基于某种类似于人择原理的东西：假如理论上可以回到过去，那么虽然我们不行，未来的人却可以，但从未见到他们“回到”我们这个时代。

上帝不但掷骰子，他还把骰子掷到我们看不见的地方去。

无边界假设

任何粒子其实都不是传统意义上的点，而是开放或者闭合的弦。

罪之光约会小感及一次项目记录

Fri, 07 Apr 2017 23:10:03 +0000

中二社 Link to heading

在上月底，中二社新作也出了，看起来整体回血已经差不多了，可以好好期待期待sppl2呢

剧本 Link to heading

简直一模一样的套路啊。不过姐线还是可以的。不应该说……我果然对这种禁忌很有感觉才是呢。

其它 Link to heading

本作总体上来说都是相当出色的作品，除了剧本。

网站？ Link to heading

其实在打这个游戏的时候吧，谈到了一个项目的网站，期间看到了另外一个人的个人网站，那个设计相当好呢。不过主要是作品展示。现在在想，这个网站风格，大概只能用于写写程序吧。如果让我写galgame什么的怎么办呢？这个网站的样式还有风格，说不定，并不适合我呢？有空去试着再设计一个新的样式好了。果然我还是喜欢华丽一点的么？

函子，应用函子，单子

Sat, 18 Mar 2017 12:38:47 +0000

Haskell Link to heading

嗯，继续写函数式。之前有比较过，也提及过关于类型类相关的事。这次主要写写单子吧。主要是这个东西学起来快，但是真的理解有点麻烦啊。

函子(Functor) Link to heading

class Functor f where
    fmap :: (a -> b) -> f a -> f b

这是函子的定义，函子的主体就是范畴论。通过这种方式来完成类型之间操作（函数）实现推导。这是非常有意思的一个东西。因为通过这个方式，我们可以只针对底层类型进行实现，然后通过一个函子，完成高级类型的推导。不兴奋么？

不过这里自然有很多疑问了，最困扰博主的问题是，这个函子的概念，一定要用Functor这个类型类么？因为我完全可以通过自已写个类型类实现。最后去stackflow上请教了一下 URL。最后得到了一个非常不错的答案哦。

Sure you can do this. It’s just kinda reinventing the wheel. The advantage of standard classes is that everybody will make their types instances of them if appropriate, so if you write a function that can operate on a generic Functor f then it’ll work with a huge number of different type constructors f from hundreds of libraries. If you change the function to require MyDataFunctor f instead, it’ll do exactly the same thing, but only with your own type MyData.

CL与Scheme与Haskell

Sun, 12 Mar 2017 16:03:00 +0000

最近开始学习Haskell了，同样是函数式语言，当然少不了对比。因为Haskell还没有完全学完，所以表达可能有点不太完善，不过现在已经完全想走向haskell了。

这里博主打个不太好的比方，

如果scheme是C语言，那么Racket是JAVA或C#，common-lisp则是Objective-C。而Haskell是C++

Haskell是一个纯函数式语言。不同于CL的多范式。它在函数上进行了一步步抽象，比如类型类，比如函子，比如单子。一切都是函数，一切都是数学，一切都是概念，一切都是证明。而相比之下，lisp更加倾向与过程式，在函数式之中，加入了面向对象的部分。

Lisp最大的优势，在博主认为是一切都是列表以及宏功能。宏功能是非常非常吸引人的一个部分。

但Haskell更多的不是语法上，而是思想上的升华。它完全可以代表数学。函数就是一个表达式。一组函数，可以用来解一个问题，一类问题的通解，就是这一组函数的抽象。这就是博主对类型类的理解。而在这之上的函子（functor），就是同类问题，在外部又加了一层问题来进行包装，进行推导来得出的通解。

Haskell完全可以理解为一个纯理性，纯数学的世界。

记一次作业程序

Sun, 05 Mar 2017 12:48:00 +0000

题目 Link to heading

Description Frog have a very simple problem for you. Given two integers A and B, you are required to calculate the Result of A + B. Input The first line of the input contains an integer T(1≤T≤20) which means the number of test cases. Then T lines follow, each line consists of a complete formula, A+B=. The length of each integer will not exceed 10000 and B must be positive.

Web服务器日志分析工具

Sat, 04 Mar 2017 21:34:00 +0000

服务器弄好了。之后就是要开始做监控了。主要是想针对流量做监控。比较好的工具有google analytics什么的，不过由于google在国内，嗯，大家懂的。所以只好找找其它的了。

日志分析 Link to heading

日志分析工具比较有名的就是webalizer, awstats这两个，不过这两个比较古老，而且界面有点难看，就被笔者给舍弃了，不过这两个工具其实还是非常不错的，相当的网站也有用这些个工具，另外一个博主要在这里写的就是goaccess。这个也不能算是新物吧。不过就网站来说，比较合现代，而且文档全面，性能也不差，最主要的是提供的功能并不差于另外两个。

官网在这里。

安装的话，也比其它两个相对方便，至少goacess在各种平台的包管理上都是有的，而webalizer在部分包里面是不存在的，大部分情况是要自己去下来编译的。

使用方法，有终端的输出，也可以到json, cvs, html。终端上是提供了一个相对友好的界面。使用的话看文档就好了。这个东西并不复杂。

流量分析 Link to heading

流量分析一般就是google或者baidu各种工具了，不过博主不想用百度，而谷歌无奈，最后找到了piwik这个工具，和google差不多，这是一个基于PHP/MySQL的工具，在页面加上相应的js后，就能解析了。日志分析更加偏向于请求以及响应分析，而这个工具会更加倾向业物性的。而且界面友好。安装和大部分php工具一样，只要提前准备好MySQL的用户和库，和PHP服务器就好了。博主自然是Nginx+Apache来完成的。

linux虚拟交换内存配置（文件）

Fri, 03 Mar 2017 18:13:00 +0000

其实这个东西是非常简单的。但是因为服务器只是偶尔配置一次，所以还是写个博文记录一下吧。

# 创建文件，以1K为单位，这里后面是创建了，4G文件内存。
dd if=/dev/zero of=swapfile bs=1024 count=4194304
# 移动文件，这一步可以不做的，或者写个比较方便的地方。。比如根目录？
mkdir /mnt/swap/
mv swapfile /mnt/swap/
cd /mnt/swap
# 改变权限，建议权限是600
chmod 600 swapfile
# 启动
swapon swapfile
# 如果想要关闭则使用
swapoff swapfile

如果想要开机自动加载，则在/etc/fstab中添加：

/mnt/swap/swapfile swap swap defaults 0 0

就是如此了。

owncloud安装问题记录

Wed, 01 Mar 2017 16:54:00 +0000

今天又把服务器安装了一个owncloud玩玩，虽然主要数据还是存在dropbox上的就是了。

这里主要写一下配置问题吧。中间被坑了几次（其实是本人理解有问题可能）

网页安装过程 Link to heading

网页安装过程，在填写数据库信息时，最重要的！！切记的是！！这个用户名和密码，是指拥有mysql管理权的，不是单个库管理权的，因为oc会在这个过程中，创建一个专门用来管理库的用户（没有必要我们自己提前建立）。当然，库还是要提前准备的，这里不一定要写root，只要是有创建用户、修改数据库权限的用户就行了。然后会根据一开始写的管理员用户，来创立一个专门管理这个oc库的用户。用习惯wordpress或者之类的东西后，会有点定向思维了。呵呵。

Nginx与Apache Link to heading

这个主要是本人能力问题，因为想建Nginx与Apache双服务器的。一开始只是单纯的把所有请求都专到Apache上，不过这样不行的呢。对Nginx也要有一些设定，而且Apache不能完全按官网上，博主这里是用的fedora dnf包里的owncloud-httpd，他会默认把所有设置包到最外层。这样必然会有影响，最后的解决方案是把Nginx与Apache的官方配置各用一部分，然后再把Nginx上转到php的部分给换成转到apache就好了。

最后要注意一点，因为oc内部会根据请求的url来生成网站内的链接，所以在nginx中，还要设置好proxy_host等信息（这个其实比较常见，只是博主一般都是写python什么的，依靠uwsgi，都是现成部品，完全没有关心过这些）。

还有一点是关于X-XX保护的，需要关一下……毕竟是从原域名跳到的localhost，虽然也能写成一样的，不过写本地以后万一改起来会简单点。

gitlab安装问题记录

Wed, 01 Mar 2017 11:54:00 +0000

最近开始重新整理服务器，安装gitlab时，出现了不少问题在这里记录一下。

useradd Link to heading

官方上面，用户的useradd有一个--disable-login的参数，这个是只有debine包内才有有的参数，目的是禁用登陆，而在fedora中，或者更普遍些我们可以使用-L来锁定，注意不可能将shell设置为nologin，但则gitlab就无法使用了，因为其中有部分关联到gitlab-shell操作。

nginx 403 Link to heading

这个问题主要是完成安装后，对目录访问各种403，也就是权限错误。在这里有一点很重要，因为gitlab会对你安装的目录进行读取，也就是gitlab所在的目录，在debine系的操作系统中，用户目录默认为755，而fedora中为700，这也是导致从源码安装引起这个问题的主要原因。在文档中，只针对子目录进行的权限修改，并没有对这个目录进行修改，我们需要跑一下chmod 755 /home/git才好。

重启服务 Link to heading

所有设置修改改要重新启动。除此之外更重要的一点，就是对assets的重新编译，安装过程中有针对node与yarn的步骤，如果gitlab更新了，这个文件也需要重新跑一下，否则gitlab网页会出现js错误。

Mon, 01 Jan 0001 00:00:00 +0000

论极语易 Link to heading

论山谈水寓坤乾，

极目云深锁九天。

语默闻声有万籁，

易安忘却世间缘。

本博客 Link to heading

主要用于记录开发中的小问题和一些理解。

不会记录非常复杂的东西（那种东西在脑子里，也懒得写成博客）。

简述 Link to heading

程序开发、周易、常式太极拳。

想读博……准备发展形式语言、数理逻辑证明等相关方向。

主要使用 Haskell 语言，其次使用 Lisp (Emacs & Common) 为脚本语言。正在接触 ~~CoQ~~ Agda。根据需求可能选用各种语言（rust，CC， ~~Ruby~~ 等）进行开发。

平日使用 ~~Vim 与~~ Emacs 为主力工具。同时使用 nix、home-manager 作为配置管理工具。开发环境集中于 NixOS。

关于开发，更多请见 dotfiles 和 awesome。

Contact / 联系 Link to heading

_@vonfry.name, or you can replace mail with any validated local-part.
matrix: @vonfry:vonfry.name.
misskey: @_@social.vonfry.name.

PGP Keys Link to heading

Current Link to heading

_@vonfry.name 2026-01-26~2027-01-26 _@vonfry.name

乐水榭 | 论极语易-Vonfry 博客

shell、eshell与工具

前言 Link to heading

什么是 Shell？ Link to heading

为什么在 shell 中完成日常工作？ Link to heading

C++ 异常与 stack unwind

Stack unwinding Link to heading

其它的一些补充 Link to heading

Haskell 里 Generics, Template 与 Typeable 的一些杂思

前言 Link to heading

思考 Link to heading

dioxus中的hooks与runtime的scope

版本信息 Link to heading

前言 Link to heading

Scope Link to heading

什么是 hook Link to heading

C++ 中结构体成员名的反射

起因 Link to heading

编译器的魔法宏与特殊处理 Link to heading

阅读参考 Link to heading

未来 Link to heading

2024 始记

杂谈 Link to heading

Link to heading

交友 Link to heading

数据备份 Link to heading

C++ 模板参数逐个处理

起因 Link to heading

问题 Link to heading

解决方法 Link to heading

一种出现内存崩溃错误的现象

现象 Link to heading

遇到的场景 Link to heading

原因 Link to heading

物理场仿真相关算法记录

几何相关 Link to heading

算法相关 Link to heading

一些开发库 Link to heading

建模 Link to heading

几何 Link to heading

矩阵计算 Link to heading

数据结构 Link to heading

为什么 haskell 的 monad 定义使用 a -> m b 作为输入

问题说明 Link to heading

什么是单子 Link to heading

Haskell 现有的定义 Link to heading

其它定义 Link to heading

为什么对象是 a -> m b Link to heading

CPS and monad and function

更新 Link to heading

起因 Link to heading

说明 Link to heading

临时文件目录空间导致的编译失败

起因 Link to heading

原因 Link to heading

解决 Link to heading

NixOS 特例 Link to heading

haskell: fix point

问题说明 Link to heading

推测 Link to heading

sha256 等 hash 算法结果长度

计算结果及字符 Link to heading

转换规则 Link to heading

中文排版标准

REF Link to heading

简述 Link to heading

使用 Link to heading

富文本 Link to heading

纯文本 Link to heading

编程语言语法的思考

前言 Link to heading

表达/语法 Link to heading

冗余 Link to heading

符号表达 Link to heading

强制缩进 Link to heading

efi、systemd-boot与grub及双系统问题

原因 Link to heading

问题注意点（针对NixOS） Link to heading

grub查找系统 Link to heading

引导修复（针对nixos） Link to heading

为什么对象是 `a -> m b` Link to heading

动态类型静态类型 Link to heading