このアカウントは、notestockで公開設定になっていません。
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ユニックスには man があるのに woman がないからユニセックスという話ですか
human
↓
(man は person にするべき)
↓
huperson
↓
(son は child にするべき)
↓
huperchild
答えが出ましたね (???) #適当
このアカウントは、notestockで公開設定になっていません。
woperchild 、サンショウウオの子供か何かか？？？ となるんだよなぁ
そういえばここ数年クラシックを滅多に聞いてないんだけど、最近唐突に『アイネ・クライネ・ナハトムジーク』のナハトムジークが nacht + musik であることに気付いた
このアカウントは、notestockで公開設定になっていません。
DLsite での使用額や傾向を見るためのちょっとしたクローラを書いているんだけど、テスト過程で販売終了とともにダウンロード・web閲覧不可になった作品を発見してしまって泣いてる (マジかよ)
サークル登録ごと消えてて、162円で購入していたことがわかった (?)
リンクが全滅してるせいで作品の ID を取るのが面倒になってる、サムネイルの URI から持ってこられるか？
このアカウントは、notestockで公開設定になっていません。
幸運にも (というより日頃の行いがよかったので) DRM 付きの作品ではない、たぶん NAS にバックアップがある
購入した作品は必ずダウンロードしておこうな、DLsite 月5万円マンとの約束だぞ
このアカウントは、notestockで公開設定になっていません。
DLsite Nest という Windows 用クライアントを使うとダウンロードはだいぶ楽できます (なお並列ダウンロードが進まなくなったりクラッシュするバグがある)
このアカウントは、notestockで公開設定になっていません。
Nest は自動展開が便利でね (どうせ画像類とかは zip 程度の圧縮でそうそう縮まないので (と思うじゃん？ BMP と WAV はめっちゃ縮む))
あと非公式の手段で自動化クロールして BAN されると怖いというのがある (利用額が利用額なので……)
使い物にならないだろうけど参考までに書いておくと、 workno が RJ197197、 maker_id が RG07812 です (タイトルは nsfw なので書かんとく)
NAS にちゃんとアーカイブが残っていたので私の勝ちです (当然)
https://ec.toranoana.jp/tora_r/ec/item/040030410826/
これの1〜3の総集編なんだけど、タイトルでググると見事なまでに違法ｱｯﾋﾟﾖｯﾖしか出てこねえな……
https://mastodon.cardina1.red/@lo48576/105493179081813967
これとの比較用に、サークル退会してなくて販売停止した作品のやつも載せときます (こっちはダウンロードと閲覧ができる)
というか120万のうち半分は直近一年やんけ！！！ (!!?!???)
や、考えてみればこれは当然の話で、月5万コンスタントに使えば12ヶ月で60万になるのはそれはそうだった
「DLsite ﾎﾟﾁｰしてもよろしいですか？」
「どうぞ。ところで1ヶ月に何円くらいお使いに？」
「5万くらいですね。」
「
こんなん年収100万くらい上がったところで DLsite に使う額が2倍になるだけじゃん……
言うまでもないけど、貯金すべき金は全部 DLsite に流れています (?)
皆様にアドバイスですが、貯金したいなら新卒のうちから DLsite で月5万使うのは避けた方が良いです
このアカウントは、notestockで公開設定になっていません。
両方向対応のデバイス増えてきたからこういうのにも気をつけないといけないよな…
いやそんなん人類任せってアカンやん。
そもそも差し込んだままで充放電方向を勝手に切り替えられる規格まであるらしく頭抱えてるところ
Unmanagedな関数呼べるのは割と誰でも知ってるやつだけど、そうかしょせんバイト列だからメモリ領域に実行権限持たせてそのまま書いちゃえばいいんだ。
Windowsに怒られたりするやつはVirtualProtectExで解除してますな。
普通のヒープに x フラグ立ってるものなのかな (何も調べてない) (立っているとしてそれを常に仮定すべきでないのはそれはそう)
昔はメモリ領域のフラグ立てる必要すらなかったのよ。NX bitはXP SP2あたりからだっけ…？
まあ機械語をゴリゴリ吐いてやろうという時点で環境依存が強いのはそれはそうなので、べつに今更ポータブルでないとか云々とか考えなくても良いというのはひとつ救いかもしれない (ほんまか)
でもこれ、普多用しちゃったらセキュリティーソフトウェアのヒューリスティック解析（？）でマルウェアと誤判定されてもあんまり文句言えない程度に怪しすぎるやり方な気がする＞＜；
怪しいもなにも、 LL を十分高速に動かそうとしたら JIT が必要になるし、 JIT はそもそも機械語を動的に錬成しながらそっちを実行する機構なわけで、それはもう……
#HITBGSEC 2018 D1: Turning Memory Errors Into Code Execution With Client-Side Compilers - R. Gawlik - YouTube
https://www.youtube.com/watch?v=ONbnKuYEHVQ
From Assembly to JavaScript and Back: Turning Memory Errors into Code Execution with Client-Side Compilers « HITB GSEC – Singapore 2018
https://gsec.hitb.org/sg2018/sessions/from-assembly-to-javascript-and-back-turning-memory-errors-into-code-execution-with-client-side-compilers/
これとか面白かった (単なるメモエリ系バグを JIT のパワーで凶悪化して任意コード実行する方法)
From Assembly to JavaScript and Back: Turning Memory Errors into Code Execution with Client-Side Compilers « HITB GSEC – Singapore 2018
https://gsec.hitb.org/sg2018/sessions/from-assembly-to-javascript-and-back-turning-memory-errors-into-code-execution-with-client-side-compilers/
PDF 資料あった
こういうことがあるので、メモリ関係のバグを何としても防ぎたくなるわけよね (Rust はいいぞ)
まあ真っ当なコード組む人々にとっては、こんなおもしろいことができますよ、っていう話で今んところは収まってしまうね。
まあ現状だと言語処理系とか低レイヤのエミュレータやドライバ系を気にする人でもないと考える必要のない領域ではある気がする (必要がないからといって使わないというわけでもない)
DRM 系の領域もそういうの使ってたりするのかね、私はそっち系さっぱりだけど
Delphi使ってた時には、インラインアセンブラでちょっとMMX命令呼ぶとかやってたので、その気軽さのつもりで出来たら便利そうではあるけど、よほどのレアケースじゃなければ普通に C# / .NETのコンパイラの最適化の方が賢く高速化しそう＞＜；
auto vectorization とか、ほげー現代のコンパイラそんなに賢くなっとるんか……と思ってしまう
そもそもの話をすると、そんな気楽に使いたくなるポピュラーな拡張命令は compiler intrinsics とかそれに近いレベルで提供されていてくれという話なので……
まあ人類ぽんこつだからコード最適化とか本当に自動化すべきである的アレ
人間はアルゴリズムをちまちま弄って高速化するより、最適化ヒントになるアノテーションをいかに楽して確実に的確に付けるかに心血注ぐべき
ていうかオレンジ的に発端である、LeadingZeroCount（GCCでいうところの__builtin_clz）は、なぜか.NETでは5.0まで用意されてなかったという・・・＞＜
PIC 用コンパイラで乗算演算子を使うと、非対応プラットフォーム用にはソフトウェア実装された乗算関数を呼ぶコードを吐くみたいな話を聞いたことがあって、そういう「関数になるか CPU 命令になるか場合による」みたいなのは正直ライブラリよりコンパイラで対応してくれという気持ちが強い。
もちろん inlining とか最適化を開発者が強力に制御できる機構があるなら話は別なんだけど
出勤報告した後に「確認したら今日は休みでした」メールを送った (あほ)
なんでや踊りはちゃんと dansu やんけ！ (そういう話ではない)
語彙、適当かというとそうでもないのでは。工学的な実験言語だし、語彙の作りかたもとても工学的だと思うのだけれども
まあ徹底した文化中立の先に得られたのが「どの自然言語とも直接は似ていない (dansu は例外とする)」だったのは妥当な結果ではあると思う
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
sticky lighting 、サイリウムのことか🤔
去年の中途半端に有能なワイ、今日のための自分にやることヒントを残すも、1/5って買いてたしよく見たら2020年だし何もあってなかった
Lojban grammar - Wikipedia
https://en.wikipedia.org/wiki/Lojban_grammar#gismu_%E2%80%93_core_verbs
ふむ
> Instead, the intention is that the gismu blanket semantic space: they make it possible to talk about the entire range of human concerns. [...] For a given concept, words in the six languages that represent that concept were written in Lojban phonetics. Then a gismu was selected to maximize the recognizability of the Lojban word for speakers of the six languages by weighting the inclusion of the sounds drawn from each language by the number of speakers of that language.
Appendix:Lojban/barda - Wiktionary
https://en.wiktionary.org/wiki/Appendix:Lojban/barda
たとえば「大きい」は Lojban で barda なんだけど、セマンティクスが「x1 is big/large in property/dimension(s) x2 (ka) as compared with standard/norm x3」なのよね。そもそも「広い」と「大きい」の区別っているか？ という
Appendix:Lojban/ganra - Wiktionary
https://en.wiktionary.org/wiki/Appendix:Lojban/ganra
ganra は「x1 is broad/wide in dimension x2 [2nd most significant dimension] by standard x3.」なので、べつに dimension についてはどっちを使ってもいいんじゃないですかね。どちらかを使うと不自然だというのは後付けの文化で決まることであって Lojban が組込みで持っている価値観ではないというだけの話な気がしている
同じ (同じか？) 日本語でも時代によって共起表現が変わるということに不思議はないし、それって単に言語の枠組みをより強く制限する別レイヤーの制約が後付けで入っているに過ぎないのではと
味噌煮込みロジバン: by standard 再考
https://misonikomilojban.blogspot.com/2015/04/by-standard.html
これによれば、 ganra は barda を限定する形で定義されるっぽいので、べつにどちらを使っても誤りでない感じっぽい (より限定された意味を好むのであれば ganra だろうけど)
Lojban 、セルフホストされているのでそっちを読めるようになりたいんだよなぁ (なりたいと言いつつ何もしてないいつものパターン)
The Logical Language Group: Online Dictionary Query- ganra
https://jbovlaste.lojban.org/lookup?Form=lookup.pl1&Strategy=*&Database=en%3C-%3Ejbo&Query=ganra
jbovlaste を読む限りだと ganra は「wide in the sense of "having a large physical extent from side to side"」だし x2 が 2nd most significant dimension なのもわからんし、全体的によくわからんな……
ちょうどﾂｲｯﾃで https://twitter.com/ozAntinnippon/status/1345279157807190016 が流れてきてﾜﾛﾀ
Lojban をやろう……
ちゃんと Lojban to Lojban で解釈しないと駄目か……
味噌煮込みロジバン: Lojban Lessons - 19章 (数)
http://misonikomilojban.blogspot.com/2013/05/lojban-lessons-19.html
remoi が re (2) + moi なのは良いとして、 moi が「x1はx2（集合）・x3（原理）におけるn番目」なので、 significant というのは暗黙の了解であって、プレーンには単に「2番目の次元において」くらいの意味なんだな
The Logical Language Group: Online Dictionary Query- moi
https://jbovlaste.lojban.org/lookup.pl?Form=lookup.pl1&Query=moi&Strategy=*&Database=en%3C-%3Ejbo&submit=Submit+query
> convert number to ordinal selbri; x1 is (n)th member of set x2 ordered by rule x3.
「メリノちゃん用」原作を意識した下着 - go餅屋 - BOOTH https://gogohrns.booth.pm/items/2650247
『ニーア オートマタ』に隠されていた“最後の秘密”が発見される。一気にエンディングへ | AUTOMATON
https://automaton-media.com/articles/newsjp/20210104-148079/
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://twitter.com/lo48576/status/1345975313436557313
Lojban の ganra の英語定義に出てくる "2nd most significant dimension" が何なのかについてひとまずの納得を得ました
Lojban の「ganra」という語の次元や方向はどのように決まるのか - Togetter
https://togetter.com/li/1647339
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
あまり関係ないけど、 datetime-string crate を書いているとき ActivityStreams 2.0 の日時文字列フォーマットが脳裏を過って、あれ秒を省略して secfrac を使えるみたいな妙な仕様なのよね。 2020-12-31T12:34.7890 みたいな。
Activity Streams 2.0
https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#dates
> as2-partial-time = time-hour ":" time-minute [":" time-second] [time-secfrac]
私はこれがずっと気になっていて、理性的に考えると
as2-partial-time = time-hour ":" time-minute [":" time-second [time-secfrac]]
となるべきだと思うんだけど、これが仕様のミスなのか意図してのものなのかずっとモヤモヤしている
これが仕様のミスなのであれば、実装側では 2020-12-31T12:34.7890 のような妙な表現の生成は非推奨であるとして受取を拒絶してしまうというのもアリだと思うんだけど、そこまで思い切ってよいものか判断しかねている
というわけでモヤモヤの共有でした。
いや issue 立てるなりして聞けばいいじゃんという話ではあるんだけど……
いつか datetime-string crate に As2DatetimeString みたいな型を追加する “覚悟” がどうしてもできなくて…… (マジで second を省略して secfrac を付ける奴おるんか？)
このアカウントは、notestockで公開設定になっていません。
[日本列島VR Oculus版 期間限定公開 - ボクスケショップ - BOOTH](https://voxelkei.booth.pm/items/2651783)
配布方法草
このアカウントは、notestockで公開設定になっていません。
何かにつけ罰則で人間をコントロールしようとする人々、インセンティブという概念を知ってから出直してくれという感じだ
いじめを報告すると罰される仕組みだと隠蔽体質になるとかもう105万回くらい聞いたけど、ﾎﾟﾖﾅで未だ同じようなこと言ってる連中はアホなのか？
の投稿
kumanotetu@mstdn.mini4wd-engineer.com
このアカウントは、notestockで公開設定になっていません。
tar は単純な使い方なら割と簡単だと思う
c: create
x: extract
f: file
a: auto compress
これだけ。
tar caf は create, auto-compress, file だし tar xf は extract, file というだけの話
tar c[a]f で最初に与えるのが個数が確定で1個であるアーカイブファイルで、任意個付けられる内容ファイルは最後に与えれば良いので、引数の順番もまあ妥当
tar で圧縮するとき z とか j とか J とか覚えようとしない方がいい、 a で済ませて
tarでvを指定したい人が多い（導入記事でもだいたい着いてる）けど、表示量が多すぎて自分では付けていない。しかしめっちゃファイル数多いと、何も出なくて「動いてんのか？」ってなるので、全体に対するパーセント表示だけみたいな、表示量の少ないオプションが欲しい。
あと小さなファイルが大量にある状態だと、ファイル I/O よりも v によるメッセージの方がボトルネックになったりするので、そういう意味でも必要なとき以外に v を使わない方がいい
tar 自体には進捗表示コマンドはないけど、パイプのデータ流量を表示する pv コマンドとかを使って
pv foo.tar | tar xf -
みたいなことはできる
ターミナルの入出力は絶望的に遅いからvせずにprogressコマンドを使おうねというのはよくある話
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
checkpoint 知らなかった (が、結局これ間引きだから一定期間ごとでの更新にはできなそう……)
emerge -uv gentoo-sources などすると -v のせいでカーネルソースのファイル一覧が出てきて I/O が詰まるので、 emerge -uq gentoo-sources している
tarの--checkpointオプション、全体の数字が欲しいな。テープだから読んでみないと分からない、それはそう。
dd コマンド並に高速な回線 Yahoo! DD #適当
ユリゲラーでさえ卵を浮かせることはできないのに (しらんが)
アセンブリ言語で 42h みたいな書き方してることがあったからとか？
Cでリテラルの「0」が0で始まるから8進数だという話はね……
markdown はコードブロックにキャプション付けられないのがマジで嫌い
仕様として無限ループが提供されていた場合は minor、実装依存みたいな感じなら patch じゃないか
修正と捉えるなら patch version でいいと思うけど
API を破壊しないような挙動変更が仕様バグや実装バグでないケースというのは割と稀という気はするし、それが計算停止性とかの部分に絡んでくるとまあコーナーケースになってしまうのも致し方なくはある
https://semver.org/lang/ja/#spec-item-7
https://semver.org/lang/ja/#%E3%82%82%E3%81%97%E3%81%86%E3%81%A3%E3%81%8B%E3%82%8A%E3%83%91%E3%83%96%E3%83%AA%E3%83%83%E3%82%AFapi%E3%82%92%E3%82%BB%E3%83%9E%E3%83%B3%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF-%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%8B%E3%83%B3%E3%82%B0%E3%81%AB%E5%AF%BE%E5%BF%9C%E3%81%97%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E5%BD%A2%E3%81%A7%E5%A4%89%E6%9B%B4%E3%81%97%E3%81%9F%E3%82%89%E3%81%A9%E3%81%86%E3%81%AA%E3%82%8B%E3%81%A7%E3%81%97%E3%82%87%E3%81%86%E3%81%8B%E4%BE%8B%E3%83%91%E3%83%83%E3%83%81%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%A7%E4%B8%BB%E8%A6%81%E3%81%AA%E3%83%90%E3%82%B0%E3%81%8C%E7%99%BA%E7%94%9F%E3%81%97%E3%81%9F%E5%A0%B4%E5%90%88
このあたりかな
結局のところ「パブリック API あるいは仕様として提示したか」や「ユーザが仕様として認識しているか」が重点という感じがする
