This account is not set to public on notestock.
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)님의 게시물
This account is not set to public on notestock.
NandGame - Build a computer from scratch.
https://nandgame.com/#
知ってる内容だけどおもしろかった
https://mastodon.cardina1.red/@lo48576/104549978722226341
人生でNAND使うかわからないけど稀に使うことができる知識です
普通の人は人生において最小個数の NAND で XOR を作ろうとすることがない、それはそう
シンクライアント、そもそも最近のエディタ（というか統合開発環境）はそれなりのマシンスペックを要求するという問題がある
それなりのスペックがある、まさに新クライアント端末が必要と (は？)
そも thin client が thin でないなら一体ソレは何なのか、みたいなお気持ちに
本当にthinなマシンで開発したいならijaasを入れてvimでコードを書くみたいなハードコアモードを選ぶ必要がある
cympfh/cumin: Mini-Programmable Configuration Language
https://github.com/cympfh/cumin
いいじゃん
This account is not set to public on notestock.
XML Schema とかその系列の型の仕組み、さすがに使いづらい (表現力はそれなりにあるんだけど、むしろそのせいで)
普通のプログラムでは型はロジックと紐付いていて、データはロジックへ進入する際にロジック側の手動で検証を受けるのよね。
なんだけど、 XML Schema とかそっち系の技術はデータ側にデータとして validation ロジックが入っていて、処理系がそのロジックをネイティブの validation ロジックに翻訳して使うという手間が発生する
しかも Schema 系はその用途的に「必要に応じて型を次々と定義していく」という戦略をとっているけど、これは静的にコンパイルされるプログラムととにかく相性が悪い。プログラム側としては事前に全ての型が判明していてほしいので。
で、結局スキーマからコード生成を経てネイティブの型を事前に用意するということになるわけだけど、それデータとして型を用意した意味の半分くらい死んでない？ という (しかももちろん追加のスキーマをネイティブに扱うことはできない)
動的にスキーマを扱うと、「型検査相当のことを型以外のシステムで行う」みたいなことになって、結局ネイティブの型レベルでの恩恵は受けられないわけよね。そりゃありがたくないわな
静的な型検査を考えない LL とかだと相性は良いかもしれないけど……
それも結局型アノテーションとか付けようとしたら同じように苦労することになるので
やってることがオブジェクト階層ごとの null/型チェックの強化版みたいになっちゃってつらいんだよな
まあ結局データとしてのスキーマ記述は「多言語対応のための制約記述」くらいの立ち位置で落ち着くのが一番得るものが多いと思っていて、それ以上を目指されても「すべての処理系は、言語に統合できないオレオレ型検査器を搭載してください」という話になるだけで幸福度はほとんど増さないと思う
とても美しい一連の型を出力するような Schema to Native な翻訳機が XML Schema に存在したならば、 XML 貴族の言うことに賛同しても良かったかもしれないね
もちろん「実用されている様々な言語向けに」という前提での話だけど。 Java だけ継承マシマシで対応されてもしゃーないので
あーそうそう、継承とかいう概念もそもそも特定パラダイムにがっちり紐付いたアレなのでスキーマで使われると険しい表情になってしまうし、そこは現代においても未解決問題な気もする
まあ Java とか C++ も、あっちはあっちで sum type というか代数的データ型がネイティブに扱えないみたいな弱点があって、いずれにせよ険しい
そんな感じ。
あるいは ActivityStreams 2.0 の Collection みたいな。
Activity Streams 2.0
https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#collections
ActivityStreams も結構アレだよな……
Activity Vocabulary
https://www.w3.org/TR/activitystreams-vocabulary/#extendedtypes
Vocabulary だと、これらも †継承† で表現することが想定されているっぽい
gtk::prelude::IsA - Rust
https://docs.rs/gtk/0.7.0/gtk/prelude/trait.IsA.html#foreign-impls
Rust で継承前提のものをどうにか表現しようとすると、こんな感じになる
This account is not set to public on notestock.
私の志向はボヘミアン寄りなので、単に混合ドキュメントを素朴に書けて名前空間が使えるデータ形式として存在してくれていればよかったんだけど……
PSVI とか言われると、そんなん超ヘビーなライブラリかコード生成がないと実用言語で使い物にならんやんけ……と思ってしまう
This account is not set to public on notestock.
https://hostux.social/@fsf/105487596088209535
これ GNU が「ニュー」と読むだけでなく gnu (ヌー) がウシ目ウシ科であることを十二支とかけているのかと思ったけど、そもそも英語圏は十二支の文化ではないか……
impl TryStream を返す関数で ? を使ったら「Result でも Option でもないやんけ、ダメです」と言われた、かなしい (それはそう)
しかたないので関数内で || async { ... } してる
This account is not set to public on notestock.
ソケット類はプロセス寿命とほぼ一致することが多いので /run でわかるんだけど、 fifo は必ずしもそうでもどうなんだろう
/var/run は /run への symlink だったり非推奨だったりいろいろあるので、その辺りも distro 都合という感じでア
スマホ契約者が標的に！ NHK受信料は「値下げ」ではなく「払わない」という選択肢を検討せよ（NEWSポストセブン） - Yahoo!ニュース
https://news.yahoo.co.jp/articles/d021251f90dbcd64556281105bdd42ae6457a5c9
> しかし、通信のインフラ整備にNHKは寄与していない。通信インフラを作った通信業者に乗っかって、『ネットでもNHKが見られるから受信料を払え』というのは放送法の建て付けから考えると完全におかしい。
なるほどね
This account is not set to public on notestock.
単なる可逆圧縮でよければ FFV1 が 標準化されていたはず
FFV1 - Wikipedia
https://en.wikipedia.org/wiki/FFV1
FFmpeg/FFV1: The FFV1 lossless video codec specification.
https://github.com/FFmpeg/FFV1
FFV1 Video Coding Format Version 4
https://tools.ietf.org/id/draft-ietf-cellar-ffv1-v4-03.html
まだドラフトっぽい？
動画コーデック、先に圧縮があって欠落させないという形で無劣化としていることが多そうなので内部形式として RGB や RGBG などを所望の場合はちょっと探すのつらそう
メタデータ、下手に動画コーデックやコンテナに紐付けるよりも別ファイルで持つ方が現実的で持続する気がする
なんなら XMP のメタデータを別の XML ファイルに書いとくみたいな手もあるし
え、それは情報量的には動画にしても大差ないのでは……(高々コンテナのメタデータ分ぐらいしか減らない気がする)
や、動画だと時間方向の予測とかによる圧縮がそれなりに効くことが期待できるので連番静止画よりは小さくなる気がする (もちろん動画の内容次第だけど)
基本的にコーデックが対象情報の特性を知っていれば知っているほど圧縮がよく効くので
フレーム毎圧縮、言ってみれば zip のようなもので、 .tar.gz には及ばないのはそれはそう
コーデックが知っている特性を活用できないと意味がないわけで、時間方向の差分とか予測とかを活用できないアルゴリズムで実験してもあまり有意義な結論は得られないと思う
天文関連用にであれば、天文関連用に新たなフォーマット作る方が良さそうだけど、それでもノイズまで保存するんだから結局あんまり縮まない気がする＞＜
フレーム1枚では縮まないだろうけど、たとえば天文写真であれば背景色は多くのフレームでかなり近いことが想定できるし、であればノイズがのっていても差分で色を持ってやれば情報量は劇的に小さくなりそうだけど
フレーム内でも結構効きそうだと思うけどねぇ (たとえば画像をブロックで分割したときほとんど同じ色のほぼプレーンなブロックが相当出てくるだろうし)
まあ実際の問題はこれでしょうね、コーデックの色空間対応ってたぶん軽率に増やせないやつなので……
This account is not set to public on notestock.
This account is not set to public on notestock.
あとコーデック周辺はクソデカ企業の特許だのパテントトロールだのがうじゃうじゃしてそうというのもある
鳴り物入りで登場したコーデックが金になりそうであれば確実に特許で突かれるからな
自分のところで特許ガチガチに固められるとかであれば、また話は違うかもしれないけど……
This account is not set to public on notestock.
