昔の最近の出来事(2020.01)

2020/01/31

気持ち早めに帰着。

本物お仕事でもgitを使う事があるのですが、Emacsのmagitを使ってて ハマってた事があったのでメモ。 共用サーバーの為、少し古めのEmacsを使用する都合上 magitも少し古いものを 使用していました。で、ハマってたのはlogのshort表示の際に、 ハッシュの次に表示されるグラフがズレる事があるというものでした。 具体的には以下のような感じ。

git log の--graphは行の最初にグラフが表示されます。

$ git log --oneline --graph | head
* 5db3324a7e Show key bindings on M-x completion (bug#39035)
* bb3b0990d8 fix bug#39344
* a7a955eedb Revert "Fix MS-Windows build broken by "Install C source code""
*   93b5530662 Merge branch 'scratch/ns/draw-to-bitmap'
|\
| * f674c905dc Draw to offscreen buffer on macOS
| * 3ad7813296 Revert "Make all NS drawing be done from drawRect"
| * 6b955c26f6 Revert "Ensure NS frame is redrawn correctly  after scroll"

一方、magitでは、

5db3324a7e * Show key bindings on M-x completion (bug#39035)
bb3b0990d8 * fix bug#39344
a7a955eedb * Revert "Fix MS-Windows build broken by "Install C source code""
93b5530662 *   Merge branch 'scratch/ns/draw-to-bitmap'
           |\
f674c905dc | * Draw to offscreen buffer on macOS
3ad7813296 | * Revert "Make all NS drawing be done from drawRect"

てな感じで、行の最初にハッシュが表示されるように整形されています。 この例で使用したmagitは最近のなので大丈夫っぽいのですが、古いのだと ブランチがマージされる辺りの表示が、

93b5530662 *   Merge branch 'scratch/ns/draw-to-bitmap'
        |\
f674c905dc | * Draw to offscreen buffer on macOS

てな感じでズレて表示されてました。 そもそも git log ではグラフを行頭以外に表示する事ができないようなので、 順番を変えるにはmagit側で文字列を加工する必要があります。 ところが、グラフのマージしたり分岐したりする部分はハッシュ値がありませんので、 どうにかしてハッシュ値の文字列長を取得して、同じ長さの空白文字列を挿入する 必要があります。で、そもそもハッシュ値の文字列長をどうやって決めているのかを 調べてみると結構面倒臭い感じでした。

git log で出力をカスタマイズする際に短いハッシュ値を表示するには、

$ git log --pretty='%t'

てな感じで、「%t」で表示できます。 これをキーにWeb検索してみたのですが「デフォルトは7文字」という情報が出てきた のがハマリ所でした。因みに、git logで %t などで表示する短いハッシュ文字列の 長さを変えるには、

$ git log --abbrev=14 --pretty='%t'

とかやれば変えられます。magitでlogを取得する際にオプション指定すれば、 まぁ対応可能っちゃ可能。

でも、「デフォルトは7文字」にならないのは何故?というのが謎に思い、 もう少し調べてみると、magit内で「git config core.abbrev」で文字列を 取得している節があったので再びこれを手がかりに調べてみた所、 core.abbrevが指定されていない場合は、状況に応じて長さが決められると いう事が判りました。てか、「デフォルトは7文字」じゃないじゃん。 ここでややこしいのは core.abbrevが指定されていない場合に、 自動で決められる長さ(結局何文字出す事にしたか)を取得する手段が無いという所。 magitではハッシュ文字列長を magit-abbrev-length という関数で取得しています。 新しいmagitでは「core.abbrevを検査して、指定されていればその値を使用、 指定されていなければハッシュ文字列を取得&長さを調べて使用する」という動作になって ます。一方、古いmagitでは「core.abbrevを検査して、指定されていればその値を使用、 指定されていなければ(ハードコーディングされた) 7 を使用する」という動作に なっていました。

という訳で、古いmagit向けには 関数magit-abbrev-length を再定義して、 ひとまず所望の長さを返すように対応しました。ただ、原因とmagitの 動作が判ったので core.abbrevを明示的に指定しておくというのでも良いかも知れません。

2020/01/30

早くも無く遅くも無く。

万華鏡。max_trace_levelを増やしたレンダリングが終わったり。 Elapsで104.48時間なので丸4日とちょい。100時間くらいかかる予想をしていた のですが丁度それくらいでした。



回転が速すぎて万華鏡感が無い&長く見ていると目が回ります(@_@; イマイチ。 6倍以上遅くした方が良い気がするのですが、レンダリングに600時間以上かかる 計算になるのでちょっとなぁ?という感じ。

2020/01/29

遅めに帰着。

Webを散策してて、svg-clock というELISPアプリの存在を知ったり。アナログ時計をSVG形式でEmacsのバッファに 表示するというものです。最新のELISPはEmacs 27でしか動かないようですが、 先月ビルドしたEmacs-27.0.50で ちゃんと動きました。26.3ではmake-decoded-timeという関数など知らんと言われて エラーになりました。

さておき、どういう仕組みで描画しているんだろう?と思いソースコードを参照してみたり。 どうやら、Emacsの標準パッケージにlisp/svg.el(Emacs 25から使えたらしい) というのがあり、SVGを直接生成して画像としてバッファを表示する感じで 描画しているみたいでした。ふと、これ使えば 拙作のsysmonも文字を使った グラフ描画じゃなくてグラフィックス描画のグラフにできるかも?と思ったりも。 svg-clock は4Kディスプレイ(ただし150% 表示)でEmacsを全画面表示しても普通に 描画できたので、どれくらいの描画性能があるものなのか気になってきました。

2020/01/28

遅めに帰着。

「映像研には手を出すな!」を録画で視聴。浅草の技術的なセリフに いちいち なるほどと思ったり。来る2月2日の16:15から これまでの 1話~4話が一挙再放送される模様。

2020/01/27

早くも無く遅くも無く。

電気屋さんにエアコンの修理を依頼したり。と言っても部屋に据え付けなので 点検してからどうするか決める事に。点検は週末。修理と言いつつ ほぼ交換する 方向になる予感がするので、その場合はまた次の週という感じかも。

2020/01/26

AM中に起床。

午前時点で雪も雨も降っていなさげ。

掃除したり洗濯したり。

万華鏡。画面の端の明るさが足りない件、どうやら global_settings.max_trace_level が足りなかった模様。 デフォルトでは5なのですが、鏡面反射がそれでは足りなかったので 10に増やしていました。鏡面反射は10で足りていたようですが、 屈折の方にも連動するらしくそちら向けには足りなかった結果、床は 明るいのにガラス系オブジェクトは暗いという結果になっていたと 推測されます。max_trace_levelが足りないと気づく前の昨夜から、 カメラ設定を変えて一晩分実行していたのですが一旦キャンセル。

max_trace_levelを15にしてみたのですが結構時間がかかるな。

以前、24bitカラー対応のscreenコマンドの ビルドを試してみたのですが、hardstatus表示がうまく行われていない ような感じでした。最新版で何か変わっているかな?と思ったのですが、 新しいコミットは行われていないようだったり。何か使うライブラリが マズくてカラー表示されていないのかしら? とも思ったのですが、 日付や時間も表示されていないようなので、何か壊れているんじゃないの? とは思うのですが.....?
こちらのページにあるように、例えば %c は時刻を表示する事が できるように記されていますが、Cygwinにインストールされているmanページを 眺めてみたところ、「STRING ESCAPES」の項目には %c は含まれていない ようだったり。でも、Cygwinのscreenでは使えているので何が何やら。 イマイチ正解が判りません。

もう少し調べてみたところ、どうやらinfoとmanとで内容が違う(manの方が 情報が少ない?)みたい。どちらが正解かは判りません。両方間違っている 可能性もあるかも?

ソースコードを眺めてみた所、どうやら仕様が大幅に変わっているみたい。 git最新とscreen-v.4.7.0のソースと見比べてみました。


screen コマンドの 開発者向けMailingListページを検索してみた所、 こちらのエントリ にhardstatus のフォーマットが変更された事への対応方法の回答があったり。 どうやら日付はdateコマンドを使用し、backtickというscreen内コマンドで 外部コマンド実行をマクロ定義して使うようになってるみたいです。

もう少し具体的に、普段TANEがscreenコマンドで使用しているhardstatusは 以下のような感じなのですが(元はWebで拾ったものです(^^;)、

hardstatus alwayslastline "%{= kw}%-w%{= rw}% %t%{= kw}%+w %=%H %Y/%m/%d %c"

これを git最新のscreen向けには

truecolor on
backtick 0 5 5 "/bin/date" '+%Y/%m/%d'
backtick 1 5 5 "/bin/date" '+%H:%M'
hardstatus alwayslastline "%{= #ffffff;#000000}%-w%{= #ffffff;#ff0000}%n %t%{= #ffffff;#000000}%+w %=%H %{#ffffff;#000000}%0` %{#ffffff;#000000}%1`"

てな感じに変換すれば良さげでした。

screen true color hardstatus変換

「infoやmanも更新して~~」って感じではありますが、リリース直前まで 更新されないんじゃなかろうかという気も。
後はCygwinでビルドできれば完璧なのですが。そういや外部コマンドでdateを実行するような 仕組みだと、fork()の遅いCygwinでは「なんかちょいちょい突っかかるんだけど?」って ならないかな?とは思ったりも。

2020/01/25

昼過ぎ起床。寝すぎ。

SAI2の新しいのが来ていたり。バグ修正がメインの模様。

先日、Emacsでのファイル読み込み(C-x C-r など)でディレクトリパスを TABキーで補完しようとすると、Emacsがハングする件にまた遭遇したり。 MailingListでは同様の報告は上がっていないものの、Cygwin本体に ちょっと怪しげなバグがあるっぽいので何かしら関係するかも? ひとまず、Cygwinのバージョンが変わってる(develパッケージもアップデート されている)ので Emacsを再ビルドしてみたり。 再ビルドしたEmacsで意図的にファイル読み込みでパス補完を行ってみたところ、 割と簡単に遭遇する事が判ったり。

ひとまずトリガが判った気が。結論から言うとCygwinは関係ありませんでした。すみませんm(_'_)m

常時、拙作である sysmon というCPU負荷を表示するelispアプリを実行しているのですが、 例えばファイル名補完をするとファイルの一覧を表示するバッファは、表示 するファイル数に応じて高さが可変となります。その際に、隣り合わせとなる sysmonのウインドウが拡大される場合があるのですが、そうすると表示する文字 数が多くなり過ぎる場合があります。再描画のインターバルを1秒に設定している と、拡大表示した場合は1秒で描画しきれなくなり、 最後にはsysmonの再描画→1秒で間に合わない→また再描画→間に合わない→.... で ライブロックしている状態に陥るという事のようです。描画が間に合わなくても 必ずキー入力を受け付けてくれれば、一瞬スローダウンするけど操作不能に 陥るという事にはならないと思われるのですが、そういう訳ではないようです。

もっと単純に、sysmonだけをそれなりのサイズの行桁で表示して 放置しておくと、段々と描画が遅れ始めてそのうちハング状態に陥りました。 起動して最初の頃は左端の数桁しか描画されていないので、その状態であれば ハングする事はありません。これが必ず再現しないという現象に見えている という流れだったようです。内部的にはウインドウサイズに応じた行桁分だけ 空白文字で埋めているので、ウインドウサイズを大きくするだけでも ダメになるハズですが、プロット文字で埋まっていくとスローダウンする所を 見ると、空白文字の場合は表示しないような最適化が行われているのかな?と 思ったりも。

これまで数年の間 同じように使っていたのですが、ここ最近になって発現する ようになったのは、POV-RayのレンダリングでCPU負荷が高い状態で使っている為、 描画がギリギリ追い付かないのかな?と思ったり。とは言え、ハング状態に陥る のは色々と面倒臭いので対応が必要と思います。

今できる対応としては、sysmon-update-intervalという変数で再描画間隔を 指定できる(デフォルト1.0秒)ので、これを5.0とかに伸ばす。大分待たされる 場合はあるのですがキー入力はなんとか受け付けられるので、ハング状態に 陥るのを回避できます。

sysmonのハング対応を考えてみたり。-nwではターミナルをフルスクリーンにして 475桁×110行(=52725文字)とかで表示しても、再描画間隔 1秒でハング状態に陥る事は ありませんでした。単純に Cygwin Emacs-w32の文字描画が死ぬほど遅いという所に 起因するようです。ここはしかたがない所なので、文字数を閾値にして閾値を 越えるようなグラフ描画になる場合は描画を行わないようにしてみたり。 ひとまず瞬間的にsysmonのウインドウが大きくなる場合があってもハング状態に 陥る事は無くなりました。 ただ、そもそも 8500文字くらいの表示でも、GUI表示では他のウインドウの入力に ラグが生じる感じです。-nw では6倍くらいの文字数を表示してもへこたれないのに 比べると大分イマイチな描画性能に思えます。

FedoraのEmacsでも確認してみました。GUIモードでは 文字数が多いとCygwinのと 同じくハング状態に陥りましたが、C-gが効くのでどうにか止める事は可能でした。 ただ、C-gで止めるとsysmon自体が停止状態となるので再実行する必要がありました。 なので、再描画キャンセルの閾値を指定する機能は有用みたい。

そんな訳で sysmon を更新してみました。ご参考まで。

万華鏡。うっかり時間がかかってしまいましたが、約50.5時間でレンダリング完了。



少しダイナミックになった気もしますが、もう一声なんか無いかなぁ?と思ったりも。 あと、端の方の明るさが足りないのがイマイチに思うのですが、何故そうなるのかが 判りません。

2020/01/24

飲み会で遅めに帰着。

あまりの眠さに急速停止。

2020/01/23

遅めに帰着。

万華鏡。カメラを調節して再レンダリングしてみてるのですが、 うっかり光源を追加してしまいレンダリング時間が2倍以上になっていたり。 終わるのは明後日になりそう。

そういや最近Cygwinを3.1.2にアップデートしました。それと関係あるかは 判りませんが、Emacsでminibufferに表示されるディレクトリパスをタブキーで 補完しようとすると、Emacsがハング状態に陥る現象に二度ほど 遭遇しました。特定の操作で必ず再現する訳ではないので原因は判りませんが、 ちょっとイヤな感じ。

2020/01/22

遅めに帰着。

先日のレンダリングは23.5時間時点ではまだ終わらず。でもあと残り 40分くらいか。

そういや「映像研には手を出すな!」の原作者の 大童澄瞳氏のWikipedia から、氏のPixivアカウントへのページが辿れたり。一番最初にアップロード された作品は12年前のようなのですが、Wikipediaによると氏の現在の年齢は26歳と なっていて、12年前ってまだ14歳じゃんかと思ったり。 TANEがPixivのアカウントを取得したが偶然にも今から 約12年前だったり。 ついでに言うとSAIのVer1.0がライセンス販売開始されたのも この年でした。 という訳で、2008年当時の中学生が現在20代で漫画家になっていても 別におかしくは無いのかと改めて思ったりも。

Web散策していたらレンダリングが終わったり。動画にしてみたのですが ちょっと動き過ぎたかも。

2020/01/21

遅めに帰着。

万華鏡。丁度、朝レンダリングは終わっていたり。 カメラを粒の中まで移動するようにした所、万華鏡感は減ってしまったのですが、 ダイナミックな感じが良いなとおもったり。所がループ再生で絵が繋がらない感じ になってたり。コードを見直してみた所、rotateする場合に360°(1回転)の整数倍 でない値を設定しているのが原因の模様。しまった。

もう少し万華鏡感の出る所も狙って再度レンダリング開始。

そういや日曜の深夜にNHK総合で放送されている「映像研には手を出すな!」 のアニメ。面白いなこれ って感じです。原作は月刊!スピリッツの連載らしいのですが、 漫画の止め絵で説明するよりも、ずっと解りやすくなっているのではないか と想像します。設定大事な理由が少し分かったかも。

2020/01/20

遅めに帰着。

万華鏡。昨日弄った分のアニメーションレンダリングは24時間時点でまだ3分の2を少し越えた所。 明日の午前中に終わる感じか?

2020/01/19

AM中に起床。

掃除したり洗濯したり。

ちょろりお出かけ。去年末に出ているハズのはじめアルゴリズムの10巻を捕獲できず。

万華鏡。カメラを動かすようにしてみたのですがあまりぱっとせず。 因みにレンダリング時間はちょうど24時間くらいでした。もう少し弄ってみるとどうなるか?

SAI2の新しいのが来ていたり。バグ修正がメインの模様。

2020/01/18

昼過ぎ起床。寒くて死亡。

エアコンが復活しないので数日間コンセントを抜いていました。 今日、復活を期待して電源を入れてみたのですがダメでした orz

万華鏡。エリアライト(面光源)を使用すると、反射を繰り返す度に明るくなる原因 を調べてみたところ、鏡のtexture.finish内のreflectionパラメータに指定している metallicの値が原因でした。因みにmetallicという文字列で別の意味を示す パラメータがあってややこしいです。texture.finish.reflection.metallicは 金属のような反射を表現するとなってて、これを0.0にすると反射を繰り返す 度に明るくなる事はなくなりました。という訳で、エリアライトが原因というよりは テクスチャのパラメータとエリアライトの組み合わせにより発現する現象でした。

平行光線ライト エリアライト

左の絵が並行光線ライト、右の絵がエリアライトを使用したものです。 エリアライトを使用すると影が柔らかくなるのですが、集光模様は 平行光線ライトを使用した方がクッキリするので、好みが分かれる所かも 知れません。また、エリアライトを使用するとレンダリング時間が長くなる (今回の例では「使用:未使用=24.58分:1.68分」で14.63倍長い)ので、 アニメーションを行う場合は使用可否判断の分かれ目になるかも知れません。

そういえば、Googleマップの航空写真は3D表示が可能になってて GoogleEarthの機能と統合されたのかと思ったのですが、ここ最近、 マップとは別に3D表示する場合はGoogleEarthっぽいのが表示されるようになってます。 統合されたのかと思ってたのに何故また分離されてるの?と思ったのですが、 3D表示可能な地図は少し古いようで、(最新地図と思われる)マップと 食い違いが生じているからか?と思ったりも。

2020/01/17

早くも無く遅くも無く。

GTS。いくつかGTリーグにイベントが追加されていたのですがルイス・ハミルトン チャレンジの方をやってて気づいてませんでした。少し消化してみたものの、 直ぐに取れないのもいくつかあったり。

そういやアーケードアーカイブスに「出たな!!ツインビー」が来ていたり。 アーケード稼働は1991年なのですが、という事は1990年稼働の 「パロディウスだ! 〜神話からお笑いへ〜」もそのうち来るか?と思ったりも。

2020/01/16

気持ち遅めに帰着。

万華鏡。粒の数を増やしてアニメーションレンダリングした所、帰った時にも まだ終わってませんでした(^^; もうあと数フレームという所だったのですが、 風呂に入ってたら終わってた。合計で、23時間ほどかかったようです。 で、絵の方は、まぁこんな所かな?という感じ。



レイトレースなので、あるガラス玉位置とそのガラス玉の集光模様の位置関係が、 絵の中央付近と外側とで異なります。元となる絵を回転や反転させて 描くフェイクっぽい方法だとこういう感じにはならないと思います。 ですが、正確な環境マッピングでなくても人の目にはそれっぽく自然に見える のと同様に、実際のところフェイクっぽい方法でも何の問題も無いかも とは思ったりも(^^;

因みに、使用CPUはCore i7-7700K@4.2GHz。7スレッド使用で 1920x1080のサイズで720枚レンダリング するのに23時間かかりました。動画は1920x1080で720枚を60fpsで再生。なので12秒の 動画という事になります。

2020/01/15

気持ち遅めに帰着。

万華鏡。粒をそれとなく動く感じにしてみた所、ちょっと良くなった気も。 もう少し弄ってみたのですがどうなるか.....?

こちらのblogエントリ より知った、ファミコンソフトの忍者ハットリくんのソースコードが 公開されているという話。オールアセンブラというのは当時としては 普通だったと思われますが、アセンブラだと具体的に何をやっている のかが直ぐには判らないなぁ?と感じます。単にニーモニックが判らないと いう話ではなくて、例えば右にキャラクタを動かすのにX座標を X+=N すると いう風にプログラム言語的に表現されていれば変数名とその演算とから 何をやらんとしているかがもう少し想像し易いと思うのですが、 レジスタレベルまで落とし込まれていると、今このレジスタには何の値が ロードされているか?ってのはプログラム言語的に表現された物に比べると かなり判りにくいと思います。恐らく、自分で書いた物が他の人に読めるか? という観点で見ると、アセンブラで書くと他の人が直ぐに読めない率が 上がるような気はします。

2020/01/14

遅めに帰着。

先日の万華鏡を少し色調節してアニメーションをレンダリングしてみたのですが、 中の粒をただ回転させただけだとイマイチな感じだったり。中の粒をもっと動かして みたらどうだろう?と思ったのですが、そういやPOV-Rayのrotateって 任意軸で 回転させるにはどうすれば良いんだ?と思ったり。ベクトル関数には vaxis_rotate(A,B,F)というのがあり、三次元位置AをベクトルBを軸にF度回転させる 事ができるようですが、あくまでAを回転させる場合なので、オブジェクトを回転 させるrotateでは使えないような。

そんな訳で任意軸でのオブジェクトの回転はおいといて、粒をそれとなく動く感じに してみたのですがどうなるか.....?

2020/01/13

AM中に起床。

アパートの契約更新にお出かけ。サクッと終了。

ふと思い付きでPOV-Rayで万華鏡を作ってみたり。ベースはWingsを使ってカメラ 設定や反射の調節などを行ってみたのですが、中に入れるオブジェクトを手で 置くのは面倒臭いので、途中からPOV-Rayの制御構文を使って乱数でオブジェクトを 配置してみる事にしてみました。なんとなくイケそうな感じになったのですが、 XZ平面上に乱数でオブジェクトを配置してみたところ意外と重なるので、 衝突判定を行ってオブジェクトが重なった場合は位置を再度決め直すみたいな 感じにしてみたりと、調節の方に時間がかかるのはPOV-Rayではいつもの事 という感じです(^^;

万華鏡テスト

面光源を使用すると、鏡に映った絵は少しずつ明るくなるようです。なので、 この絵では真ん中の一番暗い三角形のエリアが鏡ではない部分になります。 カラフル感が無いのでもう少しオブジェクトの色を調節した方が良いかなぁ? と思ったりも。あと、アニメーションも少し試してみたのですが、レンダリングに 時間がかかりそうなのでもう少し止め絵で調節してからの方が良いかなと思ったりも。

2020/01/12

昼頃起床。

掃除したり。

以前、24bitターミナルの存在を知り、 Cygwinのminttyはサポートされているというのを知ったのですが、 screenコマンドを介すると24bitカラーにならないという状態でした。 で、Webを散策しているとscreenコマンドのgit最新コードでtruecolorという オプションが追加されているらしいというのを知り、 screenのgitサイト からcloneしてビルドを試してみる事にしたり。結論から言うと Cygwinでは うまくビルドする事ができませんでした。Fedoraの方でビルドを試してみた所、 PAMを外してなんとなくビルドできたり。

screen true color

ややこしい絵ですが、Cygwinのmintty からsshでVMware上で動作するFedoraに ログインし、ビルドしたscreenコマンドを起動して、screenのウインドウを 上下に2分割表示し、「:truecolor on」でtruecolorを有効にした後、上側に 「TERM=xterm-24bit emacs -nw」で表示、下側は「TERM=xterm-256color emacs -nw」 で表示してみました。使用したEmacsは26.3です。上側はちゃんと24bitカラー表示に なっているし、下側の256カラーもそのように表示されるようです。 因みに、Emacs-27では24bitカラーで表示するのに「TERM=xterm-direct emacs -nw」 とかやれば良くなるようで、Emacs-26での terminfoを自前で追加する方法を行わなくても よくなりそうです。

ただ、screenコマンドの飾り表示を行うhardstatusで現在時刻とか表示している つもりなのですが うまく表示できていないようです。とは言え、普通にscreenコマンドで 24bitカラーが使えるようになるのはそんなに遠い未来の話では無さそうです。 ついでに emacs -nwでも libsixelで画像表示できるようになると面白いかも?

2020/01/11

起きたら昼過ぎ。寝すぎ。

GoogleMapで20年ほど前に住んでいた辺りを見てみると、大分様子が変わってて 住んでいた寮も取り壊し工事をしている感じになってました。 引っ越し先を探すにあたってふらっと入った不動産屋 で、その時に決めて引っ越した訳ですが、Googleで事前に検索する訳でもなく 偶然見つけた感じだったというのに、今にして思えばよく辿り着けたなぁ? と思ったりも(^^; 今だとGoogle検索してみてから近場で決めるという感じ にするだろうなと思うのですが、それだと大手の不動産しか出てこなかったり すると思われる訳で、選択肢があるような無いような微妙な感じがするなぁ とは思ったりも。

ちょろりGTS。自分のラップを更新できません(^^;

2020/01/10

遅めに帰着。

ちょろりGTS。さっぱり。

2020/01/09

遅めに帰着。

エアコンは全く復活する兆しが見られず。いよいよダメになったのかも。 寒くて死亡。

2020/01/08

遅めに帰着。

Web巡回して終了。

2020/01/07

遅めに帰着。

SAI2の新しいのが来ていたり。お疲れ様です。設定がマイドキュメントの下 に置かれるようになったのですが、インポートすれば大丈夫。 恐らく次の版数以降は設定ファイルを直すとかの作業も不要になるのでは ないかと推測されます。テクスチャの確認がSAI上で行えるようになった のは便利です。素材を管理するダイアログが追加されているようですが、 まだ実装途中のような気も。散布のテクスチャとか全てSAI2上でできるように なると便利になりそうな予感。

2020/01/06

今日までお休み。ゴミ捨てに朝起きてぐうたら過ごしたり。

掃除したり。エアコン復帰せず。寒くてつらい。

2020/01/05

昼前起床。

エアコンが不調なままなかなか復活せず。いよいよダメになったか?

2020/01/04

昼頃起床。寝すぎ。

そろそろ社会復帰に備えなくては(^^;

2020/01/03

AM中に目が覚め、TV観ながらぐうたら過ごしたら午後もいい時間。

エアコン不調で停止。

2020/01/02

AM中に目が覚めながらもぐうたら過ごしたら午後もいい時間。

うっすら喉に痰が絡んだ状態が続いててなんか不調。

2020/01/01

あけましておめでとうございます。今年もよろしくお願いします。

とは言えまだ明けて35分しか経っていませんが。 今年のPixivは 最大で1840psくらいでした。30分くらいで677psになってたので 大体例年通りという感じの値だったかも。

寝て起きたら午後もいい時間。寝すぎ。

「ONEPIECE(95)」。作戦が失敗しているように見える中での回想。 今の段階ではオロチが台頭してくる理由は無さそうに思ったりも。 まだまだ続きます。


TOP PREV