[落書きコーナー](Tumblr)この広告は、90日以上更新していないブログに表示しています。2018-07-16hashtablesとserializeライブラリnmosh久々にyuniに新しいライブラリを足すことにした。どちらも他所でライブラリにしていたけどyuni本体に有った方が何かと便利なんじゃないかということで移動。smallにあるものはR7RS、そうでなくてR6RSにあるものはR6RS"という方針で選択している。いうわけでhashtablesはR6RSベース。R6RSのものを更にサブセットしている:ハッシュ関数は無し。インスペクションは無し。ハッシュ関数やequality手続きを既存のハッシュテーブルから取り出すことはできない。キーの型限定hashtablesを提供する。この限定はScheme処理系を既存のインタプリタ言語で実装するケースを想定していて、integerやstringに関しては、それぞれのホスト言語ネイティブのハッシュテーブルを活用できる可能性があることから。)、yuniではプリミティブオブジェクトは1単語原則でhashtableにした。byte-vectorでなくbytevector)実はオブジェクトのハッシュは言語上に言語を載せる場合には良く実装できない可能性があり、可能な限り型付きのハッシュテーブルを想定した方が移植性は高くなる。成立するオブジェクトに異なるハッシュ値を振る可能性がある)ため実はあんまり役に立たない。addresses.serializehttps://github.com/okuoku/yuni/commit/f91a0f67cc17646d5c6d501517c749e1758c2ef2#diff-5e9cb588006ffc28b212e667f6b0c242serializeライブラリは要するにFASLだが、"バイナリ形式のwrite/read"という位置付けとなる。API名は良いものが全く浮ばない。してしまった方が良いかもしれない。オブジェクトのシリアライズ機能は処理系によってマチマチで、GambitやChezScheme等のようにちゃんとFASLとして使用できるものもあれば、そもそもシリアライズ機能自体を提供していない処理系もある。invariantなオブジェクトは正常にシリアライズできるという要求で良いと考えているが、問題は"writeできないがシリアライズはできた方が良いもの"をどうするかという問題だろう。シリアライズの直接的なサポートはない。これらでは自前のWriter/Readerで対応することになる。今見てみるとyuniのターゲット処理系でネイティブのFASLを持つ処理系って3つしか無いのか。invariantであるものの他に、ハッシュテーブルやrecordの入出力も可能となっている。yuniではハッシュテーブルの入出力は上記のinteger/symbol/stringの3種に限定しようとしている。固有のハッシュ関数やequality手続きを持ったハッシュテーブルを入出力するためには、これらの手続きもシリアライズする必要があるが、クロージャのシリアライズは処理系のサポートが無いと困難なため。ネィティブサポートの無い処理系の扱いは悩みどころだが、とりあえずScheme側の実装でどの程度のパフォーマンスになるかを見たいところ。殆どのケースで、テキスト形式のread/writeには勝てないのではないだろうか。500MiB程度のデータを処理しているのでテキスト形式に落してしまうとI/Oオーバヘッドが大きくなってしまう。)スレッド非サポートの処理系では、並列処理時に結果を受け取る際に使用する。いうあたりで、個人的にはyuniのような位置付けのライブラリにはどうしても必要なんじゃないかと考えている。A3341itemオブジェクトベースオーディオのためのE-AC-3拡張の規格書を読むaudioはてなブログをはじめよう!mjtさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。