近況 2023-02-28

 2023年3月1日 投稿 日記

今月の活動 (ミローネ言語、ほか)

ミローネ言語

  • 前回のリリースから時間が経ち、変更が増えてきたのでリリースした (→ v0.6.0)
  • レコードに関する入力補完を実装した
    • レコード式の中でフィールド名を入力補完に出す: feat: Attempt of record fields completion
    • ドットの直後で左辺にフィールド名を入力補完に出す: feat: Support more field completion
    • 他のシンボルの入力補完とは違ってフィールドは型に依存する
      • 型情報を参照する必要がある
    • 型検査が出力したIRからレコード式やナビゲーション式の位置、ドット左辺の型を取り出しておく
    • 構文木を辿って入力補完の候補となるノードを探し、ノードの範囲で型情報を絞り込んで取り出す、ということをすればいい

コンパイラのテスト

  • セルフコンパイルが速くなってきた
    • 識別子の名前の付けかたを改善して、Cの再コンパイル対象のファイル数がかなり減ったおかげ
  • テストスクリプトもセルフコンパイル版のコンパイラを使って動かすようにスクリプトを書き直した
  • セルフホスティング感が出てきた

イテレーションの長さ

  • コンパイルしてテストしてというイテレーションが長くなってきてしんどい
  • 特に F# のLSPサーバーがますます安定しなくなってきている (前はもうちょっとましだった気がする)
    • 入力補完が出ない、エラーが表示されないとか
  • コンパイラはセルフコンパイル版でおおよそチェックできるからよい
    • LSPサーバーはミローネ言語の範囲では書けないのでめんどくさい
  • いったんLSPサーバーはNode.js (+ TypeScript) で書くのもいいかもしれない
    • コンパイラを別プロセスで起動して中間表現を出力させる
  • イテレーションの短さに関心がよってきた
    • LSPサーバーへのインクリメンタル計算の適用とか (rust-analyzerがやっているような)
    • ファイル変更時のキャッシュ無効化が少なくなるような言語設計とか

knowbug

進捗があるわけではなく、相変わらず「どうにかしないと……」と思っているという話

  • サーバー側で文字列化やツリー構築などの処理をして結果をクライアントに流すのではなく、クライアントからサーバーに個別のデータを問い合わせさせたほうがよいかもしれない
    • 性能が気になる。データをシリアライズしてパイプに流すより、チャネル的なインターフェイスで共有メモリを介してデータを送るほうが効率がよいはず (そういうライブラリないかな)
  • タイマーによるポーリングは非効率なので、標準入力の非同期の読み取り (ReadFile) も調査したほうがいい気がする
    • マルチスレッドは危ないのであまりやりたくなかった
    • とはいえReadFileを非同期に待ってPostMessageするだけで十分なので、いける気がしてきた
  • オブジェクトパスのライフタイムをみたところ、おそらく長命なパスはオブジェクトリストに含まれる項目にIDを振る部分しかない
    • 長命なパスというのは実行の再開後にも存命するようなパス
    • 毎回、パスを作り直しながらツリーの根から辿るというような実装でもよかったかもしれない
      • 参照カウンタを使わなくてよくなって分かりやすいかもしれない
  • 以前にも書いたように、デバッガ作成のチュートリアルについて構想中
    • いまからC++を学ぶのは大変だと思うが、Cや他の言語がknowbugに適しているわけでもない
    • UIを表示するのがめんどくさい (C++ならDear ImGUIは候補かもしれない)
    • WrapCallの仕組みがdirtyすぎてなんともいえない

RDB上のマップをまとめるかどうか

  • こういうテーブルの設計をどうするか悩んだ:
    • 自然キーがあって、それをキーに使ってよいとする
      • しかも複合キー。例えばユーザーIDと日付のペア
    • キーごとに登録できるデータが2種類ある
      • それぞれ登録されるデータの種類は異なる
      • 個数も多い (1カラムならnullでもよかった)
    • どちらかのデータが登録されているキーのリストと、それらのデータをまとめてリスト化したい
  • キーごとのレコードを入れるテーブル(親)と、データ登録用のテーブル(子)2つを持つという方法にした
    • RDB的には自然な気がする
  • データ登録用のテーブルだけ持ってFULL OUTER JOINやUNIONを使う方法もあった
    • これが悩みどころ
  • データ登録用のテーブルを1つにまとめる方法もあった (NULLABLEだらけになる)

書いた記事

  • CombineLatestのリアクティブグリッチ
    • 前述のとおりインクリメンタル計算の一種としてリアクティブプログラミングを改めてみていた
    • pushベースだとglitchの発生が気になる
    • pullベースというかadaptonがLSPサーバーには適していそう

気になった記事

関連記事