polkit は依存を spidermonkey 68 (ESR) に更新してくれ〜
polkit は依存を spidermonkey 68 (ESR) に更新してくれ〜
postgres=# CREATE UNIQUE INDEX index_conversations_on_uri ON conversations (uri);
ERROR: could not create unique index "index_conversations_on_uri"
DETAIL: Key (uri)=(tag:sukebeneko.com,2020-05-04:objectId=15173825:objectType=Conversation) is duplicated.
postgres=#
というわけで、 index_conversations_on_uri インデックスが存在していないことが判明したので uri の重複したレコードを dedep してから作り直します
頭が悪いので、バックアップとってないサーバでサービス稼働状態のまま直接 SQL 叩いてる
生きてる本番サーバで叩く DELETE は最高に楽しい、今この瞬間を生きているという強烈な実感を持てるよ (適当)
Firefox 77 Nightly Adds Initial AV1 Image File Support (AVIF) - Phoronix
https://www.phoronix.com/scan.php?page=news_item&px=Firefox-77-AVIF-Experimental
🎉
弊鯖の Mastodon の DB が腐っていたのを、手動でいくつも DELETE とか CREATE UNIQUE INDEX を叩くことで復活させました 🎉
マトモに設計したら DB が不整合状態になるとかありえないと思うんだけど、一体何があったんだろう……
Mastodon 腐った DB 矯正メモ (2020-05-05) by らりお
https://gist.github.com/lo48576/3fc718124de4e22b97d22568031f12dc
Mastodon の DB が腐っていたのを修正したメンテナンスのメモです。 #mastodon
cf.
https://mastodon.cardina1.red/@lo48576/104113951825779459
https://mastodon.cardina1.red/@lo48576/103974978595397759
https://mastodon.cardina1.red/@lo48576/103974987462202016
このアカウントは、notestockで公開設定になっていません。
@yumetodo configure は configure.ac から生成されているので、そっちを見るべきです
configure.ac (昔は configure.in) から ./configure とかを生成するのが autoconf で、 Makefile.am から Makefile とかを生成してくれるのが automake (超雑な理解)
Autoconf, Automake, and Libtool: 5.2 Generated Output Files
https://www.sourceware.org/autobook/autobook/autobook_25.html
しかし autotools 周辺 (具体的には automake, autoconf, libtool あたり) はかなり混沌としていて厄介……
昔は私も書いてたけど、さすがにクロスプラットフォームとかは経験ないし今はもう Rust に魂を吸われてしまったので autotools 触りたくない
@yumetodo 「標準的なプロジェクト構成で存在しているべきファイル」みたいなのの集合があって、それらを勝手に追加してくれるみたいです。 COPYING とか。
そも autotools は m4 macro によって一連のファイルを生成するものであって、本質的にはテンプレート適用によって出力されたデータになるので、生成物が難読であることは致し方ないといえる
CMake はシンタックスがめちゃくちゃ嫌いなので autotools 以上に触りたくない
たとえば関数 (というのか?) に渡しているトークンが名前付き引数の名前なのか値なのかそうでない何かなのかとか、ぱっと見て一貫性が感じられないところが凄く嫌い。
ぱっと見で文法が理解できないくらいならありがちなスクリプト言語でも書いた方がまだわかりやすくない???
このアカウントは、notestockで公開設定になっていません。
meson とかはその辺り少しはマシなんですかね。
meson のファイルは読み書きしたことほとんどないので何もわかってないけど
このアカウントは、notestockで公開設定になっていません。
こう、「DSL であればシンタックスからセマンティクスが想像できなくても許される」みたいな甘えが感じられる言語全般が嫌いなんだけど、 CMake はドンピシャという感じです……
このアカウントは、notestockで公開設定になっていません。
Ruby 文化圏の DSL とかはその辺り結構絶妙よね、相当な独自文法だったり宣言的なあれこれだったりに見えるけど、頑張って読むとやっぱり Ruby の標準文法内で解釈できるプログラムになっていて、実際 expression が想定されている部分に Ruby の式を突っ込めるという
メタビルドシステムの設定ファイルが汎用プログラミング言語だと人々が凝ったことをやりだしてよくないというのがCargoやMesonに活かされた教訓だと思っています
ちなみにCMakeやGNUmakefileは汎用プログラミング言語ではない上に凝ったことができます
根本的に「最終的にチューリング完全な記述力が必要になるという現実から目を逸らして表現力の弱い DSL を作る」というところから間違っている
このアカウントは、notestockで公開設定になっていません。
まあ cargo は基本的に対象言語が Rust か C という前提があるからこそだろうけど、「基本的な部分は toml で宣言的に書かせるが、どうしても手続的にやる必要があれば Rust で (build.rs を) 書かせる」というのは結構いいやり方だと思う
GitHub とかで面白そうなプロジェクト見付けても *.sln があると即座にタブ閉じるよね…… (Linux ユーザ並感)
私は逆に「ビルドパイプラインを記述する言語はパイプライン記述言語として設計して、プログラムが必要になったら別途プログラムを書いてパイプラインに組み込む方が良い」と考えています
https://mastodon.cardina1.red/@lo48576/104115564322462965
https://git.sr.ht/%7Eadmicos/sksg
sksg という面白い静的サイトジェネレータのプロジェクトがあって、「処理系は宣言的に記述されたパイプラインの適用に徹して、フィルタは全て外部コマンドにより提供される」という割り切った設計なんだけど、これ結構イケてるなぁと思った
ちなみに公式サイトが死んでる
XML な時点でお察しな上に、依存関係の概念がありながら既存のものが並列に処理されることを想定されていないせいで並列化ができないすばらしいビルドシステムなんですけれども、しかしやめられなかったんですね~ https://ufcpp.net/blog/2017/5/newcsproj/
このアカウントは、notestockで公開設定になっていません。
なんかこう、bin/hoge とか yarn run hoge とか、開発時にプロジェクト内で実行させたいタスク類を書いて呼び出すのに良い方法はありますか?
現状はmakefile使って、make 〜 ってやることが多いです。
sagiegurari/cargo-make: Rust task runner and build tool.
https://github.com/sagiegurari/cargo-make
こういうタスクランナーがあります (Rust 製だけど用途は汎用) > https://fedibird.com/@noellabo/104115602538101815
このアカウントは、notestockで公開設定になっていません。
雑にシェルスクリプトを書く。
書けないようなややこしいやつは、どこにでもありそうな適当なスクリプト言語に頼る。うちは昔っからの人なのでperl。
https://fedibird.com/@noellabo/104115602538101815
cargo-make (makers) 、シェルスクリプトとか Rust とかの小さなコードをインラインで書けるのがすごくいい発想だと思う
従来こういうことをしたかったら、たとえば bin/ とか script/ とか util/ みたいなディレクトリを作ってそこに細々としたスクリプト類を突っ込んでるところだけど、そういうことすると誰が使っているスクリプトなのか追跡しづらくなるからね
むしろ IDE は嫌だなぁ……特定のプロジェクトを弄るとき本来それを使う必要のない場所でまで特定ツールを強要されたりするので
授業でアンヨヨイヨのプロジェクトやってたときは、 Vim で Java 書いて ./gradlew みたいなのを別ターミナルから叩いてコンパイルみたいなことしてた (筋金入り)
りりくる - LIly LYric cyCLE - Vol.2『bitter honey』 - OTOTOY
https://ototoy.jp/_/default/p/543533
りりくる - LIly LYric cyCLE - Vol.3『もっと、ずっと、ぎゅっと、』 - OTOTOY
https://ototoy.jp/_/default/p/543542
これずっと気になってたけど壁紙落としたりマグカップ買っただけで本編聞いたことないやつだ!!! (?)
本編持ってないゲッムのサントラを買い漁ったりしてるマンなので、こういうことはよくある
このアカウントは、notestockで公開設定になっていません。
こういうの、静的型付きでないせいでむしろ内部表現の違いを隠蔽できていないという感じがしますね (個人の感想)
たとえば Rust であれば Vec<i32> は i32 がヒープ上の連続領域に配置されるし、 struct MyI32Arr(Vec<i32>); であれば MyI32Arr は特定の内部表現を保障しない。
AsRef<[i32]> for MyI32Arr とか Deref<Target = [i32]> が実装されていれば連続領域にあることは保障されるが、ヒープ上であるとは保障しない。
Rust だとそういう「何が保障されていて何が隠蔽されているか」が型からある程度明示的に示されるんだけど、 Python とかは逆に静的型がないせいでそういう保障がない、むしろ「保障したくないことでも、現状あるがままの状態が続くと保障されていると誤解されがち」みたいなところがある
たとえば map() がリストを返すかイテレータを返すかが Python 2 / 3 で違う、みたいな話とか。
そんなん型が明示されていれば問題になりようがないでしょという程度の話なのに、静的型がないから問題になる
Python のイテレータとリストみたいな話もあるので、動的型付き言語での duck typing とか信じてる人を信じていない。
duck を受け取る関数にあなたが渡そうとしているソレが本当に duck のように振る舞うと何故信じられるんですかと
保障がエンコードされない言語でのプログラミング、全てが思い込みをベースに進行するのでおそろしすぎて無理
ていうか、動的型つけならなおさら実行時になるまでマジで何が起きるかわからないのに、動的型つけな言語の方がうまくいく前提でしか書かれてないのすごく謎><
上手く行かない可能性を少しでも減らす(想定を小さくする)為にも型システムがあるのに、それに頼らない上に上手くいかなかった場合の処理まで省いたら・・・・あれじゃん?><(語彙力)
それはむしろ因果が逆で、「自分のコードがうまくいくと (根拠もなく) 信じているからエラーを省くし、信じているから型を付けない」なのではと思っている
まあ一貫性があるとは思うし、エラーを単に無視するか即座に異常終了するかの二択しか選ばないのであればそれはそれで有用な場面もあろうとは思う
バグを致命的エラー扱いするの、決して復帰を試みないという強い信念のもとでは等価なのでそういう方針も合理的ではあると思う
動的静的バトルで、動的陣営の人が「静的型つけな環境で普段書いてる人って、動的型つけな環境使う時、毎度毎度型チェックするコード書くの!?」みたいなこといってたけど、オレンジが仕方無しにPythonで書いたコードってそんな感じだった><
たとえば javascript ヘビーユーザに typeof 使わずに大規模なコード書けるか聞いてみればよさそう (?)
最適化のための型ヒントと、誤りを事前に知るための型検査は正直かなり違うものだと思う……
このアカウントは、notestockで公開設定になっていません。
https://qiitadon.com/@yumetodo/104115744892423926
まあそれは歴史的経緯というか言語の表現力の限界という問題はありそう (たとえば std::begin() をユーザオーバーロードできないせいで begin() と ADL を使うことになったり)
たとえば Rust で「そのつもりがなかったけど誤って Iterator trait を実装してしまった (テヘペロ)」みたいな事故は起きないので……
PolicyKit (polkit) が JavaScript に依存してるのも、結構アレだよなぁと思っている
このアカウントは、notestockで公開設定になっていません。
そうなのよね、いろいろなビルドシステムは基本的にファイルからファイルだといろいろやりようがあるんだけど、 stdout をそのまま別コマンドに繋げたい (ただし繋げる先は条件次第で変えたい場合もある) みたいなとき何を使ったものか難しい
あともうひとつ、外部コマンドをフィルタに使うと「内容は完全に等価だがファイルは必ず出力される」みたいなことがよく起きるので、ここでタイムスタンプを使うタイプの処理系は全滅する
このアカウントは、notestockで公開設定になっていません。
Rust はあの速さで実装と更新が進んでいるからいい感じに進化しているという感じで、まだまだフリーズを考えるには早いという感想
overload も specialization も generic associated types も dependent types も入ってないし、 Rust はまだ「欲しがってる人は相当多いしそのことが認知されてもいるが、実装が完了していない」という機能が結構ある
これは何度でも言っていきたいけど、 Rust 入門する前に「代数的データ型」の概念を知っておくべき
これがあるとないとでその後の理解が大違い
ふと思い立って "rake static site generator" でググったら Ruby on Rails の話が無限に出てきてゴッゴヨそういうとこやぞとなった
C# のCompareTo()がint返すのもモヤモヤしてるし、こういう風にとかどうにか専用の型で返してほしい><
ちゃんと型検査される、『「どっちがでかいの?ていうか同じ?」型』>< · GitHub https://gist.github.com/orange-in-space/51a5ea3884bc0f001923b0a8a6734772
このアカウントは、notestockで公開設定になっていません。
一貫比較 - cpprefjp C++日本語リファレンス
https://cpprefjp.github.io/lang/cpp20/consistent_comparison.html
普通に符号付き整数っぽさある (まあそれはそう)
一応「lhs - rhs の符号と一致する」と覚える手はあるんだけど、かといって実際に lhs - rhs で実装すると整数オーバーフローで破滅するやつな
いやまって、これ比較がオーバーロードされてるだけでちゃんと専用の型使ってるっぽいじゃん
Standard library header <compare> - cppreference.com
https://en.cppreference.com/w/cpp/header/compare
うんうん
このアカウントは、notestockで公開設定になっていません。
HTTP 以外でもたまに TLS 使ったりするからね (MySQL の接続を暗号化したり SMTP / IMAP で使ったり)
XML 変換言語はチューリングおじさんの夢を見ない / Lambda calculus implementation by XSLT 1.0 - Speaker Deck
https://speakerdeck.com/lo48576/lambda-calculus-implementation-by-xslt-1-dot-0
lo48576/xslt10-lambda-calculus: Lambda calculus by XSLT 1.0 (and `node-set()` of EXSLT)
https://github.com/lo48576/xslt10-lambda-calculus
カタカナ語、いわゆるググラビリティの低い平易な言葉と比べて、対象を明確にできる点で重宝するんだけど、アグリー要るのかなー、通信プロトコルの一種なのかなー、という感想です。重宝されている以上、必要なのでしょう。
こういうの、その世界にどっぷりつかってないとわからないですね。
オタクなので「(必ずしも一意である必要はないが) 何かしらの明示的な定義がない言葉は、カタカナ語であろうと日本語っぽいものであろうと等しく曖昧でお気持ちでしかない」という感覚を持っている
アグリーという言葉に何らかの明文化された定義を見出している人々がいるのであればそれには価値があると思います。
まあそんな人がいるとは聞いたことないしそういう定義も見たことないけど……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
静的サイトジェネレータ (で使う文書形式変換) と ActivityPub 実装、どちらを先に実装するか悩んでいる
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
規格と実装が分離できていても、ユーザのレベルが「リスト内包表記と for と map() はどれが早いのでしょうか? 調べてみました!!」みたいなのではしょうがない (?)
https://mstdn.maud.io/@pakutoma/102455093474325552
これで思い出したのが、 Python のリスト内包表記と高階関数みたいなのの使い分けで処理系によって速度が云々みたいなの、最悪の言語デザインだよなぁと思った
まずコード自体の性質でなく処理系での挙動で表現を選ぼうというのが気持ち悪いし、ひとつのことを表現するのにどちらが優勢ともいえない表現が複数存在するの Python 的にどうなのという (Perl の再来じゃん)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
結局「コメント投稿者が自分の責任とリソースでコメントのホスティングを行え」「コメントをコメントされた側の情報発信者が複製して再頒布できるようにしろ」の2つが妥協点として妥当な気がしている
まあ要するに ActivityPub のような分散型のモデルはうまくやればかなり相性良いと思う
このアカウントは、notestockで公開設定になっていません。
Haiku死亡確認はFediverseで書いてもツッコミ対象なんだよな(まず私が見つけ次第ツッコむ)
Firefox OS死亡確認はいまないています……する(Fx0オーナー)
@babukaru
* 回数は無次元
* 次元としては 周波数 × 時間 = 回数
* 具体的単位にすると 1 Hz × 1 s = 1
+ (1 は無次元の単位)
* つまり Hz = 1 / s = s^{-1}
このアカウントは、notestockで公開設定になっていません。
Updating your Extension for 1.0 - Inkscape Wiki
https://wiki.inkscape.org/wiki/index.php/Updating_your_Extension_for_1.0#Python_3_.2F_Python_2_compatibility
そういえば、いつのまにか (やっと?) Inkscape で Python 3 が使えるようになってたんですね
1〜2年くらい前、 Inkscape が Python 2.7 に依存してる (のでシステムから関係する依存を排除するうえで障害になる) のが大変気に入らなかったので、ネイティブにインストールするのをやめて flatpak を使うようにした
Wasabi Has Entered the Japanese Market | Wasabi
https://wasabi.com/blog/wasabi-entered-japanese-market/
How do I access the Wasabi Tokyo (ap-northeast-1) storage region? – Wasabi Knowledge Base
https://wasabi-support.zendesk.com/hc/en-us/articles/360039372392-How-do-I-access-the-Wasabi-Tokyo-ap-northeast-1-storage-region-
> Access to Wasabi's Tokyo storage region for non-NTT Com customers is planned for later in 2020.
@babukaru
* m とか s とか kg みたいな単位はそれぞれ「長さ」とか「時間」とか「質量」という別の物理量を表現していて、こういったものを「次元」と呼ぶ。
* 同じ次元でも、 mm, cm, m, km, AU (天文単位) といったように複数の単位が使われうる。が、これらは倍率が違うだけで定数倍の差にすぎない (たとえば 1000 mm = 1 m のように)。
* 加減算をするときは次元が同じ量同士でないとできない。 1m + 1cm は同じ「長さ」の物理量なので足し算できるが、 1m + 1kg は次元が異なるので無理。
@babukaru
* 物理量の次元は、別の次元の積や商で表現できることがある。たとえば m^2 は長さと長さの積だし、 km/s は長さを時間で割ったもの。
* 様々な物理量の次元は、実はもっと少数の種類の物理量の積・商として表現できる。 たとえば W (ワット) = m^2・kg・s^{-3} のように。
* 様々な物理量の次元のうち、精密な値を測定しやすかったりいろいろな理由で扱いやすかったりするものを選んで最小限の基本的な次元セットを取り出したのが、 SI 基本単位
SI基本単位 - Wikipedia
https://ja.wikipedia.org/wiki/SI%E5%9F%BA%E6%9C%AC%E5%8D%98%E4%BD%8D
このアカウントは、notestockで公開設定になっていません。
traverse はグラフ全体な印象があるし、特定の edge について言うならどちらかというと follow の方が近そう
物理量の次元の話、ベクトル空間とかについて基本的なイメッジを持っていると話が早いんだけど、むしろ逆に物理量の次元の話からベクトル空間のイメッジを得る方向の方が自然な気がしてきた
このアカウントは、notestockで公開設定になっていません。
visit は目的語が edge よりも node っぽいという印象 (エーゴわからん)