堕天使の煉獄

Gallery
Comic
Story
Production
Work
Link

2016-09

14

23:47:49

気力の問題

久方ぶりに新規絵(といっても落書きとして日記に載せたのが元絵だけど)up。
d_126.jpg

塗り始めたのは数日前なのだけども、なんだかだらだらと数日かかってしまったりで。

大抵は塗り始めたら塗り終わりまで一気に終わらせることがほとんどで、分かれてもせいぜい2回目には塗り終わってることがほとんどだったのだけども。
一枚の絵に3日も4日もまたぐのは、ほとんど無かったんだけどなぁ。
まあ、モチベーション切れてるの判ってるときに無理に進めてもしょうがないかなというところもあったりで。

あとはここ最近の、PGとお絵かき半々ずつぐらいの時間の使い方というのも影響の一つか。PGやったあとに塗り作業て、普通にPGでそこそこ肩凝ったり疲労それなりの所からスタートなので。
お絵かきオンリーのときとはまた違った疲労箇所だと言うところも影響あるのかな。結果的に複合的な疲労に感じて、余計きつく感じるのかも。
なにげに、やっぱお絵かきって肉体労働なんだなあとか再認識。

でも、とくに〆切りがあるわけでもない、サイト用の絵の場合なら、こんなペースもありなのかなと言う気も。

折しもサイトはほとんど開店休業中なポンコツ具合だし、まったりペースでいいかなーと。昔みたいに一日一枚とか粗製濫造になってまでせっせとアップするのもどうかとおもうし。


そんなこんなで、久方ぶりのご意見箱~

「落書きの深夜のお散歩がなつかしい、あれからもう11年ほど経ちますか」

10年の月日……なんか遠い目になっちゃいますね。
涼しくなってきたらまた深夜のお散歩行かないとな。最近またちょっと運動不足気味なので。

てかペテルギウスの爆発、そろそろとか言われてるけど、どうなんだろうなぁ。
爆発すると、日中でも見える最低でも満月ぐらいの明るさで見えるようになるんだとか。

田舎の一級河川の近くの民家の少ないたんぼ道を歩く様にしてるのですが、(住宅密集地だとそのうち通報とかされそうだしw)それでも、やっぱ深夜でも街頭とか街の明かりで、月明かりのない日でもそれほど真っ暗闇というわけでもなく、そこそこ明るかったりするのですが、ペテルギウス爆発したら、夜の闇も払拭されてしまうのかなーとおもうと、ちょっと寂しい。

それが数週間から数ヶ月続くらしいので、きっと初見は稀なる天体ショーということで喜ぶけど数日すれば飽きるわなw
てかほんとに地球に影響ないのかね……。


2016-09

13

03:25:14

あいかわらず糞だな

win10強制アップグレードウィルスはもう入らないということで、久しぶりにwinアップデートなんかを。

……予想はしてたけど……10時間待っても更新のチェックが終わらないw

寝る前に本読みながら2時間ぐらい待って。こりゃダメだな。でもまあ、さすがに起きた頃には。と放置してみたけど変わらずで。
この辺のは、入れる順番とかでもトラブル起きたりするので、出来れば自動で一気に済ませたいところだったのですが。

win10強制アプグレ関係で見てたページに、この辺の更新待ち時間が最近飛躍的に伸びたという記事があって、回避方法とかもいろいろ載ってたのだけども、2~4時間待ちぐらいならまあ、寝てる間に終わるかなとおもってたのですが、こりゃだめだわと。

しかし対策記事みてると、2~4時間が対策すると数分に短縮とか、もとのアプグレパッチ作ったアホは何考えて作ったんでしょうね……。MSは影の政府と結びついていて、ウィンドウズを使った作業の生産性を下げて人類全体の進化を妨げてるとかいう陰謀論コピペとか昔あったなぁw

で、先に入れておいたほうが良いパッチ先に手動でインスコ。

……結果変わらず。

win10強制アプグレ関連パッチ混入の最新WinUndateクライアントも入れてみる。
(8月になった今ではwin10強制アプグレ関連入れても問題ない……よね?)

……したら5分で更新80件見つかりましたの文字が。

……10時間まっても終わらないのが今度は5分……

ほんとあほらしい。

結局、一番の問題はWUクライアントのverのようですね……。
が、新しいverは強制win10アプグレパッチと抱き合わせという糞っぷりなので、今まで入れられなかったんですよね。
が、それ入れないと更新チェックが一生終わらないんじゃないかってかんじで終わらなくなるという。

ほんと酷い……。



で、待ってる間に、伊藤計劃・著「虐殺器官」読了。
ていうか、これ既読だった……。

が、なんとなくもう一回読むことに。夭折した氏の本通し読みのつもりだったので。
といいつつ、「ハーモニー」だけまだ手に入ってないんですよね。予約いれてたのだけども、図書館の蔵書では貸し出し可になって一冊あるはずなのに、本自体が行方不明で、当日、司書の人にも探してもらうも見つからずで、まだ手元に無かったりで。

たまにあるんだよなそういうの……。なぜか二冊しかない本が、データ上では蔵書数三冊になってるんだけど、貸し出し中が一冊、貸し出し可が2冊。で、おいら予約。でも本が無い。
実際は一冊は貸し出し中で一冊は行方不明で、もう一冊はそもそも存在しない。そもそも蔵書数は2冊の本だという訳のわからない感じになってた事もあったり。ダン・ブラウンのロスト・シンボルだったかインフェルノだったか。

いくら昔の、みんな紙で管理してたころからデータ化したとはいえ、やっぱ、結局扱うのが物理的な本で、基本手渡しのやりとりだから、そういう人為的なミスが起るわな……。

そんな感じで人為的ミス(MSのは人為的ミスどころかテロですね)に泣かされた週末でした。

堂場舜一・著「バビロンの秘文字」全三巻、「内通者」読了。

バビロンの秘文字のほうは、まるで海外の作家さんが書いたかのような作品。ジャンル的には、冒険小説になるのかな。近いのでいえばダビンチコードとかあのへん。

多分架空の、ラガーン人というバビロンの末裔という民族が出てくるのですが。

なにげにその端緒の歴史の部分が、バビロンに住んでいた頃、山から蛮族が攻めてきて、故郷を追われその後流浪の民となる。みたいな話なのですが、その侵略してきた蛮族というのが後のサルゴン王だったりして。
ちょうど、高橋克彦の「新・竜の柩」のなかで、大昔にタイムスリップした登場人物達が現地で出会う重要人物がシャルケヌ=後のサルゴン王で、バビロンをこの後攻めるぜ、したらなっ! って感じで別れてるんですよねw

全然なんのつながりもなく、つい最近読んだ本でこんな変なリンクしてて、不思議な感じ。

なので、変にバビロン関係の予備知識があったおかげで、いろいろとわかりやすかったかも。

あとは、舞台がスエーデンのストックホルムなんですが、たまたま某氏がkanonの二次創作の小説で、祐一の親がストックホルムにいるという設定の話を書いてて。
そんでもって、「バビロンの秘文字」の主人公の恋人の名前が「里香」なのですが、某氏の小説とkanonつながりで、どうしても出てくるたびに「香里」と読み間違えて、最後までずっと、香里…・・じゃない里香だ……と毎回修正しながら読んでたっけ。

あとは、全三巻のうち、最初二巻までしかなくて、そのあと三巻あるかなと図書館の蔵書検索してみたときに目についたのですが、著者の堂場舜一さん、著作が100冊越えた記念てきなエッセイ集? というのが検索ででてきて。
執筆ペースの速い多作な作家さんではあるのだけど、100冊の大台のってたのかーと。

せいぜいそのうち半分ぐらいしか読んでないかも。
結構、ハードカバーでなく、文庫本のみのシリーズが結構あるらしいので、そっちの方はほとんど手つかずなんですよね。
刑事鳴沢シリーズは文庫でなんとか全部集めて読んだけど。そいや刑事鳴沢シリーズ最後らへんは、新潟県警の刑事の話だったはずが、ハリウッド映画かってな展開になっててワロタ。なにげにバビロンの秘文字の展開も、海外物の大作映画っぽい展開だったな。

文庫シリーズでは失踪課シリーズとかも読んでみたいんですけど、なかなか一度手を出すのなら最後まで……となると、なかなか踏ん切りが。刑事鳴沢シリーズも全部そろうまで結構長い時間掛かったしな・・・。


で、次は……図書館のサイトみてて、いろいろチェックしてると、伊藤計劃の本が貸し出し可になってる。もう何年も見るたびに予約ついてたりしてたりして。いままでは他にも借りる予定の本があったのでそのうちと思ってたけど良いタイミングなので借りてみることに。

……てか、この作者さん、お亡くなりになってたのですね……。

最近そういうの多くてぐんにょり。

2016-09

10

00:15:51

そういう時節なのか

d_125.jpg

実際に運用してみて、なかなか便利に使えてる感じの書庫内ファイル弄るソフト。運用上気づいた事をちまちまフィードバックする感じでちょこちょこ弄る。

しかし、圧縮ファイルの解凍も組み込んだところで、UnifyZipの有用性が薄くなってきてたりで。UnifyZipは圧縮された書庫を非圧縮にしつつ、あとはフィルタリングや余計なフォルダ除去とかもやってくれるのだけど、圧縮書庫のまま圧縮ファイルを個別解凍→リサイズ等の変更→非圧縮で保存。というのが出来る用になったので、一旦UnifyZipで無圧縮書庫にするというプロセスが不要気味に。

あと、ちょっと前に、HDDんなかにある書庫ファイル適当に放り込んでテストしてみたところ、読めないzipファイルがあったと言う件。
調査してみると、なんともしょうもない結果に。

zip書庫読み込みの際に詳細モードというのを用意していて、zipファイルのヘッダ情報をログりながら読み込むモードがあるのだけど、それで読んでみると、Local file headerとCentral directory headerの重複部分が不一致なフィールドがあるエラーの模様。
zipファイルの仕様上は重複部分が一致していなければならない物なのですが。
一致していないCentral directory headerの中身を見ると、なんとなく重複部分の値は不定値が入ってるっぽい。初期化前の変数をぶっ込んだ感じの。
つまるところ、この書庫を作成したツールがLocal file headerはちゃんと書いたけど、Central directory headerの重複部分は、すでにLocal file headerにあるからええやんと、サイズだけあわせて適当に書き出してるという、お行儀の悪いファイルだったというオチぽ。

Explzhとか、マンガミーヤなどのビューワでは読めたりするので、これらのソフトはヘッダの重複チェックを行っていない=読めれば良いんだよ的なアプローチのソフトなのだなと(ビューワ系は性質上そうなるのが普通か……)
とりあえずExplzhで修復かけてみたら普通に読める用に。

しかしまあ、未だにすっきりしないのだけど、この重複部分というか、ヘッダが1ファイルに対して二つあるっていう仕様、歴史的経緯とはいえ、必要か? というところであいかわらずなんだかモヤモヤするw


後は時事ネタ。

こち亀終了
タモリ引退(をほのめかす)

こち亀200巻で完結だそうな。
タモリ引退もまあ、そういう年だよなと。最近では唯一チェックしてるテレビ番組でもあるタモリ倶楽部でも、急に老け込んだ印象あったし。

自分の年齢的に、子供の頃とかに活躍してた人が、そういう年代にさしかかる時期に来てるんだよなーとおおもうと、自分もそれなりに年を食ったなぁとか。


後最近、ジャッキー&クリス・タッカーの映画、ラッシュアワーのドラマ版てのをやってるの知って、見てみることに。

……なんか主演のコンビが、まったく華がない……。
これはどうなのかねとおもってたのだけど、東洋人刑事の方は相変わらず微妙のままですが、黒人刑事の方はなんとなくだんだん良く感じてきて、結構楽しんで見てたのだけど、第一シーズンで打ち切り決定してるとか……。

コンスタンティンもそうだったけど、最初は微妙かなとおもってたけど、見てるうちにちょっと面白くなって来たかな? と思ったところで打ち切りのパターンか……。

ラッシュアワーはジャッキー&クリスタッカー。コンスタンティンはキアヌ・リーブスだもんな。元の映画版のキャストが大物すぎて、ほぼ無名のひとが同じ役所やると、最初はやっぱ微妙な感じになるんだよなぁ。

でもラッシュアワーの方の黒人刑事の人は、クリスタッカーよりは、エディーマーフィータイプよりで、結構良い味でてると感じてきたりで。

キアヌといえば、ビルとテッドの三作目の話はどうなったのかな。
今年の3月ぐらいにちょっと進展あったっぽいんだけど、そっから音沙汰無し。
ああいうお馬鹿映画大好きです。

2016-09

08

06:37:58

一度かたむくとなかなか

傾倒しすぎると、帰ってくるのに時間がかかるものですね。
そんな感じで、クールダウン的にpg。

d_124.jpg

こないだQTのウェブページ表示機能のお試しかねて作った、コミック発売日一覧サイトから、登録した作家名や書名で検索するツール。てな感じなのを、もうちょっとマシな感じに作り替えてみる。

以前のは、そもそも情報取得するサイトが、作家名が原作付とかの場合、両者の名前が載ってない。成年コミックも除外されてるっぽい。と、情報サイトの質的に微妙だったのに気づいたりで。なので別のところを使用することに。

それと、QTのウェブぺーじ表示機能。
以前にも書いたけど、デバッグビルドだと、すこぶる遅い。そんでもって、そもそも、用途的にページを表示する意味も無いよね。ってことで、ページ表示ウィジット削除。
あと、ページの読み込み待ちのあいだ、ダイアログで進捗表示するように変更。……なぜか24%ぐらいで毎回止まって、しばらく待った後急に100%になるのは仕様なんでしょうかw
QWebEngineViewのloadProgressシグナル受け取ってプログレスバーに値渡してるだけなので、どうも、ロードプロセスと、表示までの間? の時間はノーカンぽいのかな。ロードだけおわるのが24%なのか……? そしてデバッグビルドだと、その後がやたらと待たされるぽ。

でもまあ、実際に表示しない方が負荷も軽くて良い感じぽ。

あとはちまちまと、検索結果を日付でソートしたりとか、成年コミックは赤字で表示してみたりとか、こまごまとした機能をつけたりして、とりあえず完成ぽ。

まあ、サイトのhtml取得して自前でタグ解析→リスト化の流れなので
サイトのhtmlの構造が変わったらまた、解析部分書き直しっていう感じのアレなので、自分用のツールですね……。

でもこれで、毎月漏れなくチェックするのとか地味に面倒だったのが自動化されてすっきりぽ。

しかし、やっぱ大洋社の発売日リストが一番見やすかったなぁ。
倒産直前ぐらいに、発売日リストは別の場所で継続みたいなことが公式ツイッタあったけど、音沙汰無いなぁ……。

相も変わらずPG。そろそろお絵かきもやらないとな。

今日は、やはり欲しい。zip内ファイルの個別解凍機能。
ってことで一度は挫折したこの件を再調査してみたり。

とりあえず、基本的にはzip書庫の圧縮にはデフレート圧縮が使われている。それは良いんだけども、なんかいろいろこれも種類があるらしく。
書庫ファイル内からバイナリで圧縮ファイルのデータをもってきて、それを解凍するだけなのだけど、これが良い手段が見つからない。

まず、解凍をどうやるのかさっぱり。辞書+ハフマン方式だとか、こんなん1から自前で解凍出来るようなものを作るのは骨が折れそうで。

しかし、メジャーどころのライブラリなんかでは、書庫ファイル自体を読み込んで、独自のハンドル操作やら、ファイルを検索する機構とセットで解凍機能がついてるんですよね。
そんでもって、出力は大抵ファイル。

メモリ上の圧縮データをメモリバッファに解凍。というのが欲しいのだけども。

なので、解凍ルーチンだけが欲しいんだけどなぁ。

で、いろいろ探していると、1ファイルで完結してるという、「miniz.c」なる物を発見。

uncompress( buffer, &buffer_size, src_memory, src_size );

おお、こういうのが欲しかったっ。

やっと見つけたーと、試してみると、解凍に失敗のエラーが。
デバッガで追ってみると、なんかソースと出力先のバッファサイズ回りでなんかエラーが起きてるっぽい。

んー。圧縮ファイルと解凍後のファイルのサイズなんか間違いようもないし……。
なんど見返してもうまく動かん~。


したらこんな記事が。

データ圧縮 zlib と gzip と zip (zlib で zip にアクセスする)
ttp://wlog.flatlib.jp/item/1653


どうも、miniz.cのuncompressは、zlib形式の解凍に使うものらしい。

で、zlibと、zip書庫内ファイルの違いといえば……圧縮形式は同じ? なのだけどもzlibには独自のヘッダが付加されているんだそうな。

書庫内zipファイルは、圧縮ファイルのサイズだとか圧縮方式だとかは、zipファイルのファイルヘッダとして別個にもっていて、圧縮ファイルはヘッダ無しのベタファイルになるようです。

そんで、uncompressの内部で行われているinflateInitをinflateInit2に変えて、 windowBitsに「-MZ_DEFAULT_WINDOW_BITS」を与えてやると、ヘッダ無しの生データ(raw)として解凍されるとのこと。

で、その辺修正した自前のuncompress関数にぶっ込んでみると。

解凍出来たー!

最初のはzlibのヘッダ分でバッファのサイズが狂ってたのね……。

てかzlibとかgzipとかややこしぃ……。

d_123.jpg

そんな感じで、圧縮書庫内ファイルの画像もプレビュー出来るように。

んー意外に展開速いな。画像一枚単位だからだろうか。ファイルアクセスの速度のがよっぽど問題なのか、あんまし展開速度に非圧縮と差が感じられない。
とはいえさすがに画像のヘッダ情報も読み込むのは、全ファイル解凍と同じで数個のファイルでのテストとは違って、実際の運用では重たくなりそうなので、やっぱ圧縮ファイルはファイル選択時のみ個別解凍でプレビュー表示のみ……というのが妥当か。

あとはこのバージョンでは、unzip32も7-Zipなどの統合アーカイバ系は使わない形に。結局全部バイナリから自前で読んだ方が速いし融通きくなと。windows.hもインクルードしなくて済むし。ああすっきり。

そんでもって、編集設定画面を別画面に移したので、画像プレビューも大きくなったり。やっぱ画像プレビュー画面は大きい方がいいな。


しかし……「miniz.c」……これ拡張子がcになってる通り、C言語ベースなんですよね。しかもソースファイルだし。なんでhじゃないんだ……。

そんでもって中身はdefineもりもり、マクロもりもり。目からゲボがでそう……。

あと、一応zip書庫内の解凍にも対応してるようなのですが、こちらは統合アーカイバ系とちがい、何番目のファイルか指定して解凍する形ぽ。
なので、一旦リスト化して、あとはインデックスで解凍するファイルを選択する形っぽい。
ファイル名で毎度検索するっぽい統合アーカイバ系よりはマシな作りの気もするのだけど、最初からファイル名判ってて解凍したいときは結局走査がいるので、使い勝手はあまり良くないぽですね。(すでに別手段でリストを取得後の状態で解凍なんてときに、結局再捜査がいるぽなので。インデックス番号がどういう順番のルールなのかもわからないし)

そんなこんなで220kbぐらいあったcソースコードから、圧縮もつかわなーいってことで、zipファイル関係と圧縮関係のコードをばっさり削って、さらにソースではなくヘッダファイルに変更。

んでも100kbぐらいある……。

そんでもって、できればクラスライブラリ化したかったのだけども、C言語ベースのポインタうんこもりのコードなので、とても触る気にもならず……。
単にラップするのでは意味ないし(defineマクロ系を排除が一番の目的なので)結局ヘッダ化したところで妥協。

そんでテスト用プロジェクトで動作確認後、本チャンのプロジェクトに組み込む。

#define crc32 mz_crc32

うぉいキミぃ。

こんな定義の所為で自前のcrc32関係のコードが誤爆を受ける……。

define定義による名前空間汚染事故は結局起るのか……せっかくwindows.h排除したのに……。

ていうか他にももりもり小文字オンリーのdefine定義があったりして、止めてぇ……ってかんじぽ。

やっぱC言語って邪悪だわ……。

2016-09

02

00:35:58

コピペばかりは飽きる

いまだにちんたらやってるPG。
1から綺麗に書き直ししてるのだけども、基本的にはコピペがおおいので、あんまし創造的な作業じゃないので、しばらく続くと飽きる。
綺麗にいろいろ雑だったものが綺麗に収まっていくという所は気持ちいい作業ではあるのだけども。
そして良くやる、ヘッダの循環参照系の罠にはまる。てか、QTのそっち系のエラーって、全く方向性が違うエラーメッセージでるので、それが原因だと気づきにくくてシンドイ。clangコードモデルつかってたらそうでもないんだろうけども。clangコードモデルはエラーメッセージがわかりやすいのも評判の一つだし。
でも相変わらずうちの環境が悪いのかハングるので使えないしw

そんなこんなで、月が変わったところで、毎月やってる、今月発売の漫画のチェックなんぞを。

しかし、毎月のこととはいえ、正直めんどい。
発売リストのっけてるサイトにいって、上から順番にじーっとみて、気になったのをメモ帳にこぴぺ。

自動化したいところですね。
ブラウザ上だと、複数の検索ワードで一気に検索とか出来ないのですよね。火狐のアドオンなんかでもそういう感じのないっぽいですね。

たとえば、作家名をだーっと登録して、作家名全部で発売リストページ内検索して、見つかったテーブルの行を取得してリストとして受け取れる。

そういうのが欲しいなぁとか。

そういえば、QTでも最近web関係の機能結構増えてるんだっけか。簡単な表示するだけのブラウザなら数行で出来ちゃうよみたいな記事読んだぽ。

d_122.jpg

……とりあえずさくっと作ってみたり。
確かにweb表示までは簡単なんですが、なんか変な警告常に出るし(vc++ビルドだからなのか判らないケド、web描画系回りのなにかっぽい警告)いまいち信頼性に欠ける感じぽ。
あとデバッグビルドだと表示も動作も糞おっそい。

リリースビルドでもこんなだったらどうしようかと思ったけど、そっちではさくさく動いたので良かったですけど。

そんでもって、なんかQT5.7で結構変わってるというか、ここ最近のverで毎度変更あるかんじのまだふにゃふにゃな機能っぽくて、ググったサイトの情報がちょっとでも古いともう使えないってかんじで困ったり。

てか、5.6ではページ内の要素を検索とか機能あったのが消されてる・・…。5.7のドキュメントみると、jQuery使ってのjavascriptでその辺の事をやてったりして。
かなりいろんな機能が削られてるのはc++でゴリゴリ書くのじゃなく、web関係はjavascriptに任せちゃおうよな方向性なのかな??

でも個人的にはjQueryとかうっとおしいだけなので触りたくないんだけどなぁ。

そんな感じで、結局toHtml()でhtmlのテキストを受け取って、自前で解析する方向にw

とりあえずその辺の発売日リストのサイト開いてだーっと解析して一旦、発売日、書名、著者名、レーベル名のテーブルを作成。
その後、登録した著者名や作品名で検索してヒットした物をテキストで出力表示(右上んところ)と言った感じのものが出来~。


まあ、サイトの解析の都合上、このサイトと決めたらそのサイトに合わせた解析部を書く事になる感じなので汎用性はないなぁ(そのサイトがにリニューアルしたらまた書き直しw)あと、デバッグビルドだと糞遅くて、スタイルシートとかバリバリなサイトだと、表示に時間掛かってうっとおしいので、なるべくプレーンなサイトを探したりもしたんだけど、今度はプレーンすぎると解析時に、どこからデータが始まるのかというキーになるところを指定するのが厄介になったりして。そのへんのさじ加減も難しい。

あとは……予感はしてたんですが、リリースビルド後、必要なランタイムとかを自動でexeのあるフォルダにコピーしてくれるQTのツール実行後、容量見てみたら……exe本体は110KBだったのですが……。

ランタイムの総量100MB超。

1000倍だー!!(野沢雅子調)

さすがにブラウザてのはいろいろとランタイムいるんだなぁ……こりゃぜんっぜん配布に向かないレベルの代物ですねw
本体のみなら100KBぐらいなのにランタイム込みだと100MB越えじゃあぁなぁ。

このソフト自体は、発売日リストのサイトが改変されたら即修正必要な感じだったりと、ソースちまちま弄りながらじゃないと使えないような代物なのでアレですけど。
それでも、exeの100KBのみで実行出来るのなら、ジャンク物って感じで配布とか気軽に出来るんですけどね。


てか、QTのweb関係どうかなーというお試しで作ってみた感じなのですが……用途的には単純にサイトのソース表示→すべて選択→ペースト→解析っていうかんじで、web機能使わないでただのテキストベースの解析ソフトにした方がまだマシな気がしますねw

そんな感じでちょい脱線とかしてたりする昨今。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
コピペばかりは飽きる
03
やはりC言語は邪悪だ……
04
05
06
07
08
一度かたむくとなかなか
09
10
そういう時節なのか
11
大分夜は涼しくなってきた
12
13
あいかわらず糞だな
14
気力の問題
15
16
17
18
19
[敬老の日]
20
21
22
[秋分の日]
23
24
25
26
27
28
29
30
total:2080398 t:2768 y:180
■記事タイトル■

■年度別リスト■
2024年 2024年12月(0)
2024年11月(0)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年 2023年12月(3)
2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年 2022年12月(4)
2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年 2021年12月(8)
2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年 2020年12月(3)
2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年 2019年12月(1)
2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年 2018年12月(1)
2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年 2017年12月(2)
2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年 2016年12月(7)
2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年 2015年12月(7)
2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年 2014年12月(12)
2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年 2013年12月(15)
2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)

■レス履歴■

2023-09-26 14:59:38 - 久慈光樹

2023-09-26 14:29:10 - 織田霧さくら

2023-09-26 13:10:45 - 久慈光樹

2023-03-20 05:30:16 - 織田霧さくら

2023-03-15 20:42:58 - まうる

2022-12-26 19:14:57 - 織田霧さくら

2022-12-25 02:28:36 - まうる@まるるん

2022-09-30 04:29:01 - 織田霧さくら

2022-09-23 19:01:29 - まるるん

2022-06-16 21:06:34 - 山本


■ファイル抽出■

■ワード検索■

堕天使の煉獄

https://rengoku.sakura.ne.jp
管理人

織田霧さくら(oda-x)

E-mail (■を@に)

oda-x■rengoku.sakura.ne.jp

堕天使の煉獄バナー 堕天使の煉獄バナー