OCaml Weekly News

affect では例えば、非同期関数の結果の待機、別の関数のキャンセル、タイムアウト、シグナル配送、一度だけセットされるセルがセットされること、ファイルディスクリプタが読み取り可能になること、そして独自のファニーなプリミティブアクションを select で待ち合わせることができます。

アクションのロックフリー実装は2009年の論文に従っており、一部のアイデアは CML の Guile 実装から採用しています。後者と同様に、affect では CML の用語を変更しています。イベントベースの用語はこれらのメカニズムを考える上で非常に混乱を招くと感じています。OCaml を完全に Milner 化するために CCS からインスピレーションを得て、event を action、channel を port に置き換えました。これらの命名変更の詳細については設計ノートをご覧ください。

明確でアクセスしやすい並行モデルを提供しようとする点に加え、affect が第一世代の OCaml 5 並行ライブラリと異なる点は：

1. OCaml ランタイムシステムの新しい並列的性質を完全に受け入れ、並行性と並列性を区別しません。
2. 第一級の同期アクションや非同期関数という高レベルの抽象を、他から処理できるよう公開しています。これらのメカニズムは並列安全でロックフリーであるため、統合に多くの作業は不要で、使用するコンテキストへの制約も少なくなっています。

これは特に以下を意味します：

• プログラムの main で組み込みスケジューラを呼び出すことに不満があったり、そもそも使いたくない場合でも、これらの抽象を使用するエコシステムライブラリを引き続き使いながら、アプリケーションの並行・並列アーキテクチャを合理的に制御できます。

  例えばこのテストには、アクションを処理したり、ルートとなる非同期関数をスレッドで自前で実行する方法を示すコードとサンプルが含まれています。それらは組み込みスケジューラの並列起動とも連携できます。別のテストでは、2つのスケジューラインスタンスが並列に実行できること（独立した領域でも、ポートを介した通信でも）が示されています。

• バイト列以上のものに合意できるとよいことを考えると、既存のスケジューラが affect の高レベル抽象（またはそのサブセット）を処理できることが必要です。例えばアクションを処理するには、アクション呼び出し処理時にスケジューラでブロック解除の作業をスケジュールするための並列安全なクロージャを提供するだけで済みます。

TL;DR：素敵でエルゴノミックな並行モデル および 柔軟性が得られます。

リリースについては、affect は今ついに概念的にしっかりと根付いたと思っていますが、まだ初期段階であり、あまり使われていません。この最初のリリースの目的は、2年間リポジトリと思考の中で熟成してきた設計の、完全に動作し使用可能な実装を公開することでした。現状では：

• おそらく本番環境での使用はお勧めしません[^1]。
• 変更は引き続き想定されます。特にプライベート API をいじっている場合は。早期採用者やこのフォーラムでの質問は歓迎します。試していて問題が発生した場合は issue tracker でご連絡ください。
• このライブラリはしばらくの間、最新バージョンの OCaml を必要とします。
• リリースに間に合わなかった点として、協調的な [~Unix~ 互換モジュール]での select(2) の使用を置き換えることがあります。当初の計画では epoll/kqueue を使用する予定で、その計画は変わっていません。

• 現在の実装は明確さと正確さを優先しており、ある意味では素朴です。パフォーマンスが光り輝いていなくても、改善できる次元はいくつかあります。構造の特殊化、より命令的なデータ構造の使用（ただし必ずしも有利とは限りません）、一部の atomic の削除、単純なスケジューリング戦略の高度化などです。もちろん BYOS（前述のモデル全体のモノスレッド実装は約100行）も可能です。

  コードベースはほどよく読みやすいはずです。アクションと非同期関数のコアモジュールだけなら690行、並列ワークスティーリングスケジューラが380行加わります。しかし、悪魔は実行の割り込みタイミングに潜んでいます :–)

Happarapyllecomputling!

この最初のリリースは OCaml Software Foundation からの助成によって実現しました。また、ドナーの皆さんのご支援にも感謝します。これらの成果物が作業・配布されるためには、皆さんのサポートが不可欠です。

• ホームページ: https://erratique.ch/software/affect
• ドキュメント: https://erratique.ch/software/affect/doc または odig doc affect
• インストール: opam install affect ([opam PR])

よろしくお願いします。

Daniel

[^1]: 自分の IO 非依存の [HTTP ライブラリ]用の affect ベースのコネクタを本番システムにデプロイしたときに、安心してそうお伝えできるようになります :-)

髭を蓄えた Emacs ユーザーと尖った耳の VS Code ユーザーの間の争いは、長年にわたって無益に燃え続けてきました。両陣営は Slipshow エディタとしての優位性を証明し、最高のタイポキルカウントを主張しようとしていました。

尖った耳の VS Code ユーザーには公式の Slipshow 拡張機能があり、Slipshow バイナリを必要としないライブプレビューを持っていました。しかし、その組み込みライブプレビューにはマルチファイルプレゼンテーションなどの制限があり、さらに重要なことに LSP サポートがありませんでした。

髭の Emacs ユーザーは組み込みの LSP クライアントである eglot を使用できましたが、公式モードがなければ、厳密な LSP を超えた機能セットの拡張は不可能でした。

そこで、今回の Slipshow リリースには2つのコンパニオンが付属します：

• Slipshow の VS Code 拡張機能（VS Code のマーケットプレイスで入手可能、現在は Slipshow バイナリが必要）
• Slipshow の Emacs メジャーモード（(use-package slipshow-mode :vc (:url "https://github.com/panglesd/slipshow-emacs-mode" :rev :newest)) でインストール可能）

これらにより、エディタとプレビューサーバー間のより多くの連携が可能になります。例えば、各キーストロークで更新するか保存時に更新するかを選択するシンプルな設定が追加されました。プレゼンテーションをエディタから直接制御する2つの新コマンドも利用できるようになりました。

One LSP to rule them all, one server to sync them,

One keystroke to step through slips, and in the editor bind them.

もう一つ言及に値する改善点は、描画の保存ワークフローが大幅に改善されたことです：Save ボタンをクリックするだけで描画を保存できるようになり、描画は挿入された場所に固定されます（テキストコンテンツが変更されても、描画は適切に移動します）。

You shall not desynchronize text and drawing content!

両エディタが優れていることを示す証拠として、描画が記録・保存され、その前にコンテンツが追加される様子をご覧ください：

https://github.com/user-attachments/assets/c4f0131d-7eda-4bdd-874e-50c1872580eb

https://github.com/user-attachments/assets/d4164c3f-f63a-40fb-b03b-add4f0f32435

いつもながら、NLNet のサポートに心より感謝します。Emacs Lisp を習得するのにかかった膨大な時間は、彼らの寛大なサポートなしには割に合わなかったでしょう！

（もし毛深い足を持つ第三の、同じく素晴らしいエディタのユーザーで、Fellowslip に加わりたい方がいれば、ぜひご連絡ください。喜んでお手伝いします！）

完全な変更履歴はこちら：

• auto-continue 属性：次のアクションへ自動的に進む機能 (#240)
• step アクションへの ~duration:FLOAT 引数 (#241)
• LSP:
  • エディタからプレゼンテーションプレビューを前後に進める2つのコマンド (#242)
  • .slp を入力ファイルとして認識 (#244)
  • 各キーストロークまたは保存時にプレビューを更新する設定 (#248)
  • 依存関係の変更を監視してプレビューを更新 (#252)

• 描画をプレビューサーバー経由で保存するように (#249, #254)
• 描画が追加されたポイントに固定されるように (#262)
• Slipshow サーバーの URL を知らせる通知のスパムをなくした (#265)

• マルチファイル設定での LSP アクション検出の修正 (#243)
• serve モードでの外部テーマの修正 (#245)
• 一部のファイルが開かれていない場合のマルチファイル LSP プレビューの修正 (#250)

• ドキュメントの英語品質を大幅に改善 (#255, @Synchro)

テストデータを含む Intel HEX ファイルを作成して出力する例：

Intel_hex.Record.
[
  Extended_linear_address 0x0F;
  Data (0x0000, "Hello ");
  Data (0x0007, "World!");
  End_of_file;
]
|> Intel_hex.Encode.into_string 
|> print_endline

:02000004000FEB
:0600000048656C6C6F20E6
:06000700576F726C6421CA
:00000001FF

もちろん、任意のソースから Intel HEX オブジェクトを読み込むこともできます。

In_channel.with_open_text "data.hex" Intel_hex.Decode.from_channel

- : Intel_hex.Object.t =
[Intel_hex.Record.Extended_linear_address(0x000F);
 Intel_hex.Record.Data(0x0000, "Hello ");
 Intel_hex.Record.Data(0x0007, "World!");
 Intel_hex.Record.End_of_file]

Into/from blobs

Intel_hex.Object.from_string ~block_size:6 "Hello World! I love it!"

- : Intel_hex.Object.t =
[Intel_hex.Record.Data(0x0000, "Hello ");
 Intel_hex.Record.Data(0x0006, "World!");
 Intel_hex.Record.Data(0x000C, " I lov");
 Intel_hex.Record.Data(0x0012, "e it!");
 Intel_hex.Record.End_of_file]

OPAM パッケージマネージャやその他の方法で intel_hex ライブラリをインストールできます。

$ opam install intel_hex.0.4

スカラー乗算には高速化のための事前計算テーブルが含まれています（mirage-crypto-ec 0.11.3 で導入）。これらのテーブルのルックアップアルゴリズムは、テーブル全体をスキャンする代わりに、秘密情報に依存した読み取りを行います。