レポートといえば、やっぱり自前で ODF 吐かせるしかないですね https://github.com/azyobuzin/reportyatsu2
レポートといえば、やっぱり自前で ODF 吐かせるしかないですね https://github.com/azyobuzin/reportyatsu2
ORM に CREATE TABLE させてるから CHECK 制約つけてなくて、不整合データが生まれてないかを調べられていないのが難点
未着手ジョブ数が減ってきていて、探索順をちゃんと決めてあげないと、もしかしたら最後の方に全然並列にならないかもしれないなぁという思いになってきた
docker build コマンドに --squash オプションつければ容量半分になりそうだな。そんなオプションがあることに初めて気づいた。というのもイメージがでかい原因が、 Dockerfile の ADD --chown がなぜか(Windows で作った tar.xz だからか?)効かなくて、所有者が root になってしまうので、ゲームファイルすべてに対して chown してイメージサイズが実質 2 倍になってる
✔ 4GB の tar.xz の展開が遅い
✔ Wine の依存パッケージが多すぎて apt-get install が遅い
結果があってるかはともかく、完走しました!!!!!!!!うおおおおおおおおおお!!!!!!!!!!!!!!!!!!!!
とりあえず 8 時間あれば完走させられることがわかったので、ここでバグが発見されても実行時間の予測はつくな
とりあえず僕の予想値よりジョブ数が少なかったということは、選択肢到達回数が 1 回少ないパターンが僕が知っている範囲より多いということだから、それが何だったかを突き止めなきゃいけないかな
とりあえず結果の DB をバックアップし、ソースを push したので、いま HDD が壊れてもこの偉大な進捗は消えない
探索結果的には、最初の選択肢で上を選んだとしても、選択肢 10 番に到達しない場合が 512 存在するらしい
完全に理解した。 10 番のイベントが発生しないのは、最初の選択肢で下を選ぶ or 「3番目の選択肢で下を選ぶ」がトリガーっぽい。こっちは気づかなかった
1番目と3番目の選択肢は、かおるこの好感度に関わるので、かおるこの好感度がマックスじゃないと、学園祭前夜イベントが発生しないということっぽく、これは実際に全部手動で動かさなくても納得がいく結果
IReadOnlyDictionary<(int, ChoiceAction), IReadOnlyDictionary<Heroine, double>> 型が生まれた
ある選択肢を選んだときに誰のルートに行くかの確率を出してみた
jitaku. azyobuzi .net :30416 / results
んだけど、未尋以外は的確にそのキャラの好感度を上げる選択肢を選んでいかない限り到達できないということがわかってきた。逆に未尋に対する地雷は存在しない
というかこの雑に出した結果でも得られる情報結構あるなぁ。4番とかどっち選んでも何も変わらないじゃんw
実際の選択肢と番号を紐づけて見た感じ、そもそも未尋に関わりそうな選択肢はどっちを選んでも毒にも薬にもならないっぽい
ブログ書くために、まだ Docker 化する前の Windows 上で動かしていた時代のやつを動かして、スクリーンキャプチャ撮ろうと思ったら、選択肢全部記録させた DB 消しちゃったっぽいな……
Surface の初期化するときに、ソースコードは GitHub にあるからええやろw っていって DB も消した臭い
OKを押したつもりが2回押していて、下にあった「記録したデータを削除」ボタンまで押してしまって終了した
今回書いた探索コードのアルゴリズム、1年半前のものと同じだと思ってたけど違かった。前のバージョンは深さ優先で探索していて、次に探索するリストでメモリを食わない仕組みになってた。ちょっとずつ記憶を思い返してみてるけど、このコードを書いていた時点では何パターンあるかの試算をしてなかったから、メモリに乗り切るのかが不安だったという説
> FreezePeach and SeaLion are down due to a bad RAM DIMM
最近あの鯖がハードの不具合で死にまくってる印象があるんだけど
ワガハイを Wine で動かし始めたときの作業ログが見当たらない、もしくは今死んでいる FreezePeach にいろいろ書いてたかもな……
はてなブログに投稿しました
主人公の好感度問題 完結編 - アジョブジ星通信 https://azyobuzin.hatenablog.com/entry/2018/10/29/002457 #はてなブログ
ワガハイ全探索のまとめ https://azyobuzin.hatenablog.com/entry/2018/10/29/002457 ですが、言葉足らずだなぁと思って後で加筆しようと思っているのですが、実際ここの説明が足りねぇよ!と思うところがありましたらご指摘いただきたく
意識低い系として生きてるけど、大体手を動かし始めれば何らかの楽しみが見つかる性格でとりあえず乗り越えられるから良かったと思ってる
このアカウントは、notestockで公開設定になっていません。
探索方法、もっとセーブを活用して刈り取れば高速化できるんですけど、バグってないかの検証が難しくなるので、正しい結果が出たことをさっさと知るために、雑なやり方になってます
TL;DR としてうな氏の https://mstdn.maud.io/@unarist/100976963847747421 を採用させていただきました
Ashe がどんな風に自動操作をするのかについて加筆しました。クイックセーブを使って最初の選択肢まで戻ってきています
スマホ落としたら画面は割れなかったけど、数日後に電源ボタンに触ってないのに押し続けてることになって、シャットダウンしても勝手に生き返るようになったよ
コカコーラゼロは、むしろゼロのほうスッキリしていて好きなくらいだけど、三ツ矢サイダーゼロは三ツ矢サイダー名乗るのやめろ
UNION!!、 GPM のコメントに音質が最悪と書いてあって検証した結果、音がギチギチに詰まっていて地獄みたいな話をしたけど、それはそれとして、最高に高まる
Mastodon、設定画面に「新規アプリ」ボタンがあるから、そこからしかクライアントキー作れないように思えなくもない
適当な Linux マシンがあると、 Docker for Windows を使うよりも効率的にワーカーが走らせられる(?)
goroutine の良さは go func という構文ではなく、 await 構文なしで並行処理がいつの間にか書けているというところにある
Raspberry Pi で x86 エミュレーションソリューション(有償)、存在してるってことはできなくもないのか。まぁそもそも QEMU で試してみてすらいないので、愚直な方法がどんなもんかを知らないけれども
Go に 2 CPU 以上使うように環境変数で設定すると、どの OS スレッドで動くかはわからなくなると聞いている
それが怖いかというと、上位レイヤーのアプリではまったく問題ない上、適度にプリエンプティブなので、イベントループにありがちな詰まりも防げる
単純に x86 コードを走らせたいだけだったら、 Bochs より QEMU のほうが速そう? Bochs は CPU の挙動自体をエミュレートしてるから、その層からデバッグしたい人向けって感じがした https://www.ibm.com/developerworks/jp/linux/library/l-bochs/index.html
他のアーキテクチャ用のローダーを用意すると Linux がうまくやってくれるのかこれ https://wiki.debian.org/QemuUserEmulation
[Linux][Debian][C#] binfmtという魔法 - Linux上でC#とmonoが出会うまで - papamitra http://d.hatena.ne.jp/papamitra/20071215/binfmt
PDF相手にもブラウザのリーディングモードみたいなやつ欲しいな。A4印刷用の文書をスマホで読みたくない
A4サイズ PDF をスマホで眺めてたら、字が小さすぎてスマホと目の距離が近すぎてしんどくなってきたので、度の低い眼鏡に変更
ニコカド祭り、ちゃんと追ってなかったので、最後のチャンスを見てるけれども、欲しいラノベが 50% オフになることは……!ありませんでしたー
と思ったが、そういえばこれがあった……が、カクヨムで読んでたぶんには面白かったが、あのだるだるした流れが本で出ても……という気持ちがあって買ってないやつ https://honto.jp/ebook/pd-series_B-MBJ-20139-6-259066X.html
Google Play Books がバチクソ重いんだけど、 iPad Air 2 もうだめなんですかね……
おにぎりスタッバー、まだ3章までしか読んでないんですけど、とりあえず前提知識無しで読んでほしいって感じ
タイトル買いしたラノベ、まだ読んでないんですけど、レビュー見たらどうもタイトル通りではないらしく、楽しみになってきたが、その前にタスクを片付けないとな……
GitHub Actions 試してみたいんだけど、 GitHub のベータ機能の規約がなんか一方的な感じがして、なかなか同意するを押せない
もともと bzr ユーザーで、 Launchpad の Web が重い重い言ってた頃に、 GitHub の軽快な Web は衝撃的だった
JS界隈のレベルの低い人たちは、他人を時代遅れ認定することで自己防衛してるとしか思えない
AsyncLocal が有効に働くのは、その async を管理する側が ExecutionContext を切ってる場合だけなわけだよな。 ASP.NET Core のサーバー部とか読みに行かなきゃなぁ
スマホのストレージ最適化突っ込みたいなら、スマホ業界が落ち着いてきた今がチャンスという気がする。今まではシェア拡大が急務だったと思うので
大体リファレンスとソースコードを見て想定通りの挙動をするかどうかを常に調べながらコード書く癖がついているので、さささっとその場でコード書くっていうのは苦手
走り続けなきゃ死んでしまう気持ち高まりすぎて、無理に走り続けて死んでしまうのが怖い。無意識に他人に追いつけ追い越せを考えてしまうけれども、自分の限界前でセーブしなきゃいけない