OCaml Weekly News

先週号 上へ 次週号

こんにちは

2026年8月4日から11日までの週の OCaml Weekly News をお届けします。

Table of Contents

Dune 3.24

このスレッドを引き継いで、Ali Caglayan が発表しました

Dune チームは dune 3.24.2 のリリースを発表できることを嬉しく思います。

新しい修正内容や、それを実現してくれたコントリビューターへのクレジットについては、完全な変更履歴をご覧ください。コントリビューターの皆さん、ありがとうございます!

このリリースで問題が発生した場合は、issue tracker にご報告ください。

OCaml 5.5 および trunk 向け Merlin と OCaml-LSP の新リリース

vds が発表しました

Merlin 5.8.1-505 のリリースを発表できることを嬉しく思います。このリリースでは特に、Dune のウォッチモードで OCaml-LSP を使用する際に頻繁に発生していたキャッシュの問題が修正されています。

また、現在の OCaml コンパイラの trunk で動作する Merlin と OCaml-LSP のプレビューバージョンもリリースしました。コンパイラの開発に利用できますが、型 AST への将来の変更によって再び動作しなくなる可能性があります。

sdl3 バインディング

sanette が発表しました

こんにちは!

OCaml-sdl3(パッケージ名は単に sdl3)の(非常に)予備的なバージョンを発表できることを嬉しく思います。これは言うまでもなく、SDL3 ライブラリ向けのバインディングセットです。

https://github.com/sanette/ocaml-sdl3

なぜ予備的なバージョンを発表するのか?第一に、今後数ヶ月はあまり時間が取れないこと、そして第二に、すでに楽しく使えると思うからです!

このバインディングは clang を使って SDL のコードを解析するプログラムによって生成されています。これは第一フェーズであり、まだすべての関数が使えるわけではありません。いくつかの関数については手動ラッパーを書き始めました(サンプルを参照)。

AI に関する免責事項: clangctypes の使い方を理解するために chatGPT を活用したことは認めますが、バインディングジェネレーター全体(および手動で追加した部分)は完全に(私の)手で書かれたものであることをここで明言しておきます。

JFLA2027 : Premier appel à communications

Yannick Zakowski が発表しました

このメッセージは意図的にフランス語で書かれています。これは、2027年1月末にブルターニュで開催される「フランス語圏の関数型言語の日々」の論文募集です。論文は英語で書くことができますが、発表自体はフランス語で行うことが求められています。

Merci de faire circuler : premier appel à communications

JFLA 2027 : Journées Francophones des Langages Applicatifs

http://jfla.eu/jfla2027.html

26 janvier au 29 janvier 2027

Maison Saint-François

Les 38èmes Journées Francophones des Langages Applicatifs (JFLA) se tiendront en Bretagne, à Dinard (Ille-et-Vilaine), du mardi 26 janvier 2027 au vendredi 29 janvier 2027.

Les JFLA réunissent concepteur·rices, utilisateur·rices et théoricien·nes ; elles ont pour ambition de couvrir les domaines des langages applicatifs, de la preuve formelle, de la vérification de programmes, et des objets mathématiques qui sous-tendent ces outils. Ces domaines doivent être pris au sens large : nous souhaitons promouvoir les ponts entre les différentes thématiques.

  • Langages fonctionnels et applicatifs : sémantique, compilation, optimisation, typage, extensions à d'autres paradigmes.
  • Assistants de preuve : implémentation, nouvelles tactiques, développements présentant un intérêt théorique, technique ou méthodologique.
  • Logique, correspondance preuve-programme, réalisabilité, extraction de programmes, modèles.
  • Spécification, prototypage, développements formels d'algorithmes.
  • Vérification de programmes ou de modèles, vérification déductive, interprétation abstraite, raffinement.
  • Utilisation industrielle des langages fonctionnels et applicatifs, ou des méthodes issues de la communauté scientifique. Outils et plateformes pour le web.
  • Enseignement ou diffusion des langages fonctionnels et applicatifs. Environnements et méthodes de développement, retours d'expérience.

Les articles soumis aux JFLA sont relus par au moins deux personnes s'ils sont acceptés, et au moins trois personnes s'ils sont rejetés. Les critiques du comité de programme sont toujours bienveillantes et la plupart du temps encourageantes et constructives, même en cas de rejet.

Il n'y a donc pas de raison de ne pas soumettre aux JFLA !

DATES IMPORTANTES

/!\\ Attention : les dates limites sont fermes et définitives. Il n'y aura pas d'extension. /!

  • Soumission des résumés et articles : 16 octobre 2026, GMT+2
  • Notification aux auteurs et autrices : 2 décembre 2026, GMT+2
  • Version finale des articles : 16 décembre 2026, GMT+2

SOUMISSIONS

Nous acceptons deux types de soumissions :

  • Article de recherche (18 pages max.) portant sur des travaux originaux. Nous acceptons des travaux en cours, pour lesquels l'aspect recherche n'est pas entièrement finalisé. Nous encourageons aussi la soumission d'articles présentant avec élégance un résultat connu sous un angle nouveau.
  • Article court (9 pages max.) décrivant un problème particulier, les pistes en cours d'investigation, et visant à rechercher de l'aide de la part de la communauté. Les articles courts peuvent également présenter de manière synthétique et cohérente des résultats déjà publiés. Enfin, ils peuvent présenter un outil logiciel dont l'exposé constituera une démonstration.

CONSIGNES AUX AUTEURS ET AUTRICES

Les articles peuvent être rédigés en français ou en anglais.

La forme de l'article doit être soignée, et le contenu rédigé de manière structurée et claire.

Le style LaTeX jflart doit impérativement être utilisé sans modification de la mise en page. Le style LaTeX et sa documentation sont disponibles depuis le site web de la conférence.

Les limites de pages sont strictes. Les références bibliographiques ne sont pas comptabilisées dans la limite de pages. Les annexes aux articles ne sont pas autorisées.

Les auteurs et autrices peuvent soumettre du matériel supplémentaire, séparé de l'article soumis, sous forme de texte (version longue, sans limite de pages) et/ou de développement logiciel. L'évaluation de ce matériel supplémentaire est à la discrétion du comité de programme. Les articles soumis doivent donc être auto-contenus et évaluables sans ce matériel supplémentaire.

Les soumissions parallèles dans d'autres conférences, journaux ou workshops avec actes ne sont pas autorisées.

Les membres du comité de programme sont autorisés à soumettre un article. Les présidentes du comité ne le sont pas.

Les articles doivent être soumis via le site :

https://types-hotcrp.paris.inria.fr/jfla27

L'évaluation des articles suit un processus en simple-aveugle : les rapports des articles sont anonymes, mais pas les auteurs et autrices.

Les articles acceptés seront publiés dans les actes de la conférence, sur HAL, et les auteurs et autrices en donneront une présentation lors des journées. Les présentations seront, de préférence, données en français.

Yannick ZAKOWSKI et Stefania DUMBRAVA

JFLA 2027

hegel 0.14.0

Ethan Chou が発表しました

こんにちは、

Hegel に関していただいたフィードバックを受けて、v0.14.0 で Core への依存が除去されたことを発表できることを嬉しく思います。以前のバージョンにあった Core のジェネレーターは、Hegel_jane というオプションのサブライブラリに移動しました。このリリースに協力してくれた @c-cube に感謝します!

詳細については、リリースノートをご覧ください:

https://github.com/hegeldev/hegel-ocaml/releases#release-v0.14.0

ifs-fractals の新リリース 1.1.0

Cédric が発表しました

皆さん、こんにちは。

ifs-fractals — 反復関数系(バーンズリーのシダなど)のアトラクターをカオスゲームによって描画する小さなライブラリと CLI — が、今夏 opam に登場して以来、初めての機能リリースを迎えました。16年に及ぶ集中的な開発の末に ;-)

69533442f671ef2ba37fb0c5029780b8ec8b10c5.png

1.1.0 の新機能:

  • ヘッドレス PNG レンダリング。これまでフラクタルはグラフィックウィンドウにしか描画できませんでしたが、ディスプレイなしで直接ファイルにレンダリングできるようになりました:

    ifs-fractals -o fern.png -s 800x1280 barnsley
    
  • またはコードから、`save_png barnsley 200000 "fern.png"` のように呼び出せます。これにより、サーバーや CI でもパッケージが使えるようになり、テストも格段に楽になりました。自分に課した楽しい制約として、新しい依存関係を追加しないこと — PNG ライターは純粋な OCaml で書かれた自己完結型のもので、stored deflate ブロックを使った 8 ビット PNG を書き出します。
  • 密度カラーリング。カオスゲームはアトラクターを均一には訪れません — 一部の領域は他よりもはるかに多く訪れられ、その密度こそが視覚的な構造の多くを担っています。`-c`(または `save_png ~color:true`)を使うと、ピクセルがヒット数に基づいて対数スケールで色付けされます。上の画像がその結果です:シダが葉脈を取り戻しています。

    ifs-fractals -c -o fern.png -s 800x1280 barnsley
    

`opam install ifs-fractals` でインストールまたはアップグレードし、`ifs-fractals –list` で 16 種類のアトラクターをすべて確認してみてください。

新しいアトラクターがどのように設計されるか — カエデの葉やヒマワリを生み出すアフィン変換の 6 つの係数をどのように見つけるか — について、短い論文 Building New IFS Attractors: a Working Vocabulary of Affine Maps ( https://doi.org/10.5281/zenodo.21804778 ) にまとめました。より詳しい解説はブログ ( https://www.cedricbonhomme.org/2026/07/27/challenging-claude-with-ifs-fractals/ ) にあります。

一点開示しておきます。これが話の面白い部分でもあるのですが:新しいアトラクターは Claude(Anthropic の Fable 5 モデル)によって設計されました — ブログ記事でその実験について詳しく述べています。それ以外のすべて — ライブラリ、CLI、PNG ライター、論文そのもの — は私自身の作業であり、LLM の出力ではありません。

フィードバックや新しいフラクタル定義を大歓迎します。プルリクエストをどうぞ。

気に入ったアトラクターを設計したら、ぜひ見せてください!

OSEC-2026-14: mirage-crypto-pk: RSA 署名検証が未ドキュメントの例外を発生させる

Hannes Mehnert が発表しました

新しいセキュリティアドバイザリが公開されました。いつものように、以下で確認できます: https://github.com/ocaml/security-advisories および https://osv.dev/list?q=&ecosystem=opam

よろしくお願いします。

Hannes

id: OSEC-2026-14
modified: "2026-08-07T13:00:00Z"
published: "2026-08-07T13:00:00Z"
severity: "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L"
severity_score: "4.3 (Medium)"
affected: "mirage-crypto-pk" {< "2.3.0"}
events: [
   [
     git "https://github.com/mirage/mirage-crypto.git" [
       [fixed "a0f59a0c90eb067505b55a03d3bb104eacd6dd33"]
     ]
   ]
]
credits: [
   [reporter "Thomas Gazagnaire"]
   [remediation_developer "Hannes Mehnert"]
]
cwe: [ CWE-248 ]
affected_bindings: [
   "Mirage_crypto_pk.Rsa.encrypt"
   "Mirage_crypto_pk.Rsa.decrypt"
   "Mirage_crypto_pk.Rsa.PKCS1.encrypt"
   "Mirage_crypto_pk.Rsa.PKCS1.decrypt"
   "Mirage_crypto_pk.Rsa.PKCS1.sig_encode"
   "Mirage_crypto_pk.Rsa.PKCS1.sig_decode"
   "Mirage_crypto_pk.Rsa.PKCS1.sign"
   "Mirage_crypto_pk.Rsa.PKCS1.verify"
   "Mirage_crypto_pk.Rsa.OAEP.encrypt"
   "Mirage_crypto_pk.Rsa.OAEP.decrypt"
   "Mirage_crypto_pk.Rsa.PSS.sign"
   "Mirage_crypto_pk.Rsa.PSS.verify"
]

RSA 署名検証が未ドキュメントの例外を発生させる

RSA の decrypt および encrypt 関数は、メッセージが 2 より小さい場合に Invalid_argument 例外を発生させます。これにより、署名値が 0 または 1 の X509 証明書は、 適切なエラーの代わりにこの Invalid_argument 例外をスローすることになります。

  • 修正

    修正は、ドキュメント化されスタック上位で捕捉される Insufficient_key 例外を再利用することです。

  • タイムライン
    • 2026年7月28日:security@ocaml.org へ報告
    • 8月7日:mirage-crypto-pk 2.3.0 のリリースおよびセキュリティアドバイザリの公開

OSEC-2026-15: mirage-crypto-ec: EC 公開鍵の範囲外読み取り

Hannes Mehnert が発表しました

新しいセキュリティアドバイザリが公開されました。いつものように、以下で確認できます: https://github.com/ocaml/security-advisories および https://osv.dev/list?q=&ecosystem=opam

よろしくお願いします。

Hannes

id: OSEC-2026-15
modified: "2026-08-07T13:00:00Z"
published: "2026-08-07T13:00:00Z"
severity: "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L"
severity_score: "4.3 (Medium)"
affected: "mirage-crypto-ec" {< "2.3.0"}
events: [
   [
     git "https://github.com/mirage/mirage-crypto.git" [
       [fixed "1f0bf67044e67cf6e46911fcd77a0ff706b6c3e7"]
     ]
   ]
]
credits: [
   [reporter "Thomas Gazagnaire"]
   [remediation_developer "Hannes Mehnert"]
]
cwe: [ CWE-125 CWE-248 ]
affected_bindings: [
   "Mirage_crypto_ec.P256.Dsa.pub_of_octets"
   "Mirage_crypto_ec.P256.Dh.key_exchange"
   "Mirage_crypto_ec.P384.Dsa.pub_of_octets"
   "Mirage_crypto_ec.P384.Dh.key_exchange"
   "Mirage_crypto_ec.P521.Dsa.pub_of_octets"
   "Mirage_crypto_ec.P521.Dh.key_exchange"
]

EC 公開鍵の範囲外読み取り

内部の Point.of_octets 関数は圧縮ポイントに対する長さチェックが欠けており、 短いバッファが提供された場合に例外を発生させます。これはすべての NIST 曲線 (P-256、P-384、P-521)と Dsa.pub_of_octets および Dh.key_exchange 関数の 両方に影響します。

  • 修正

    修正は、提供されたバッファの長さを確認することです。

  • タイムライン
    • 2026年7月28日:security@ocaml.org へ報告
    • 8月7日:mirage-crypto-pk 2.3.0 のリリースおよびセキュリティアドバイザリの公開

新パッケージ: floatml

Opale が発表しました

こんにちは :​) 先週取り組んで先ほど公開した新しいパッケージ、floatml を紹介したいと思います!これは Rust のソフトフロートライブラリ(rustc_apfloat)の小さなラッパーで、OCaml で高速かつ効率的な IEEE-754 の float16float32float64float128 を利用可能にします。また、できる限りアロケーションを抑えるよう心がけたので、適度に効率的なはずです。

免責事項: コードのかなりの部分は LLM によって書かれています。インターフェースを決定して指示を出したのは私ですが、Rust とのグルーコードは LLM が生成したものです(そして徹底的にテストされています!)

Soteria のために作成しました。Z3 をなるべく使わないよう、具体的な浮動小数点演算のリダクションが必要だったのです。皆さんにも役立てていただければ幸いです!

ocaml-android リブート!

Romain Beauxis が発表しました

皆さん、こんにちは!

Android クロスコンパイラ opam リポジトリの完全なリブートをプッシュしました!

このリブートは、Windows 版の最新のプラクティスに倣い、最近のメイン OCaml コンパイラにおけるクロスコンパイルサポートの大幅な改善のおかげで、非常にすっきりとした内容になっています。

時間の都合上、すべてのパッケージが移行されているわけではありません。旧ブランチは old-main として引き続き利用可能です。

これはコミュニティリポジトリですので、OCaml コードのクロスコンパイルが得意な方は、ぜひパッチを送ってください!

Ravel 1.0.1 — interaction net にコンパイルする関数型言語

Kayo Tei が発表しました

皆さん、こんにちは!

Ravel 1.0.1 が opam で利用可能になったことを発表できることを嬉しく思います。

Ravel は interaction net — 強い合流性と暗黙的並列性を持つグラフ書き換えモデル — にコンパイルする小さな関数型言語です。ユーザー定義の代数的データ型、深いパターンマッチ、レキシカルクロージャを持つファーストクラス関数、そしてラベル付き複製・消去ノードによる自動リソース管理を特徴としています。

https://opam.ocaml.org/packages/ravel/

フィードバックや貢献を歓迎します!

新パッケージ: P4-SpecTec

Haechan Kwon が発表しました

こんにちは!

P4 言語仕様を機械化するためのフレームワーク p4spectec の初回公開リリースを発表できることを嬉しく思います。アルゴリズム的推論規則の形式で形式仕様を記述するためのドメイン固有言語を提供します (Lee et al., 2026)

P4-SpecTec で書かれた仕様は実行可能です。P4-SpecTec で型付け規則を書けば、リファレンス型チェッカーが得られます。動的意味論の規則を書けば、リファレンスインタープリターが得られます。prose バックエンドは機械化された仕様から人間が読めるドキュメントも生成します。

https://opam.ocaml.org/packages/p4spectec/

詳細な手順、ソースコード、機械化された P4 仕様については、パッケージにリンクされた GitHub リポジトリをご確認ください。

新パッケージ: NeoDriver 0.1.2 – Neo4j データベースドライバー

Tomasz Barański が発表しました

Neo4j ドライバーの初回公開リリースを発表できることを嬉しく思います。

これは Eio 向けに構築された Neo4j データベースの純粋な OCaml ドライバーです。公式ドライバーと完全な機能同等性を達成することを目指しています。まだそこには至っていませんが、現時点で以下の機能を備えた完全に使用可能な状態です:

  • Bolt プロトコル 3.0、4.2–4.4、5.0–5.8、6.0 のサポート。
  • プレーンな bolt:// と TLS bolt+s:// / bolt+ssc:// 接続。
  • 遅延ストリーミング結果を持つオートコミットクエリ。
  • 自動リトライ付きの明示的トランザクションおよびマネージドトランザクションの両方。
  • ブックマーク。
  • 名前付きタイムゾーン(組み込みの IANA データベースと 1970 年以前の LMT フォールバック)を持つ時間型。
  • 基本認証(Bolt >= 5.1 での HELLO 後の LOGON)。
  • TestKit 適合性:126 テスト中 114 が合格(12 がスキップ)。

https://opam.ocaml.org/packages/neodriver/

opam-audit

Hannes Mehnert が発表しました

皆さん、

opam-audit が初期バージョンとして opam にリリースされたことを発表できることを嬉しく思います。これは opam プラグインです(一つの switch にインストールするだけで、すべての switch で opam audit として利用できます)。

opam-audit は OCaml Security Team のセキュリティアドバイザリデータベースのローカルコピーを保持します。opam audit を実行すると、使用している switch にインストールされているすべてのパッケージを既知のアドバイザリと照合し、既知のセキュリティ脆弱性を持つインストール済みパッケージを報告します。

既知の脆弱なパッケージが見つからない場合は 0 を返し、そうでない場合はゼロ以外の値とインストール済みの脆弱なパッケージの一覧を返します。これにより、CI システムがアプリケーションを公開する前に opam audit を呼び出して、脆弱なパッケージがバイナリに紛れ込んでいないことを確認できます。

以前のこちらのスレッドでも言及されています:https://discuss.ocaml.org/t/request-for-comments-what-to-do-with-opam-packages-that-have-known-security-vulnerabilities/18087/2

ソースコードは https://github.com/hannesm/opam-audit にあります — バグ報告や機能リクエストを歓迎します。

shakuhachi v0.3.2 - 音楽コレクションマネージャー

EruEri が発表しました

皆さん、こんにちは。

shakuhachi v0.3.2 のリリースを発表できることを嬉しく思います。このリリースには、発表し忘れていた 0.3.0 と 0.3.1 の内容も含まれています。

Shakuhachi は引き続き音楽コレクションマネージャーです。

これらのリリースの要点:

  • 正規表現による置換は遅く、それを置き換えることでフォーマットの速度が大幅に向上します。
  • かなりの数の誤った動作と自分のミスを修正。
  • 多くの新しい関数が公開され、その上に何かを構築するための多少使える基盤となっています。
  • プラグイン(dynlink を使用)が必要な依存関係をすべて持てるよう、OCaml のリンク戦略との格闘。
  • いくつかの新しいオプション(_例アイテムのソート、重複した曲の挿入を避ける、など_)。

すべての変更点を確認するには、変更履歴をお読みください。

https://codeberg.org/EruEri/shakuhachi

お時間をいただきありがとうございます。

敬具。

Bytream 0.1 – 初回リリース

Mikhail が発表しました

どうも!

Bytream の初回公開リリースを発表できることを嬉しく思います。これはバイトのストリーミングと処理のためのライブラリです。

このライブラリは、効率的な方法で書き込みと読み取りのバイトストリーム処理を組織化するための、I/O ランタイムに依存しないメカニズムを含んでいます。たとえば、コーデックやプロトコル実装の構築などに使えます。

このプロジェクトを作成するアイデアと動機は、あらゆる種類のバイナリフォーマットやプロトコルを効率的に解析する必要性から生まれました。既存の AngstromFaraday の組み合わせは素晴らしいのですが、私が必要とする以上に表現力が豊かです。そして BytesrwIostream はデータの受信と送信の方法を扱っており、処理や記録の方法を扱っているわけではありません。

そこで Bytream がこの問題を解決します。Bytesrw からスライスとライフタイムのアイデアを、Angstrom からアンバッファリングのアイデアを借用し、どんな I/O ランタイムでもストリーミングモードで動作する、Stdlib のチャンネルのような通常の OCaml コードを書けるようにします。

初回リリースの詳細

初回バージョンから、入力用(Bytream.In.t)と出力用(Bytream.Out.t)の2つの抽象化が利用可能です。どちらもバイト配列の表現に内部で Bigarray を使用しています。この選択の動機は、このデータを外部関数に転送する際の複製を避け、ランタイムを固定するためです。

既に述べたように、Bytesrw のアイデアを引き継ぎ、Bytream はストリームを供給するためのチャンク機構を使用します。以下の例はチャンクの基本概念を示しています:

(* Queue as a byte chunk source. *)
let queue =
  let queue = Queue.create () in
  Queue.add "he" queue;
  (* ... *)
  Queue.add "d!" queue;
  queue
in

(* Reader function that returns chunks of text from the source. *)
let reader () =
  match Queue.take_opt queue with
  | None ->
    (** For close incoming byte stream, the reader 
        should raise an End_of_file exception.  *)
    raise End_of_file
  | Some chunk -> Bstr.of_string chunk
in

let in_stream = Bytream.In.make reader in 
Bytream.In.input_string in_stream 7
(* - : string = "hello w" *)

そして、発信バイトストリームの代替例:

(* Queue as a byte chunk sink. *)
let queue = Queue.create () in

(* Writer function that outputs chunks of text to the sink. *)
let writer (~buffer, ~length:len, ..) =
  Queue.add Bstr.(sub_string ~off:0 ~len buffer) queue
in

let out_stream = Bytream.Out.make writer in 
(* ... *)

実際のケースでは、もちろんチャンネル、ファイル、ソケット、その他のものを使って外界と通信します。そしてそれをストリーミングで行います。

module Bson = struct
  (* ... *)

  let from_channel ic = 
    let in_stream = Bytream.In.of_channel ic in
    Codec.input_document in_stream

  let into_channel oc doc = 
    let out_stream = Bytream.Out.of_channel oc in 
    Codec.output_document out_stream doc

  let to_string doc = 
    Bytream.Out.with_into_string @@ fun out_stream -> 
    Codec.output_document out_stream

Lwt との連携は Lwt_direct 経由で現在実験的に利用可能です。

#require "bytream.lwt";;

let something_into_channel oc = 
  let%lwt out_stream = Bytream_lwt.Out.of_channel oc in 
  (* The usual Bytream code. *)

他のダイレクトスタイルの I/O ランタイム(EioMiou など)ではより良く動作するでしょう。

または別の例:

match request with
| `Post "/archives/", body_stream ->
  (* The reader has its own internal buffer mechanism that allows it to bufferize 
     the contents of the body stream and decode them without copying chunks. *)
  let reader = Archive_reader.in_stream_of body_stream in
  let archive_meta =
    Bytream.In.make Archive_reader.(to_handler reader)
    |> Archive_reader.input_archive_without_contents 
  in

  let blob = Archive_reader.blob reader in 
  process_archive ~meta:archive_meta ~blob ()
  (* ... *)

次のリリースに向けた計画

  • ドキュメントの改善
  • ユニットテストの追加
  • コンビネーターの追加?
  • 皆さんのご提案….

インストールと試用

すでに OPAM で利用可能です!

OPAM パッケージマネージャーまたはお好みの方法で bytream ライブラリをインストールできます。

$ opam install bytream

アップストリーム(開発者)ブランチの最新バージョンも取得できます。

$ opam pin bytream.dev https://github.com/dx3mod/bytream.git

Dune を使用している場合は、依存関係に bytream ライブラリを追加してください。

ショーケース

Bytream を使用しているエコシステムライブラリを探索することで、その適用可能性をより深く理解できます。

  • Rpmfile は RPM パッケージの読み書きを行うライブラリで、バージョン 1.0.0 以降 Angstrom から移植されています(現在開発中);
  • Intel_hex 予定
  • そして他にも多数…

あとがき

このライブラリについてのご意見を聞けることを大変嬉しく思います。フィードバックをいただけると幸いです。また、実装の詳細と API についての先輩方からのコメントも歓迎します。ソースコードは MIT ライセンスのもとで公開されており、いつでも変更を受け付けています。

お楽しみください! :camel: :hot_beverage:

Smaji Glyph Path

ZAN DoYe が発表しました

Smaji Glyph Path

フォントグリフのアウトラインを操作するための OCaml ライブラリです。グリフパスの解析、変換、合成、異なるフォーマット間の変換のためのツール群を提供します。

このライブラリは2つの主要なパス記述標準をサポートしています:

  1. SVG Path:<path> 要素(その d 属性を含む)とコンテナとしてのオプションの <g> 要素をサポート。
  2. Glif フォーマット:Unified Font Object(UFO)フォーマットでグリフのアウトラインを記述するために使用されるデータをサポート。

opam で公開されているため、opam install smaji_glyph_path で簡単にインストールできます。

2つのユースケースのサンプルもご覧ください。

Smaji Glyph Path の2つの使用例、Smaji Outline Description と Smaji Stroke Description

ZAN DoYe が発表しました

Smaji Glyph Path

Smaji Glyph Outline Description

Smaji Glyph Stroke Description

Smaji Glyph Path ライブラリの2つの実用的なアプリケーションをご紹介したいと思います:Smaji Glyph Outline Description(god)Smaji Glyph Stroke Description(gsd)です。現在これらはまだ opam に公開されていません。Smaji Glyph Path ライブラリの使い方の例としてリンクを掲載しています。これらの例が役に立つと感じた方は、返信や「いいね」でお知らせください — 関心があることがわかれば、opam に登録してより良くメンテナンスできるようにします。

異なるストロークを組み合わせてグリフを簡単に構築できるマークアップ言語を設計しました。Smaji Glyph Path のおかげで、グリフの作成は積み木遊びのようなもので、筆記プロセス全体のアニメーションも生成できます!

以下の例をご覧ください:

例1: 2つのストロークを組み合わせて「八」という文字を構築。

<god version="1.0">
  <glyph unicode="516b,0">
    <stroke type="t" x="0" y="0" width="56" height="112"/>
    <stroke type="p" x="76" y="0" width="56" height="112"/>
  </glyph>
</god>

516b,0.outline.svg

例2: 既存の「god」(不)と横画(一)を組み合わせて「丕」を作成(アニメーション付き)。

<god version="1.0">
  <glyph unicode="4e15,0">
    <character utf8= "不" x="0" y="0" width="128" height="120"/>
    <stroke type="h" x="0" y="114" width="128" height="14"/>
  </glyph>
</god>

4e15,0.animation.svg

この画像が静止している場合は、画像を再読み込みするか、新しいタブまたはウィンドウで開いてアニメーションを再起動してみてください。

しばらく GOD を使用してみて、表意文字よりも表音文字に向いていることに気づきました。そのため、表意文字(特に漢字)に特化した新しいライブラリ Smaji Glyph Stroke Description(GSD) を設計しました。

GOD の詳細、GOD と GSD の違い、それぞれのユースケースの長所・短所については、冒頭のリンクをご確認ください。ここでは簡単に紹介するにとどめます — 興味があればぜひご覧ください!

過去の CWN

CWN を見逃した場合は、メッセージを送っていただければメールでお送りします。また、アーカイブRSS フィードもご覧いただけます。

毎週メールで受け取りたい場合は、caml-list を購読してください。