total:56395 t:12 y:41
2019-02 煉獄日記
煉獄日記
管理人:織田霧さくら(oda-x)
2019年02月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28
タイトル一覧
月別一覧
年度別一覧
検索
2019-02-16.Sat 一旦立ち止まると
2019/02/16(Sat) 04:45:12
トルクが全く無いんですかねこのエンジン。
ちゃんと走ってるときは割とガンガン進むんですが、一旦何かにぶつかって低速になるとエンストして。その後ちっともエンジンが掛かりやしない。

そんな感じの今週一週間。

風邪かな? と大事を取って寝るを数日繰り返してたら、もう大丈夫っぽい? って感じになってから全く何も手に付かなくなっちゃったりで。一度立ち止まると駄目だな……。

未来少年コナン全話見たりとか、アニメのからくりサーカス、しょうがないのかもしれないけど端折りすぎだよなーからの懐かしさから原作全43巻一気読みとかやり出したりして。なにやってんのって感じに我に返ったのが昨日あたり(ぉ

なにげにコナンって、ギガント乗り込むシーンあたりだけは何度も見たことあるんですが、一話からちゃんと見たことなかったりして。
小さい頃に夏休みスペシャルみたいな感じで再放送やってるようなときも、気づいたときにはこのギガントのシーンあたりの回で、最初から見る機会に出会えなかったんですよね。
うーん。色んなその後の宮崎作品の原型が散らばってる感じで、もっと早くに見るべきだったなとおもたり。


あといろいろ小ネタ。

なにかのゲーム画面かなにかのサムネで、3Dモデルの部屋があって。なんかレンダリングの感じがVidroっぽいなーとか思ったときに、そいや最近新しいverとかチェックしてなかったなと見にいったらば。

Vidro
ttps://ja.wikipedia.org/wiki/Vidro

2010年7月、開発者の徳吉雄介はスクウェア・エニックスへと転職し[3]、vidroの開発は第100630版(2010年6月30日)で終了した。


開発終了してたのか。そしてスクエニに就職されてたのか開発者の方。
んで、手元にあるvidroのver確認したら100630版でしたw
普通に最新版まではちゃんと取得してたんやね。
ちょっとググればまだ普通にDLできるところもあったので、手に入らない~ってわけでもなさそうっぽい。現時点では。
でも一応最終版はバックアップしておこうかなとおもたり。
フリーのレンダラでは使いやすいし綺麗なので。あとメタセコと親和性高いので。

んでももう10年近く前の話なのか……ここ最近3D関係さわってないものなぁ。

次~

更新が途絶えていた「FFFTP」の開発に後継者、v3.0が“GitHub”で公開される
ttps://forest.watch.impress.co.jp/docs/news/1115458.html

ぼちぼち最近の話ですが。
FFFTPの開発引き継ぎ版が出てすぐぐらいまでは私も使ってたのソフトだったのだけども。なんか妙に動作が重くなってストレス溜まる感じになっちゃったので以降はFileZillaを使ってたりする。

 今回開発を受け継いだKURATA Sayuri氏は、“艦これ”専用ブラウザー「艦これ 司令部室」の開発などで知られている。


このKURATA Sayuri氏って、結構c++界隈のフォーラムとか掲示板とかでKanonのさゆりんのアイコンでよく見かけるひといるなぁって思ってたのですが、ずばりその人だったのでちょっと「おおっあの人か」って思っただけの話ですw

てかまあ、今年でKanon20周年だったりするんですが。
今時の若い人にはもうKanonとか知らんだろうな~とか思ったりしてたところで何となくタイムリーなネタだったので。

んで、なんでこの「FFFTP」の開発に後継者の記事にたどり着いたかと言えば、ちょっと前にOpenSSL関係でちょっと調べてたときに、この記事のなかの

「OpenSSL」や「JRE32.DLL」といった外部ライブラリへの依存が削除され、Windowsに付属するライブラリを利用するようになっている。


って部分で「おや?」と思ってぐーぐるの検索結果から記事を開いたところだったりする。
OpenSSL使わない方向でhttps対応とかできる他の方法が? と気になったもので。
んまあその後いろいろ調べを進めてみたところ

素直になれない人のwindows SSL
ttp://d.hatena.ne.jp/rti7743/20130216/1360968993
windowsのcrypt32 secure32とかの使い方が複雑すぎて人間が理解できないぐらいになっているのです。

記事のコメント欄に
Win32 APIにSSL機能があるのでWindowsプログラミングでOpenSSLは本来不要。だが誰も使いこなせないので結局OpenSSL、という話。サンプルソースを読むと(主に行数で)なるほど使いこなせないと理解できる


うん。素直にOpenSSL使った方がいいねっ!
ほんと7zipの中のMS謹製のvariant型みたいなのもそうだったけど、MSさんのライブラリの仕様とか変数名のセンスとか古い以前にいろいろひどくて読む気にすらならないもの大杉ぃ。
「だが誰も使いこなせないので」のくだりでワロタw

QT使う場合はちゃんとそっちでOpenSSL対応してくれてるので、あえて他の方法を使うメリットはなさそうぽ。

んまあ外部ライブラリへの依存関係を減らしたいのは山々なんですけどね……。

そんな感じで、ようやく再起動中。
2019-02-08.Fri O・KA・N
2019/02/08(Fri) 04:41:03
悪寒です。おかん(母親)ではないですw

なんでこうやる気になった途端にこうなるのか。いや急にローギアからトップギアに入れる感じにやる気になったから、体力低下してこうなったのか。
そいや先日は妙に暖かかったんですが、その翌日に朝方雨とか天気悪くなったらまた一気に冷え込んだので、その急な寒暖の所為かな……。

なんか風邪の初期症状っぽい悪寒が。
一旦布団入っても、ガタガタブルブル。まずい……。

ってことで昨日はさっさと寝ることにしたので、作業は殆ど捗らず。

とりあえずやったのは、書庫ファイル名受け取ったら、7z.dll使用と自前処理用(zip専用)に切り分けるためのインターフェース作って、7z.dll利用版と自前処理の関数をオーバライド出来る様に7z.dll利用版の方のクラスを整えたりしたぐらい。
あとは以前組んだzip関係のコード眺めて、「うわぁ」となったり(ぉ
数年ぐらい前に組んだってのと、zipのフォーマット調べながら作ったので、微に入り細を穿つ感じで、これ使わんだろ? っていうフィールドまできっちりなんか処理してたりして。

その辺、今回はばっさりと必要な部分だけ取捨選択したら、処理もスマートかつ読み込み速度も稼げるようになるんじゃないかなと。

でついさっき起きて、とりあえず熱っぽくも無いようだし悪寒も収まった感じで。頭はぼーっとするのは寝過ぎかな。途中でちょいちょい目が覚めて、あ、携帯メールきてるーとかごそごそ起き出して、また寝たりと。あれは夢かな? といま見たらちゃんとメール返信してるみたいなので、現実だったかと確認。

んで特に症状出てない感じなので追い打ちであっついお風呂に浸かることに。
なんか余計に頭はぼーっとするようになったけどw

最近は本格的に風邪をひくと一週間ぐらい寝込む事おおくなったので、なるべくならひき初めの段階でさっさと直してしまいたい感じなんですよね。

そんな感じで、しばらくはなんかまた調子が……とおもったら即ベッドインてなかんじの様子見運用で。
2019-02-06.Wed なんだか暖かい
2019/02/06(Wed) 05:36:05
ここ数日、昼間は妙に暖かいですね。
でも夜は普通に冷えるのでこの寒暖は気をつけないと風邪ひいたりするので注意しないとな。

さて、昨日はfirefoxの面倒なレイアウト改変更新あって、それに時間取られたりしてあんまり作業進まず。あと病院にいったりもしてたので。
7z.dll利用ライブラリのエラーハンドリング周りまた弄ったり、利用側とどっちが何処まで処理するのかとか、データ構造はどっちが用意するのかとか設計的な事をぼちぼち考えてる間に終わってしまったり。

あとGyaoでフィフス・エレメントやってたので見てしまったし(ぉ

てか吹き替え版しかみたことなかったので、字幕版で初見(だったとおもう)。

最近はめっきり字幕版でしか見たくない。吹き替え版しかない場合、その映画自体見ないってぐらい吹き替え版嫌いなのですが。
しかしフィフス・エレメント。吹き替え版のクオリティすごく高かったんだなと。クリス・タッカーのラジオ番組? のDJっぷりは、むしろ吹き替えのほうがノリもテンポもハイテンションな感じが出てて良かったし。
他のキャラも、まさに「吹き替え」といったかんじで、雰囲気、声質までにかよってるし。もとの俳優さんの演技をトレースするような演技してるようなフィットぶり。

吹き替え版が嫌いになった理由は、なんか最近、もとの俳優さんの演技そっちのけの画一的な演技しか出来ない声優さんと、下手くそな俳優とかお笑い芸人起用とかで、映画自体を台無いしにされることが多い所為なのですが。
あと最近のは頓に声と俳優のキャラが合ってないと感じるキャスティングおおいし。もとの映画と俳優さんへのリスペクトが全くないのとちがうかと。

わりと昔の映画は吹き替えもしっかり作られてるんだよなと。
最近のがおかしすぎるんだよなと再確認。

そいやビルとテッドも吹き替えの方が初見でその後字幕版も見たけど、そっちも良い感じだったな。
なんか若者言葉というかブロークンな英語でしゃべってるみたいな話はきいてたのだけども、なるほどこれがああなるのかって感じで雰囲気でててこれも良い吹き替えだったなと。
ちな、そもそもそんな英語できるわけではないのですが、所々なんていってるのか全く判らない。日本語なら津軽弁レベルだろってぐらい発音がくだけすぎててわからないw 英語の方言とかてのを初めて意識したのもこの作品だった気がする。

初見はなんとなくつけてたテレビで途中から見たのですが(二作目の地獄旅行の方)お、なんかこれ面白そうだぞ? と途中からだったものの録画ボタンを押し(まだVHSの時代です)最初に食いついたのはメガデスが流れて来たからだけど(メガデスとか色んなメタルバンドの音楽が提供されてる)その後もちょいちょいみてて、そのうち完全版ちゃんとみたいなー。でも日本ではマイナーっぽいからレンタルとかあるんかなー
したらその後、当時はそれが二作目だというのもしらず一作目があるのを知って。その後ネット時代がやってきて情報を集めやすくなると、海外ではアニメ版が制作されるぐらい結構ヒット作だったらしいことも知ったりで。
あと初見時はテッドがキアヌだとは知らない(ビルトテッドは1989年、二作目が1991年、出世作のスピードが1994年)で見てたんだよな。

んで、TVで見てた時に、TVの映画ではごくたまにそういう演出されることあったけど、CM前にアイキャッチが入るんですよね。
「またあとでね~♪」て言ってビルとテッドがてを振ってるの。
あれってもとの英語版でも「catch you later」っていっててそのまんまだったんだなとw
しばらく「またあとでね~♪」のフレーズが頭に残り続けてたっけ。

ビルトデット三作目ほぼ本決まりらしいので今から楽しみにしている一本です。

2019-02-05.Tue めんどくせぇなもう……
2019/02/05(Tue) 06:08:27
firefoxの更新きてたので更新かけたらば……。
まーたタブが一番上に移動してやがる……。

いい加減、勝手にレイアウト変更するような更新止めて欲しいわ……。
んでググってみると案の定、firefox65でタブを下にしたいんですけど的な記事がぽこぽこ。
いい加減、タブを下にしたい層が一定数要るって事を認識して、設定一つで位置変更出来る様にしてほしいわ。なんで執拗にタブを上にしたがるのか……。
てか今回の場合は、メニューバー周りのレイアウトを新しいCSSの機能に置き換えたみたいで、firefox58ぐらいだったか? からuserChrome.cssでタブを下に移動させてたのだけども、その辺書き直さないと行けない感じらしい。

てか更新の度にこんなんやらされるのめんどくさすぎだろ……。
なんかfirefoxって、バージョン番号急にあげ始めたあたりからおかしくなったよな。破壊的な変更最近多いし。
とはいえいくつかのアドオンが便利すぎて代替はなかったりするので……。

てか新しくなったcssのレイアウト方式っつっても、普通にそんな日本語の解説ページなんかないし、まずどう変わったのかとかから調べるのだけでうんざりですわ。
とりあえずいろいろやってるウチになんとかタブは下に下げれたんだけど、こんどは移動した分空白がのこってその空白が消えないw

個人的には

ツールバー(戻るボタンとか検索とかアドオンアイコンとか)
タブ

の二段のみでサイト表示部分は大きく取りたい派なのですよね。
メニューバーは最近のverでは「三」ボタンから大抵のことは出来る様になったので必要無いし。
なのにタブは下に行った物の

空白(もとのタブの幅サイズ分の)
ツールバー
タブ

の三段構成にw
こんなんいやや。
メニュー表示にチェック入れるとちゃんと空白部分にメニュー表示されるし。
この空白消したいんや。どうすればいいんやー。
ここがcssではなんて要素なのかもわからんし。ググっても英語ばっかりだしぃ。
ってのでしばらく悩む。

結論
#navigator-toolbox {margin-top: -24px !important}

無理矢理力業すぎるw

firefox65_fix_css.jpg

んで、無事すっきり二段構成に。もうこれでいいや。

てかそろそろデフォルトで再起動ボタンつけてくれないかねfirefoxさん……。
cssの更新で再起動するんだけど、再起動ボタンはアドオンの所にuserChrome.xmlで追加してるんですけど、cssの編集でミスってその辺全部非表示になったりとかすると、再起動ボタンが使えないw
そこで毎度、「再起動ボタン普通に要るだろ。標準でつけとけよ」となんども脳内にこだまするw

そんな感じで、こんなんで時間取られてファッキン。


書庫ファイルのなかの画像ファイル整理整頓編集ツール。

今回は、いままでc++で例外って全く使ってなかったのですが。
基本的にゲームPGでは例外は使わないですからね。c++1x以降はとにかくどこでもnoexcept指定。それでも例外出るようなケースは(標準ライブラリとか)即std::terminateでアプリ終了。
例外出るようなケースはゲームの続行不可能の場合が殆どなのでそれで問題ないですしね。
noexcept指定することで最適化されやすくなるので実行速度も稼げるし。

なのですが、外部のdllとか使う場合、その部分だけは例外使った方がいいんじゃないかなーと。

今回のだと、7z.dllをロードして、そこから書庫フォーマットにあわせたアクセス用のオブジェクトを取得して、そこにコールバックを設定して~
みたいな流れなのですが、その過程のエラーハンドリングのメッセージが、例外使わない場合は結構面倒だなーと。
グローバルなエラーメッセージ保持するの用意するのは、結構用意しても実際にはめんどくさくて無視しちゃうケース多いしw

さらには、7z.dll利用部分は静的ライブラリとして別プロジェクトに別けてるんですが、例外つかうにしても、このライブラリの中だけで完結した方がいいのか(ライブラリのなかでtry-catchする)ライブラリ利用側でやった方がいいのか。
そこいらへんで、ライブラリの設計として、7z.dllのロード部分を完璧に隠蔽して、内部でロードするクラスを用意するとしたら、そのクラスを作成する部分をtry-catchするのか、それともそのクラス内の7z.dllのロード部分をtry-catchして、そのクラス内でエラーハンドリングするのが良い設計なのか?

と、長らく例外というものをシカトし続けてたツケが……。
まったくどうやるのが定石なのかとか、設計として良いのかよくわからん~。

とりあえず、今更ながらこの辺の解説サイトみてみると、やはりc++においてはコストがアレなので、なるべく範囲をしぼって、さらには利用するのはその後アプリケーションが継続不可能なタイプのものにだけにするのが、面倒はおこりにくいっぽいてのが一応の結論か。

いまいち例外のコストていろんなサイトみてもよくわからない。
正常系ならコスト0とか言うけど、tryは遅いとか書かれてるところもあるし。
とりあえずループの中でtry-catchはやっちゃ行けないってのはわかるんだけども。

un7z::InArchive_ptr in = nullptr;
try {
in = un7z::InArchive::create(filePath, fm);
} catch (const un7z::Exception& ex){
qDebug() << ex.result();
return;
}
in->こっからなんかいろいろする

てのと

try {
auto in = un7z::InArchive::create(filePath, fm);
in->こっからなんかいろいろする  
} catch (const un7z::Exception& ex){
qDebug() << ex.result();
return;
}

で、try節の中でなにかの処理をずらずらとやるのって、そっちの場合てコストはどうなん? try節の外でやった方がええのん?
あとtry節のなかで、noexcept指定の関数呼んだときは、その関数は最適化から除外されずにコスト的に問題なくなるのか? とか。

知りたいところの情報がなかなか出てこなくて、いまいち世の中の多くの人もあんま例外って細かいところまで知らない人の方が大多数なんじゃないのかという気さえしてくるw

そんなかんじであんまわからんものは無闇に使う物じゃないなということで、多層的にエラーハンドリングが必要かつここで失敗したらもうその後の処理は何にも出来ないっていう7z.dllのロードまわりだけ例外を使う事に。

でもそうすることでまた、ライブラリの作り方的な方でもいろいろと考えることがでてきちゃったりで。
そんな感じで、設計自体見直しながら、このあたりをリライトしたり。

次回は、zip書庫だけは自前で処理する事にしたのでその部分を組む……てか以前組んだのを移植する作業に。

んでもこの部分を書庫関係用ライブラリとして7z.dll使用ライブラリと一纏めに追加しちゃった方がいいのか……。
でもこの辺、書庫内の画像ファイルのフォーマット解析とかもやるんですよね。画像フォーマットや画像サイズ(ピクセル数)色数とか。
そういった画像関係のコードもここに含めるのは違うなーと言う気もするし。
でもフォーマット解析だけなら一応範疇なのかな。書庫内ファイルの情報って意味では。

そこいらへんで、ライブラリ利用側とライブラリ側のどっちがどこまでやるのかってところの線引きも迷い出す~

2019-02-04.Mon 実験的に
2019/02/04(Mon) 05:29:23
更新頻度もやばくなってきてるので、ちょっと実験的なことをやってみようかなと。
今日やった作業の内容をここに書くって感じのを。

これだとサボって何もしてない日には、「サボってました」と書くハメになって自戒になるんじゃないかと。
あんま何もしてなさ過ぎるのもまずいと、作業も捗るかもしれん?

てな感じでスタート。

昨日はとりあえずアプリ開発環境の64bit化移行をしたのだけども、どうせそのうち使う事になるよなってことで、OpenSSLの64bit版を導入することに。

……あれ? 自前でビルドしなくてもインストーラあるじゃん。
でも自前ビルドの方法見てみると、見覚えのある手順。
あるぇー? そうかhaxeだったかなにかの環境作るのも同じ様な手順だったからそれで記憶が混同してたのかな。

んで、だんだん他にも思い出してくる。
そうだOpenSSLて現在、v1.0.2系とv1.1.x系の2種あって、v1.0.2がunix系ではデフォルトで使われてるのとLTS(長期サポート)だってことでこっちのが問題は起りにくいてきな。

んで、Qtの方が、Qt5.7ぐらいまではv1.1.x系はまだサポートされてない状況だったとかで。
今ググってみると、フォーラムの記事でQt5.11はv1.1.1サポートしてるよって誰かがかいてるんだけど……いまいちQT公式のサイトからは対応状況の記事がみつからず。
フォーラムではなんか1.1.x系つかってトラブル起ってる感じの記事がぼこぼこ出てくるんだよな。
5.8~5.10あたりの古いverだとサポートされてないからv1.0.2使うと良いよてきな記事ばかりがヒットしてるだけなのか……その辺みんな英語なのでいまいち確証が。

したらこんな記事も
「OpenSSL」のバージョンの付け方が変更 ~ライセンスは“Apache License 2.0”へ
ttps://forest.watch.impress.co.jp/docs/news/1155972.html

うーん。
どうもQt5.11移行はv1.1.1サポートしてる臭いんだけど、今度はver表記を3.0から新たに形式変えていくぜみたいな記事があったりして。
そうなるとv1.0.2系は2019年内までのLTSだったりするので、v1.1.x系いれたほうがいいのか。むーん。こういう過渡期にぶちあたると、どれを選択するべきか悩むぅ。

と悩んだあげくに、とりあえずいまのところそのまま置き換えるだけで動きそうなOpenSSLv1.0.2の64bit版を入れる事にする。

んで、漫画情報サイトからデータ拾ってきてリスト化するツールを64bitでリビルド~。
エラー。
SSL接続で転けてる~
普通にOpenSSLのdll(libeay32.dll ssleay32.dll)を実行ファイルのところにコピーし忘れてただけという凡ミス。
必要なファイルコピーして実行~
ちゃんと動いた~。

てかdllも64bit版なんだけどこっちもxxx32.dllと「32」の文字が付いてるのでややこしい。同じファイル名だけども中身は64bitだったりするので。
このへんなんとかならんかったのか。

てか大昔のwin3.1とかあの時代のころの、16bit→32bit移行あたりは、なーんにも気にも止めなかったうちに移行終了してた感じでしたけど、PCの一般化にともなって影響範囲の拡大からの、32bitをすぐに切れないかんじのぐだぐだ感w
まあ16bitとかあの頃って、そもosのbit数の影響を被るようなコードを書く人自体が極限られた専門家のみだったで状況もあるかな。
あの当時はそもそもコンパイラ自体も開発環境も今みたく無料で手に入らないわけだし。
しにても、32bit→64bitの移行ってそんなにスパッと移行しなかったですね。64bitOS出た頃はすぐに全部なんでも64bitに置き換わっちゃうものだとおもってたんですけどね。かつての16bit→32bitのように。
いまでも多くのアプリがまだ32bit版だったりするし。
そしてそれでも困らない、逆に困らない仕組み(WOW64)を用意してしまったせいで、いつまで経っても移行出来ない状況になっちゃったんですかね。
んでもアップルのios11以降は32bitアプリ切り捨てる方針とかも出てきてるし、遅まきながらもそういう流れにはなってきてるのかなとも。

64bit出てきた当時は、まだ2GB縛りに抵触するようなアプリも稀だし32bitでも十分どころかハードウェア的には64bitの方が負担大きいみたいな状況もあったしね。
今では32bitアプリで2GBの境界で引っかかるケースが普通にでてきたし。
たとえば書庫ファイル扱うツールでも、HDDの大容量化にともなって、書庫自体が2GB越えってケースも普通に出てくるようになったし。

んでもdllの見た目は32bitっぽいのに中身は64bitっていうのはちょっと厄介ですね。
7z.dllの32とかの表記無いけど、中身は32bitと64bitどっちもあり得るってのもこれまた厄介ですが。

簡単に判別できないってのもアレだな「dumpbin」コマンドで確認ぐらいしかないっぽいし。
そもそもDLLは開発者とかが用意するものなので、そもそも利用者側で混同するケースを考えなくても良いってので、必要性がないということなのか。
んでも開発者側が、これどっちやねんと困ってるんですがw

まあそういうものなんだろうといえば、そういうもの何でしょうけど……。

そんな感じでOpenSSL64bit導入完了。

2019-02-03.Sun もう二月
2019/02/03(Sun) 04:13:57
相変わらず月日流れるのはやすぎー

そして、いろいろと片付けたいことは山積しているのだけども、ちっとも片付かない。
てか、アウトレイジ1,2,3、龍三と七人の子分たち、JM、ホームアローン1,2にビバリーヒルズコップ1,2、それからなんかほかにも何本か……急に映画見るブームきてほげーっと見続けてしまったりと、あるいみ正月ボケ?

最初の切っ掛けは何だったろう……そうだ、ビルとテッド3の制作がいよいよ本決まりになったっぽい記事よんで、それからつべでJMの文字みかけて。昔TVでみたなー。記憶屋ジョニー。キアヌって関根勤ばりに歳くわねーなー。むしろ昔が老けてた? そいやビートたけしもでてたっけ。

ってとこから、そいやアウトレイジの最終章みてないな。
とおもったら間にもう一本「龍三と七人の子分たち」てのがあったのか。
てことでキアヌから北野武作品に流れ込む感じで。
「龍三と七人の子分たち」は面白かったけど、やっぱ893は893だよなーと。
んでもノリが初期作品っぽい感じで懐かしさもあったりして。

なにげに「その男凶暴につき」なんか久しぶりにまた見たくなったんだけどもみつからず。
脚本の野沢尚がその後、改変されまくるまえの原作ってことで「烈火の月」て作品だしてたけど、読んでもまったく別作品だったなーとか。
野沢尚いわく、映画が名作になったのは完全な偶然。
いろんなものが偶然絶妙にかみ合った故の奇跡みたいなこといってたっけか。
北野作品てその後もどこか危ういというか、ギリギリの線で成立してる、そんでそれがへんな緊張感生み出してる感あるよなーと。
その辺なにげに、画面に変な緊張感が漂うって意味ではキューブリックに近い印象あったりするぽ。

ホームアローンとビバリーヒルズコップはたまたまぱっとあったのでみてしまったw
どっちもまだ続編あるものの、ホームアローンはやっぱカルキンくんじゃないとな。てか遠い昔にみたっきりだったのだけども、序盤の家族からの冷遇ぶり、なんかみてて悲しくなるな。そういう脚本なんだとわかっていても。
んでビバリーヒルズコップの三作目は単純につまらなかったよなってことでスルー。
そいやなんでビバリーヒルズコップみたのか思い出した。
ビルとテッド3の制作の続報ぐぐったときにみた映画情報のサイトの関連リンクでビバリーヒルズコップ4の制作もちあがるも、エディーマーフィーが「脚本次第」と出演を見合わせているみたいなところで、三作目が脚本がひどくてもうあんなヒドイ内容の作品にはでたくない。というところで4作目のオファーにエディはネガティブだ的な記事があって。たしかに三作目はひどかった記憶がある。でも1と2はおもしろかったよね。ってところからの、久しぶりに見たいなとおもったんだっけか。


話はかわって。

書庫ファイルのなかの画像ファイル整理整頓編集ツール。
7zipのなかの7z.dll使うとzipだけでなく多種多様な書庫に対応できるのと、統合アーカイバにくらべ動作も軽そうってのもあって、そっちに乗り換えることにしたのだけども。
んでついでに、やっぱそろそろ64bitアプリ化も考えた方がいいのかなー。将来的にも。んでもwin32apiまわりがなぁ。64bit版完璧にすべてそろってるっているのか。その辺で面倒おこるんじゃないかってところと、開発環境も入れ直しメンドイ。ってのがあったりで。

んでもいつかはやらないと。
あとなにげに7z.dllさわってみて、rarとかrar5まで対応出来てるので、これ使えばマンガミーヤ的な物自分で作れるな。でもそうなると32bitアプリだとぼちぼちキツイかねぇ。
なんて思惑もあったりで。

んで64bit開発環境化よしやるかとなったわけで。
……したら以外にあっさりと出来てしまって拍子抜け。

てかvisual studio自体は32bit版しかないのね元々。
で、Qtの方をmsvc2017の64bit版に切り替える。

新規でテストプロジェクト作成。
msvc用のデバッグツール(WinDbg)がみつからねーとか怒られて、みたら64bit版ないやんと。windowsSDKのとこからダウンロード。
うん? 64bitとか選択するところないやん?
とりあえず入れてみると64bit版が新たに追加される。
??
そいや32bit版のWinDbg入れたの随分前だけど、そのときは64bit版がまだなかった? ちょっとググってみると、なんか以前は64bitのWinDbgだけインスコ失敗するみたいな記事でてきたので、以前はインスコ失敗してたのかw
影響無いので気づかなかっただけっぽいw
そんな感じで一手間はさんで、実行。
タスクマネージャでみると*32の文字消えてる~64bitアプリ作成成功~
ってことでここまでは簡単でした。

問題はなんか内部でwinapiとかなんかMS製のvariant型みたいなのからwin依存コードべったりだったりする7z.dll。
この辺でなんか一悶着ありそうなんだよなーて予感あったりしたのですが。
なんか元のプロジェクトの設定がのこってるのかなんなのか。
以前のプロジェクト読み込んでリビルドしてみたらエラーどばどば。
それも7z.dllつかうのに必要なoleaut32.lib user32.libあたりが見つからない感じのエラー。さらにはライブラリのほうがx86だから整合性とれんよてきなエラーまででてくる。
うーん。やっぱりすんなりいかなかったか。

てか7z.dllてそもそも64bitいけるん? ダウンロードページみると「x86 / x64」てなってるし。ソースコードは「any」になってるので、両用なの?
とおもったのだけども。
dllの方を確認してみるとどうも32bitくさい。
7-Zipの64ビット版のexe(インストーラ)落してきて解凍したなかみの7z.dllみたらサイズ違うし64bit版はやっぱ別であるんじゃん……。

で、64bit版の7z.dllに置き換えてみたら、ビルド通る。
実行。書庫の中身もちゃんと取得出来てる~。

割と昔、QtのQDataStreamとか触り始めたころにqint8とかqint16とか使う用になってるので64bitアプリになってもコードはそのまま使える配慮になってんだなーってのを見たときからバイナリ操作まわりは意識してバイト長固定の型を使う用にはしてきたりと、一応将来的に64bit化は頭の片隅においとくコーディングはしてきてたつもりなので、その辺では今のところトラブルはないっぽい。

そんな感じでわりとあっさり64bit化はできてしまったっぽい。


それとは別に。
7z.dllはいろんな書庫に対応できていいんですが、どうもzipのunicodeファイル名には対応してないっぽい。というのも、unicode対応版なんてものを公開してる人がいるので。

てかこのzipのunicodeファイル名ってのが厄介で、以前その辺の対策込みのzip読み込み作ったときの記憶なので細かいところは間違ってるかもだけど

unicodeフラグというのがある。このフラグたってるときはファイル名やコメントなどはunicodeとして扱われる。
厄介なのは、macなどのOS標準でunicode(unix系はutf8がデフォ)の文字セットの環境で作られたzipではこのunicodeフラグは立って無くてもファイル名やコメントはunicodeになる。

てな感じらしい。
んで、どのOSで作られたかというフィールドもあるのだけども
その辺ほんとにちゃんと入ってるのかなんて信用出来ないし、そしてバイナリで見た場合、その文字が入ってるとおぼしきバイナリ列からそれがunicodeなのかshift-jisなのかなんて見分けがつかないわけで。(条件がそろえば見分けはつくけど、確実性は無い)

で、7z.dllで取得出来る書庫内アイテムの情報にはこのunicodeフラグは含まれてないんですよね。なので7z.dll自体を改変してリビルドするしか対応できないので改造版7z.dllてのが出てきてるんでしょうけど。

んでもまあ、実際の所、そんな特殊なzipファイルに対応する必要あるんかいなという気もしないでもないのだけども。

それともう一つ、7z.dllのファイル個別解凍あたりのところ、これって非圧縮の場合なんかちょっと無駄がおおいかんじになっちゃわない?
てなところもあったりで。

さらにもう一つ。
zip以外→非圧縮zipに変換するのが用途的には必要なのだけども、7z.dllの機能つかって非圧縮zip作るのもなんかいちいち面倒(ほかの書庫用の設定も考慮に入れたつくりになっているので)だったりして。

なので、zip周りは今まで通り自前でやって、zip以外の書庫にだけ7z.dll使う感じの運用のがいいのかなーと言う感じに。
それだとunicodeファイル名の処理も一応できるしね。

前に作った奴は、ネックはrar書庫だったんですよね。
rarのファイル個別解凍、それもファイルにではなくバッファ(メモリ上)に。てのが統合アーカイバではできなかったので。
さらにはrarの内部バージョンでバージョン間に互換性がないってのでも対応が難しい部分あったりで(各バージョン毎のコードが必要になる)

7z.dllだとそれができるので以前はrarは一旦zipに変換して、それから書庫内処理ってかんじだったのを、
7z.dllでrar開いて、ファイル単位でメモリに解凍、画像処理などおこなって、非圧縮zipに書き出し。
てのが出来る用に。

間にいったんzipに変換してから~でなく直で画像編集適用しながらzipに変換出来るようになって良い感じ。
オマケに7zにもlzhにも対応出来る様になったし。7z.dll様々やぁ。

なかんじで後はちまちま組むだけってかんじなのだけども。
その辺でなぜか映画みるブームきちゃって気がついたら二月だよ……。


またまた話は変わって。

田中久仁彦氏のラフ画集の第2弾が受注販売してたので即買い。
気がついたのが1/26で受注〆切りが1/28だったので気がついて良かった~。
氏のサイトは週1~月1ぐらいの頻度でなんか新しい絵とか上がってないかなと見る感じなので、タイミング悪ければ逃してるところでした。
んでもまあ、前作のもその後も何度か再販してたみたいなので、これを逃したらもう……って感じでもないっぽいですけど。
2月中旬以降到着とのことで愉しみ~。

んでも本のお値段、約100pで1200円ぐらい。というのは安しぃ~と思うのに
送料500円で計1700円ていうと高けぇ~って思う不思議w
なんかもう尼とかに慣れすぎて送料500円高けぇって印象しかなくなっちゃいましたね。配達業者には不幸な事だろうけど。


んーなんか1月はあんまし実りのない無為に過ごす時間多い感じでダメダメだったなぁ。

やること、やりたいことは山積してるんだけどなぁ。

某所のpixivダウンローダが最近なんかChromeと連携して画像取得するようになって、しかたなくChromeいれたんだけど、なんか変なツールとか勝手に入れやがるしでChrome消したい……。
そんでもってこのツールやたらとChromeのプロセスが残りまくるので、メモリドカ食いなうえ、終了後にタスクマネージャで消えてないChromeのプロセスをプチプチ消すのもメンドイ……。
てかブラウザ経由で画像取得するぐらいなら、こんなん自作できるよなと。
Chrome消したい欲求からのツール作成欲求メラメラ。
とばっちりでChrome大嫌いになった最近。
この辺のツールはサイトの仕様かわったらまた修正要ったりするので面倒な部分もおおいのでアレですけど。それよりもChrome消したい(ぉ

そいやsslのサイト(https)にアクセスするにはOpenSSLとか必要なんですけど、以前作った漫画発売日情報サイトから情報取得するツール作った時に入れたのだけど、32bit版なんですよね。
OpenSSLも64bit版そのうち入れとかないとな……なんてことを思い出したり。
普通にdlするんじゃなくて、ソース落して自前でビルドしないと行けないのでメンドイ……。

むぐゆぁ~