このアカウントは、notestockで公開設定になっていません。

森永のラムネに圧倒的感謝してるよ

・IP
・USB
・ギガ
・アスペクト
・ファーム 🆕

#デファクト

このアカウントは、notestockで公開設定になっていません。

DirectX の DLL がぶっ壊れたのに DirectX の再インストールもシステム修復もできなかったあのクソ OS ！！！！

今でも思い出すたび腹が立ってくる

おたくなので、たった1曲のために CD に数千円出したりしてしまうんだよなぁ
生活費で多少割引をしたところでそのくらいの節約は簡単に吹っ飛んでしまう

わかる人にはわかる字幕シリーズ、 [Music] や [Applause] がある

https://gist.github.com/kb10uy/ba47b6f4872f8f7b6665835e1c9aea55

「♪〜」の字幕を使ってたことがあったようなので、 [Applause] もやってみてほしさがある (適当)

テレビよりネットの世代としてもな (???)

最小構成カーネルコンフィグバトル (最小とは言ってない) ですが、現状とりあえずひととおり所有する機器が動き問題なく使えるレベルになっており、 kernel が 5.0 MiB 、 initramfs が 6.8 MiB となっております (initramfs については 3 MiB 未満にできるはずなので、ｺﾞﾘｺﾞﾘ削っていく)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

https://twitter.com/tsubasu_izumi/status/1292115002296422400 #tw

うおおおおおお！！！！

論理明日から本気出す (適当)

sys-kernel/gentoo-kernel 、何も考えず emerge するだけでマトモに使える kernel と initramfs が生えてくるの最高じゃんと思ってたんだけど、どうも genkernel でやっているような LVM や LUKS への対応を initramfs に突っ込んでくれないらしく、 full disk encryption 環境で使えなかった (悲しい) #gentoo

KVM switch を「CPU切替器」と命名した香具師、詐欺師の才能あると思う

物理日の2/3が終わっていた顔をしている

なーにが ♪生活リズム♪ を整えるじゃ
ヌルいこと言ってねえで 🔥生命の脈動《ビート》🔥 を刻んでいけ👊

CoinHive ならぬ ScanHive

＞ CMakeLists.txt ＜

……の話してます？ (?)

vim ってクソ長い行があると syntax highlight が重くなることで有名なんですよ。
で、日本語で小説なんか書くと段落が1行になる (何故なら分かち書きでない言語なので hard wrap がない) ため、普通に重くなって困るわけですね。

そこで vim の設定で *.txt について syntax off するようにしようとしたんですが、これ素朴にやると CMakeLists.txt とかまでシンタックス消えるんですよ。もうブチギレ。

CMakeHoge.cmake もなんか頭悪いのでアレ
{{hogename}}@{{hogename}}.{{tld}}
みたいなのに近い悩みがある

しゃーないので一度ファイル種別判定かけたあとに条件付きで無効化してる

このアカウントは、notestockで公開設定になっていません。

私も loliconductor@loliconduct.org 作るかなぁ (?)

loliconduct.org は取得済みで admin 等のメールも実はもう設定済みなので、任意のメールアドレスを一瞬で錬成できる

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

Rust の cargo とかは (言語として) 後発だけあって、システムのパッケージマネージャや外部のメタビルドシステムとの相性が結構良さそうなのよね。
Gentoo Linux の portage でも、 portage 側で依存管理できてる

そもそもバージョンの固定や制約の解決まで含めて担当するのがパッケージマネージャの仕事なので、言語固有 PM で記述された制約を distro の PM 側に正しく反映 (書き換え) する必要があるのは当然

たとえば Gentoo の場合だと cargo-ebuild というツールで ebuild ファイルがｼｭｯと生成される
他の言語は知らん

https://github.com/cardoe/cargo-ebuild

このアカウントは、notestockで公開設定になっていません。

これは本当にこれで、つまり「いかにシステムの PM にパッケージを簡単に追加できるか」というのは結構重要な要素だと思うんですよ。
Gentoo とかはその辺り大変優れていて (ソースコードのﾀﾞｳﾝﾖｯﾖもﾋﾞﾙﾄﾞも自動化できるので) 、たぶん guix とか nix も似たような感じなのでは

これは視点の違いかなぁ。
私は「ちょっと使いたい小さなツール」がいろいろなユーティリティや言語でバラバラに管理されるのが嫌なので、さっさと自分用リポジトリに突っ込んでしまう

このアカウントは、notestockで公開設定になっていません。

lo48576/lo48576-portage-overlay: My personal portage overlay
https://github.com/lo48576/lo48576-portage-overlay

たとえばこんな感じですね。
しかもこうやって管理しておけば、アップストリーム (distro 公式だったり半公式のリポジトリ) に貢献するのも簡単になる

結局、最終的にはそこなのよね。
Rust だと cargo-ebuild でｼｭｯしてライセンスを cargo-license で確認して、あとはちょっと README / CHANGELOG の有無を見てやればあっというまにパッケージファイル作れるんだけど。
Rust に救われている

例: upstream に投げたやつのひとつ https://github.com/gentoo/guru/commit/7cd795cbddcdc4dee8ad342497565849fa8f20f7

Cargo.toml の C が大文字なの、「Makefile とか Gemfile も先頭が大文字だし、その方がビルド用ファイル感がある」みたいな話らしい (詳しいことは忘れた)

いやべつに雰囲気重視系とかそういう話ではなく、ちゃんと「ソースコード等とは別のメタなファイルであることに気付きやすい」的なアレがあるのだろうと思うけど

皆さんはちゃんと BSD Make で利用できない拡張付きの Makefile に GNUmakefile と命名していますか？

@kb10uy 基本的に Rust は静的リンクでライブラリも feature 設定ごとにビルドする必要がある (たぶんマクロあたりの関係とか) というのと、 ABI が不安定とかの理由もあり、プロジェクトごとに必要な crate を各自で用意する方式ですね。
一応 *.crate ファイルは PM が管理してくれるので、全く同一バージョンの crate への依存があったらキャッシュを使ってはくれる

あ、 *.crate というのは crates.io 等のリポジトリから落とされてくる、ソースコードやリソースを固めたアーカイブ

つまり *.crate 自体はビルド時の feature とは無関係に使い回せる

https://gnosia.info/@ncrt035/104659069936740295

自分を二次元美少女に擬人化して絵日記を描くのは異常独身中年男性の専売特許ではない #宣言的知識

このアカウントは、notestockで公開設定になっていません。

脱 shell script といえば、古き良き sysVinit の "bashism" は印象に残ってるな。
sysVinit は基本的にシェルスクリプトでデーモン等の起動や終了の管理をするわけだけど、これが bash 依存のものが多かったりでシステムから bash 依存を実質的に排除できないという話があって……

それが今や systemd のユニットとして一貫した記法で書かれるようになって、シェルスクリプトは排されつつある

このアカウントは、notestockで公開設定になっていません。

設定ファイルが特定のプログラミング言語に依存するの、一生をその言語と共に過ごす覚悟がないと厳しいんだよな……

たとえば meson とかは「シンタックスはちゃんと既定してあるから、公式実装以外の処理系を作ることもできるよ」みたいなことが明確に言われていたりするんだけど。
特定のプログラミング言語や言語処理系に依存してしまうと、二度とそこから脱却できないとか、互換な処理系の開発や置き換えが難しくなるというハードルがある

その観点では Rust と cargo はかなりバランスがとれていて、静的な設定は Cargo.toml なので言語を問わず読み書きできる。
特殊なビルドスクリプトが必要なら、 build.rs に記述することになっているので、当然今使っている Rust 処理系で処理できるし、コンパイラへのデータ受け渡しも標準出力経由で行われる (つまり公式の rustc への依存がない)。

まあ Rust に限らず Python でも Ruby でも「プロジェクトが使っている言語でビルドスクリプト書けば処理系固定の問題は起きないよね」というのは綺麗な解決だと思うけど、それをコンパイル型言語でやってのけたのは素晴らしいと思う

まあ Rust のコンパイラなんて2種類しか知らないけど……
まだまだ言語自体が開発途上だからそこは仕方ないね

このアカウントは、notestockで公開設定になっていません。

Scheme は標準ライブラリあたりのゴタゴタがよくわからんという印象を持っているのでよくわからん (R5RS 並感)

処理系独自拡張を使わずどこまでやれるかということね

R6RS だか R7RS だかで small と large に分かれるだの何だのの話をちょっと聞いた記憶があるけど、結局 Scheme 本格的に使ってないのでその辺り追い掛けてなくて、最新の規格がどうなってるかは全くわかってない

https://mastodon.cardina1.red/@lo48576/104659131191702808

いやちょっとまて、こんなこと書いたけど CPython と PyPy の互換性とか Ruby と JRuby で require か何かの挙動が違うとか、結局処理系互換性の罠あるやんけ……

？？？「意味論の定義されてない言語なんて妄想でっしゃろ」

このアカウントは、notestockで公開設定になっていません。

R5RS は SRFI の有無がどうのあたりで、なんだかまとまりがないなぁという印象を持っています

@kb10uy thepowersgang/mrustc: Alternative rust compiler (re-implementation)
https://github.com/thepowersgang/mrustc

icedtea の話はやめれ！
gcc-5 の gcj で icedtea-7 をビルドしてそこから icedtea-8 をビルドしないといけない話はやめれ！！

このアカウントは、notestockで公開設定になっていません。

あー、ライブラリが導入されたの R6RS からだったっけ、そういえば

このアカウントは、notestockで公開設定になっていません。

ｴｯそうなのwww

すごいことになってるんだなぁ……

まあ Scheme は動的言語だし R6RS のライブラリの構文木をﾇｯと変換して R7RS 用にするみたいな荒技使えそうだけど (いや知らんけど)

このアカウントは、notestockで公開設定になっていません。

本の虫: ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
https://cpplover.blogspot.com/2015/04/hadoop.html

reproducible build 関係についてはこんな話もあったわね

Meta-circular evaluator - Wikipedia
https://en.wikipedia.org/wiki/Meta-circular_evaluator

こんな概念を思い出していた

ある言語のインタプリタ A 上で、ホスト言語のインタプリタ B を実装する。
すると、言語拡張などを B に組込むことができる。
さらに同じように B 上で動くホスト言語のインタプリタ C を実装し……とやっていくと、一番新しい拡張や変更付きの言語であっても、一番ベースの古いインタプリタ A で動くようにできるみたいな話

このアカウントは、notestockで公開設定になっていません。

地獄そう……

このアカウントは、notestockで公開設定になっていません。

たしかに

ﾊﾟﾖﾖﾝの勉強をアナログ電子回路から始めた勢なので、動的型付き言語のコンパイルという概念に今でも違和感を持っている (老人)

や、アナログ電子回路→論理回路→FPGA→アセンブリ→C言語 の順で勉強したら誰でもこうなると思う (知らんけど)

べつに C++ や Rust で実行時型情報を使わないわけでもないし、理屈ではわかってはいるんだけどね……

そういえば SECD マシンとかいう概念を100世紀ぶりに思い出した

これは formal definition ではなく完全にお気持ちなんですが、「静的解析が (比較的) しやすい言語が静的で、静的解析が困難な言語が動的である」という雑な判断基準がある

静的解析が需要に間に合ってない C++ ですら、全体的には静的解析しやすい方といえる

CSS や DOM を彷彿させるなぁ (適当)

このアカウントは、notestockで公開設定になっていません。

ｽﾗｲﾄﾞを「だれ」「なに」で始めるやつはやる

https://speakerdeck.com/lo48576/lambda-calculus-implementation-by-xslt-1-dot-0

metropolis テーマ、シンプルでありながら十分にヘッダと本文が区別できるのでかなり好み

https://speakerdeck.com/lo48576/lambda-calculus-implementation-by-xslt-1-dot-0?slide=24

「で？」じゃねえんだよな (?)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

『東京タワー』の建設フロー、PM視点でみてヤバすぎたので解説｜Shoko Suzuki｜note
https://note.com/shokosuzuki/n/n5a9a44d6f067

やばすぎて白目剥くわこんなん

このアカウントは、notestockで公開設定になっていません。

Lisp 系のシェル、括弧の扱いをどうするかがひとつの関門になりそう (ffmpeg や find みたいな複雑なオプションでは有用だろうけど、フラットな場合は '(key val) よりも key=val のような中置記法の方が便利なので)

シェルでポ記法とか逆ポ記法とか使ったらもうちょっと表現力が高くなりそうみたいな気持ちは確かにあるので、S式もアリといえばアリなんだけど

このアカウントは、notestockで公開設定になっていません。

これは完全に好みの問題なんですが、連想配列を [key1, value1, key2, value2, ...] のようなヘテロな配列で書くの嫌いなんですよね (好み)

key-value であるという情報が構文に表れていないのが implicit すぎて気持ち悪いので……

まあ人間は初めて見た構文を親だと思って育つので…… (???)

プロパティリスト - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%83%91%E3%83%86%E3%82%A3%E3%83%AA%E3%82%B9%E3%83%88

あー、これｵﾗｲﾘｰの XML の本で読んで「うわこれ嫌い！」と思ったやつです >dict要素

このアカウントは、notestockで公開設定になっていません。

HTML の <dl><dt></dt><dd></dd>...</dl> とかも嫌いなんですが、あれは HTML5 だと div を使えることになっているので、
<dl>
<div><dt></dt><dd></dd></div>
<div>...</div>
...
</dl>
のように書ける (そしてそう書く)

たぶん根底にあるメンタルモデルとして、「可変長な list において順番は壊れやすい (別の言い方をすると、要素同士は対等である)」という認識があるんでしょうね。
長さや上限が固定であれば tuple として認識するので、まあヘテロでええやんとなる

dracut の設定をどう弄っても LVM on LUKS なシステムで起動できなくて泣いてる (なんで……)

ワロスプレスは笑う (ワードプロレスだと思ってた派 (?))

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

＞ メッセージパッシング ＜

？

相撲ﾄｰｸの話か？