Cirru 後續更新維護: 2016~2019

延續以前的一篇文章
Cirru Project in 2015
Cirru 演進歷程: 2012 ~ 2016

大體從 2017 年之後, Cirru 在圖形探索上面就比較少了, 仍是基於原來的方案.
主要在 Stack Editor 基礎上設計了新的 Calcit Editor.
另外圍繞 Calcit Editor 作了一些輔助工具.
大多想法仍是用 Calcit Editor 維護之前整理出來的這些小的應用.

嘗試 Nim 是最近的想法了, 想用靜態類型語言再嘗試一下之前作的.

Calcit Editor

項目地址 https://github.com/Cirru/calc...

大體上就是之前的 Stack Editor 的功能改進. 總體界面功能類似.

項目最開始的時候用的 cumulo-editor 這個名字, 因此記錄有寫分開的,

• Cumulo Editor 時間線上一些記錄
• Calcit Editor 時間線上一些記錄

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.

編輯器相關組件

除了主體的編輯器, 還衍生一些相關的工具:

• calcit-snippets

因爲 Cirru 的文本格式比較特殊, Snippets 須要單獨處理.
因此作了一個簡單的服務, 將用到的幾個 Snippets 存放在專門的頁面上.

• calcit-viewer

這是一個快速查看 calcit.edn 存儲文件的小工具,
功能比較簡單, 就是講代碼渲染出來, 一次性所有展開, 方便直接查看.
實際使用來講應該再加入更多功能的..

• calcit-editor

一個單獨高亮顯示代碼的模塊, 提供相似 calcit-editor 的局部.
能夠用在 Snippets 預覽的場景當中, 以及處理相似的需求.

• respo-cirru-editor

這個基於以前 Stack Editor 的編輯器組件製做的, 用於網頁上直接編輯.
存儲格式比較簡單, 直接就是數組的形式, 操做習慣大致上跟 Calcit Editor 類似.
如今 Cirru.org 頁面當中編輯預覽就是用的這個工具.

• favored-edn

Clojure EDN 美化的函數運行有一些性能開銷, Calcit Editor 存儲信息又可能比較大.
慢的主要緣由應該是佈局的問題, 各類對齊要求比較特殊.
個人場景當中需求有限, 因此寫了一個簡單的生成數據文件的工具.
同時我須要代碼換行並且大體可讀, 能被 Git 自動 merge, 甚至極端時手動調整.

Parser in Nim

parser.nim 和 interpreter.nim 是近期想到因此開始作的嘗試.
之前版本的 Parser 都比較慢, 主要仍是由於是動態語言.
當時最快的版本應該是 Go 的, 可是 Go 的問題, 包管理, 動態特性, 都有影響.
因此我考慮試一下 Nim, 一來是簡單, 二來性能方面能嘗試些不同的方案.

Nim 版本的 Parser 作了 Lexing, 以前的版本都比較粗暴直接逐字解析的.
而後也處理了一下行號和報錯方面的問題, 方便在具體的場景當中用.
雖然目前解析的代碼體積都比較小, 可是明顯能感覺到跟 JavaScript 版本的提高.

至於 interpreter 也是基於此前 Go 版本的寫法作嘗試.
目前沒有想好, 可是但願能作出來一些能用在平常工做中的工具.

其餘

畢竟要工做, 純粹的 Cirru 的探索已經不多了, 也過了那樣的年紀.
對我來講圖形佈局已經超出當初想要的效果了, 至少在便利性上面.
因此我沒有多少慾望說要去再作破壞式的改進的, 基本上都是微調.

短時間看來, interpreter 部分作一下定製可以派上點用場.
平常開發當中仍是須要一些腳本的, 用來執行短平快的一些任務.
用 Bash 寫長了很差處理, 用通用編程語言, 又有一些模塊化和 API 的限制.
Cirru 最初就是爲了方便設計的書寫, 很是靈活, 也適合繼續定製.
我以爲這方面會再嘗試一下, 但願能幫到平常開發.

遠的先不會去想了, 精力不夠的.