Cirru 后续更新维护: 2016~2019

延续以前的一篇文章
Cirru Project in 2015
Cirru 演进历程: 2012 ~ 2016

大体从 2017 年之后, Cirru 在图形探索上面就比较少了, 仍是基于原来的方案.
主要在 Stack Editor 基础上设计了新的 Calcit Editor.
另外围绕 Calcit Editor 作了一些辅助工具.
大多想法仍是用 Calcit Editor 维护之前整理出来的这些小的应用.git

尝试 Nim 是最近的想法了, 想用静态类型语言再尝试一下之前作的.github

Calcit Editor

项目地址 https://github.com/Cirru/calc...算法

大体上就是之前的 Stack Editor 的功能改进. 总体界面功能类似.编程

项目最开始的时候用的 cumulo-editor 这个名字, 因此记录有写分开的,segmentfault

Calcit Editor 当中最核心的算法是 bisection-key 的算法, 用来计算插入节点的位置.
好比这样一段 Clojure 代码, 包含简单的嵌套的数据:数组

(if (coord-contains? focus child-coord) focus nil)

用 Cirru 的数据形态表示出来, 就是数组的嵌套:编程语言

["if" ["coord-contains?" "focus" "child-coord"] "focus" "nil"]

当有两个客户端在同时编辑中间嵌套的表达式的时候, 数组的位置是 1,
那么, 好比客户端 A 的 1 的前面插入了新的节点, 而且修改, 那么也是 1,
而后 A 修改 1 的时候, 对应的 B 当中的数据就已通过时了.
整体上就是很难控制中间的逻辑不会发生明显的冲突.编辑器

bisection-key 模块的方案是给每个节点增长 id, 而且 id 用的字符顺序,
再细节就不说了, 至少大幅缩小了发生冲突的可能性, 最终的到这样的一个结构:模块化

{
 :type :expr, :data {
  "T" {:type :leaf, :text "if"}
  "j" {
   :type :expr, :data {
    "T" {:type :leaf, :text "coord-contains?"}
    "j" {:type :leaf, :text "focus"}
    "r" {:type :leaf, :text "child-coord"}
   }
  }
  "r" {:type :leaf, :text "focus"}
  "v" {:type :leaf, :text "nil"}
 }
}

做为 Calcit Editor 的存储格式(实际使用当中包含更多的节点信息).函数

基于 Calcit Editor 就能够实现多个客户端实时协做的功能了.
不过实际上来讲这方面作的探索仍是不够, 绝大部分时候仍是单机使用的.
另外加入的功能有好比实时显示光标位置, 全局通知, 链接 nrepl 之类的功能.
以及专门优化了在 Git 切换分支的时候文件重载的问题.
为了方便使用, 增长快捷键, 处理复制剪切粘贴, 原始存储格式修改等等功能.

对于 Clojure 开发来讲, 在文本的基础上, Calcit Editor 有必定的结构化方案,
但相对来讲, 因为不是 IDE 那样集成的环境, 不少功能仍是缺失的.
对于推广来讲不是好的事情. 只能说对于 Cirru 自己的探索作了延伸.

另外生成 Clojure 代码的模块也逐渐有调整: sepal.clj.

编辑器相关组件

除了主体的编辑器, 还衍生一些相关的工具:

因为 Cirru 的文本格式比较特殊, Snippets 须要单独处理.
因此作了一个简单的服务, 将用到的几个 Snippets 存放在专门的页面上.

这是一个快速查看 calcit.edn 存储文件的小工具,
功能比较简单, 就是讲代码渲染出来, 一次性所有展开, 方便直接查看.
实际使用来讲应该再加入更多功能的..

一个单独高亮显示代码的模块, 提供相似 calcit-editor 的局部.
能够用在 Snippets 预览的场景当中, 以及处理相似的需求.

这个基于以前 Stack Editor 的编辑器组件制做的, 用于网页上直接编辑.
存储格式比较简单, 直接就是数组的形式, 操做习惯大致上跟 Calcit Editor 类似.
如今 Cirru.org 页面当中编辑预览就是用的这个工具.

Clojure EDN 美化的函数运行有一些性能开销, Calcit Editor 存储信息又可能比较大.
慢的主要缘由应该是布局的问题, 各类对齐要求比较特殊.
个人场景当中需求有限, 因此写了一个简单的生成数据文件的工具.
同时我须要代码换行并且大体可读, 能被 Git 自动 merge, 甚至极端时手动调整.

Parser in Nim

parser.niminterpreter.nim 是近期想到因此开始作的尝试.
之前版本的 Parser 都比较慢, 主要仍是由于是动态语言.
当时最快的版本应该是 Go 的, 可是 Go 的问题, 包管理, 动态特性, 都有影响.
因此我考虑试一下 Nim, 一来是简单, 二来性能方面能尝试些不同的方案.

Nim 版本的 Parser 作了 Lexing, 以前的版本都比较粗暴直接逐字解析的.
而后也处理了一下行号和报错方面的问题, 方便在具体的场景当中用.
虽然目前解析的代码体积都比较小, 可是明显能感觉到跟 JavaScript 版本的提高.

至于 interpreter 也是基于此前 Go 版本的写法作尝试.
目前没有想好, 可是但愿能作出来一些能用在平常工做中的工具.

其余

毕竟要工做, 纯粹的 Cirru 的探索已经不多了, 也过了那样的年纪.
对我来讲图形布局已经超出当初想要的效果了, 至少在便利性上面.
因此我没有多少欲望说要去再作破坏式的改进的, 基本上都是微调.

短时间看来, interpreter 部分作一下定制可以派上点用场.
平常开发当中仍是须要一些脚本的, 用来执行短平快的一些任务.
用 Bash 写长了很差处理, 用通用编程语言, 又有一些模块化和 API 的限制.
Cirru 最初就是为了方便设计的书写, 很是灵活, 也适合继续定制.
我以为这方面会再尝试一下, 但愿能帮到平常开发.

远的先不会去想了, 精力不够的.

相关文章
相关标签/搜索