堕天使の煉獄

うーん。
アレからまたちょっと調べてみたけど、やっぱ問題はQFileSystemModelにありそう。
なんでも別スレッドで監視＆更新してる感じみたい。
そこでファイルをロックしてるぽ。

あとQFileSystemModel使う場合、setRootPathと、ルートからのパスしか設定できず、途中のあるフォルダ以下のみツリー表示ってのは出来ない仕様ぽ。

むううん。

リスト部分は上下2ペインに分けて、上に登録したフォルダリスト。
下部に登録したフォルダリスト内のフォルダ選択すると、そのフォルダ以下のツリーをQTreeWidgetで全部自前登録で表示。

内容がそんな多くないものならまあ、これでいいのかなぁと。
更新も単純にフォルダリストからフォルダ切り替える毎に再読み込みする感じになる＆「最新の状態に更新」も今開いてるフォルダ以下の部分だけ再読込するだけで済むしね。

そもそも自分で使う＆プロジェクト単位でソースコード参照するっていう限定された用途で使うものだし。

汎用性とか求めだすときりがないので、さくっとシンプルに作ることにしよう。

ツリービューにどんどん登録フォルダ追加していく形式だと、結局離れたプロジェクトだと上下のスクロールが面倒てのは変わらなくなっちゃうしね。
あとフォルダツリーの開閉状態の保存＆復元も登録フォルダリスト単位で管理できるのも楽そうぽ。
よし、とりあえずこの方向でやってみよう。


んで、タイトル「お腹いっぱい」。
PGとか設計考えてたりすると糖分欲しくなったりするのですが。

ここ最近あんまり行ってなかったところのスーパーに久しぶりに気まぐれで行ってみたらば。
ブルーベリージャムor小倉と生クリームたっぷりパイ生地っぽいのに挟んであるやつが、店内で作ってるベーカリーパンのコーナーに有って。

ブルーベリージャム結構好きなんですよね。

んで、ブルーベリーも小倉の方もどっちも一個158円なんですけど、ブルーベリーと小倉一個ずつ入ってるセットだと298円でちょっとお得なセットがあって。
じゃまあ、お得なかんじのセットの方を、と買ってみたのだけども、これがなかなか美味しくて気に入ったのですが。

最近これまた気に入ってる、ドラッグストアで78円とかで売ってる無糖のミルクティーとよく合うんだわ。

んで昨日、それ目当てだけにそのスーパーにまた行くぐらいのリピーターにｗ

……でもこれめっちゃカロリー高そうだな。
PGとかやるのに糖分欲しいってことで、これも糖分いぱーいなので丁度いい……と自分に言い訳してる感じではあるのですが。
普通に一個食べただけでお腹いっぱい胸いっぱいで、眠くなっちゃって全然進まねぇという（ぉ

やっぱ糖分補給は森永製菓の「大粒ラムネ」ぽりぽり食うぐらいが丁度いいのかもなぁ……。


「過ぎたるは猶及ばざるが如し」 ……だね。

このパン食べるともう、一日終わった感出ちゃうぽ。魔性のパンやな。

そして、二個セットの買ってるのですが、一度に二個食べれるほど大食漢でもないので一個ずつ食べる感じなのだけども。

今、後一個残ってるのが冷蔵庫にあるんだけど……食べたら今日終わっちゃう……のかなぁ（遠い目

こりゃしばらく封印したほうが良さそうだな……。
まあちょっと遠目のところにあるスーパーなので（つーても車で15分ぐらいだけど、途中渋滞ポイントが多い地域で時間帯によっては30分かかることもある）、そもそもそんなしょっちゅう気軽に行けるって感じでもないのが救いか。

で、そこの帰り道によった、近場のスーパーで。
ここは手作りのお弁当が美味しいところで、どうせ外に出たんならってことでお弁当を買う。今日は鳥の気分だったのでチキン南蛮。

んで、7月頭の発売日近辺では置いてなかった、スーパーカップのチョコミントが5個ぐらい残ってる。
現品限りで終わりの期間限定販売物なので、じゃあ買ってくかと二個購入。
多分、これで今年最後のチョコミントかな。

去年このスーパーでまだ20個ぐらいあるなと思って、まあ今日はいいか……とおもったあと、翌週ぐらいに、今季最後に買っとくかと思って買いに行ったら影も形のなくなってて、無いと思うと無性に食べたくなるもので。そのオアズケ具合が今年まで尾を引いてたりしたんですよね。

今季はコレが最後の食べ納めって気分で最後の分買えたので、気持ち的にはスッキリｗ

先日の日記のタイトル「ぶじゅるっ」
そのネタを書こうと思って書き始めたものの、他のこと書いてるうちに忘れちゃってたりｗ


まあ、あんまり気持ちのいい話でもないんですけど。
ちょっと前から頭に中にパチンコ玉でも入ってるのかな？　ってサイズのできものが出来てて。
痛くも痒くもないのですが、頭洗うときに指にゴツゴツ当たるし。
でも鏡でみたところ色も変わってないしで、こりゃ粉瘤ってやつかな。
毛穴とかに皮脂とかゴミが溜まってなるやつ。
にしてもデカいな……頭は皮脂が多い部分だからなのか。

で、だんだん痒くなってきて、そろそろかな……とおもったんだけど、そこからがしぶとくて。
んでもう我慢ならぬって感じで、そいつをティッシュでくるんだ状態で「フンハッ！」ってやったら「ぶじゅるっ」っていうすんごい嫌な感覚とともに大量の白いやつが出てきて、「ぼうぇっ」って嘔吐いたりして。

今までになくデカかった所為か内容物の量も凄まじくて、そのあまりの量に気持ち悪くなっちゃったです。頭皮ってやっぱ皮脂半端ないのな。

とりあえず透明な汁しか出なくなるまで中身絞り出した後、消毒。

はーすっきり。


話は変わって。

なんかもうクッソ暑くてなーんもやる気でない感じなんですが、それでも少しでも進めないとなってことで。

とりあえずすぐ出来そうな、別プロジェクトのソースコードを閲覧参照用のハイライタ付きテキストビューワ的なの。

これ、昔作ったやつからソースコード移植しながら作ったりするときに便利なんですよね。
でも作ったのがQt4のころで、Qt5で動くように微調整してリビルドしただけで、中身はかなり古いものになってるのと、長年使ってきた中で出てきた改良点なんかも組み込んでQt6で作り直そうって感じ。

んで一番の改善点は、これで開いてる状態で、開いてる場所のファイルをエクスプローラとか外部で削除すると、ロックされてることがあるんですよね。「使用中で～」とか出る感じの。
このツール終了させると普通に削除できるんですけど。

んで、Qt5でリビルドしたときに、中身のソースコード表示してる部分でファイルのリソース開放とかし忘れてるのかなぁ？　とかおもって、その辺ちょこっといじったのですが、状況変わらずで。

やっぱQFileSystemModel使ってるのが悪いのかなぁと。

これはQTreeViewにセットするだけでエクスプローラのようなフォルダツリー簡単に表示できる＆変更があった場合を監視して更新もしてくれる優れものではあるのだけども。

その監視部分でファイルのロックが発生してるんじゃないかなぁと。

モデルビューって、中身複雑すぎて、内部で何がどうなってるのかブラックボックスなんですよね。

あとQFileSystemModel使う場合、QTreeViewに一個しか設定できないぽ。

このツールしばらく使ってみて思ったのは、例えばQtの別プロジェクトをみるだけなら近い場所にあるからいいんだけど、そこにDXライブラリで書いたコード参照したいときってと、それなりに離れた場所にあるので、フォルダツリーがでろーんと伸びて、行ったり来たりが面倒くさい。

QFileSystemModel使わないで、指定のフォルダパス指定して登録。
と、フォルダ単位で登録して、そのフォルダ以下のツリーを表示する形にしたほうがいいなぁと。

そのかわりQFileSystemModel使わず自前でツリー構築するので、外部での変更やリネームの即時反映はできなくなるけど。
まあ「更新」で再作成できるようにしておけばいいかな。

後もう一つ。
QFileSystemModel使ってたときだと、そこで別のルートパス指定して開いて。
また戻ってきたりすると、ツリーのフォルダの開閉状態がリセットされてる問題。

なんかやりようはあるらしいのだけども、めっちゃ面倒そう。
ユーザーデータ追加して開閉状態を記録させるみたいなの。

基本、このツール、PGやってる間はずっと立ち上げっぱのこと多いので、ツール立ち上げたときまでツリーの開閉状態復元はしなくてもいいかなぁとおもうのですが、起動中は開閉状態はキープしておきたい。
いちいちリセットされると面倒でしょうが無いんですよね。

その点も、QFileSystemModel使わない自前で登録型だと……あ、自前で「最新の情報に更新」的なのやるとツリー再取得時に開閉状態復元処理要るな……。
まあフォルダ名キーにしたハッシュリストとかで対応できるか。

大量にフォルダ登録とか、大量にファイルが有る場所なんかだと、更新に時間かかりそうだけど……まあ自分しか使わないツールだしいいかｗ

QFileSystemModelは使ってない部分は読み込まない。使う部分だけ読み込む感じなので軽いんですよね。

逆に自前登録の場合は、ガッツリ全部読み込んで登録するので量が増えると重くなるぽ。
まあ数千程度なら問題無いとおもうけど。

あとはQFileSystemModel使わないで自前登録になるとQTreeViewでなくQTreeWidgetの方使えるのでシンプルに書けるよねっていうメリットもあったりするぽ。

モデルビューはどうしても色々と複雑になりがちなんだよね。

実際に組んでみて、ファイルのロック問題解決してるといいなぁ。

あとはハイライタ周り……結構昔に書いたコードなのでリライトしたい所。
んでも、あんまり凝るのもなぁと。
閲覧時にハイライトきっちり出来てると気分いいけど、ほとんど自己満足の世界だからなぁ。
そこに今詰めすぎるのもいかがなものかと。

他にやること山積してることだし……さらっと終わらせたいｗ

先月末のQtまわりのアップデート、異様に遅かったのはメンテナンスツールのバグで、ミラーサーバに振るわける部分がうまく動いてなくて本家のサーバに集中してくっそ遅くなってた模様。
てかその報告が一週間後ってどゆことｗ

それはさておき。

perlのもっと簡単お手軽な実行環境ないものかとググってたときに、XAMPPなるものがでてきたのだけども。
なんか調べてみると、古い簡易版のすとろべりーぱーるが入ってるとかで、結局perlは自分で入れなきゃ駄目ーとか、結局httpのデーモン使うタイプなのねーとか、うーんめんどくさそう。

とスルーしたのだけども。

どちらかというとperlはおまけでphpのほうがメインなのねコレ。

んでphpってなんかあんまり興味持ったことなくて。
perlの後発のcgiとかに使う言語って感じで、perlほど変態的でない初心者にもとっつきやすい言語……てな印象だったのですが。

今回ちょっと調べてみたら、当時（1990年代末期～2000年代初頭）から随分と進化してる部分もあって事情も違うのでしょうけど。

へえ、ssi（サーバーサイドインクルード）みたいなのが標準機能でできるのね。
ssiは当時は対応してないレンタルサバも多かったりで結局まともに使う機会もなかったのだけども。

「全ページに共通のメニュー」なんかを埋め込むのとかに便利なんですよね。
perlでもできるっちゃできるけどもっと汎用性の高い形でできるっぽい。

あと、perlの記法だけなんとなくおんなじ風な、なんちゃってのオブジェクト指向じゃなくもっとまともなオブジェクト指向な書き方できるのねphp。
phpのクラスの記法はC#とかJAVAタイプな感じぽ。

あと速度面でもモジュールモードだと速いらしい。

そんでもってphpはDBと連携が最初から想定されてる感じなので、その辺の機能が充実してるらしい。


ふむう。

perlのなんちゃってオブジェクト指向で書かれてるこのブログ風cgi。
結構後から手を入れようと思うと、何がどうなってるのか思い出すのに一苦労するんだよなｗ
IDEとか無いし。

一方、phpは入力補完までついてるIDEが結構ぽこぽこあったりするんですよね。

ただ、ローカルのWebサーバにIISつかうのかApache使うのかとか、IDEもVisualStudioつかうのか、VS code使うのか、もっとべつのIDEつかうのかとか。
いろいろと方法がありすぎて、どれにしたもんかなと。

んでもってなにげに今最新はphp8.2なんだけど、8.2の新機能でreadonlyがクラス全体に指定できる機能がつくとかで、コレ使いたいねぇ。ってなったんだけども。

さくらインターネットではまだ8.1までしか対応してないんだよねｗ

あとphpてバージョンアップで破壊的変更を結構する感じらしいみたいね。
phpとセットで語られてることの多いWordPressなんかもバージョン差異のトラブル多いみたいだし。
LTSみたいなの無いのかな？　と調べてみたのだけども基本的に三年サポートで古いのはどんどん切ってくスタイルらしい。
なのにとっくにサポートも切れてる5.xとか7.xがいまだ多くの鯖で稼働中という現状があったりして、web系て枯れるまで待つ傾向あるのか、最新のver使えるようになるまで遅い＆古い枯れてるverを使い続けるパターンおおいよね。

うーん。
環境作るのもめんどいってのもあるんだけど、もし触るんならさくらインターネットで8.2対応きてからでいいかなぁ……って感じに。

DBまわりは……さくらインターネットはDBも使えるんだけど、DBサーバーが物理的に別鯖になるのでかなり遅いと言われてるんですよね昔から。
DBサーバをすべてSSDに変えました！　とかいうても、速度のボトルネックはそこじゃねぇしって感じだしｗ

んで、SQLiteをつかうという方向もあるのですが。
どうもトラブル多いらしくて、これで自前でブログシステムとか作るのはやめたほうがいい。「やめとけ」っていう意見がちょっとググっただけでもぼこぼこ出てくるｗ

んんーカテゴリ別で記事表示とかやりたくもあるんだけど、現行のテキストファイルベースのでも負荷考えなければべつに出来なくもないんですけど。
そこまでするほどねもないかなぁって感じでもあるし。

まともなオブジェクト指向であとから保守とかやりやすくなるならphpで書き直してみるのもアリかなぁ、どうかなぁ……環境構築のめんどくささがやっぱネックだなぁ。
でもXAMPPだとperlの実行環境もついてくるので手間を惜しまず作っておくべきかなぁ……。

なんてことを悩み中な最近。


関係ないけど、perlとphp、昔の知識というかイメージしか無いので最近の事情を知るためにいろろググってたときの事。

perlの言語としての説明分のところに

「Perl（パル）」

と書かれてるサイトがｗ
そのタイミングでちょうど飲み物をくぴりと口に含んだ瞬間だったせいで、ぷぴゅると吹いたｗｗ

ぱるってｗ

なんかすんごく不意打ちで飲み物吹いたじゃねーかｗ

まあただのtypoなんだろうけど、ぱるっていう音の響きがなんかツボに入ってしまったりｗ


……で、ここまでphp移行もかなり現実的に考えてたところで、さくらインターネットのperlのverが5.12.x で、最近契約した鯖だとperl 5.32.xつかえまっせ。
ってあるんだけど、最新て今いくつだっけ？
とおもって調べてみたらば。

最新は5.38.0 だったんだけど、そのあとに気になる文言が目に入る。

「class構文が追加された」

ttps://perldoc.perl.org/perl5380delta

use feature 'class';

class Point
{
field $x;
field $y;

method zero { $x = $y = 0; }
}

とfeatureキーワード付いてるので、まだお試し機能みたいだけど。

……慣れ親しんだperlでまともなclass使えるようになるんならphpいらなくね？
ってなったりしてるｗ

でもさくらインターネットてわりとperlのver上がるの遅いんだよな。
まあperlはもともとそんな新機能もとめて新しいver使いたがる感じでもない感じだけど。
4→5に上がるあたりはたしか早く上がってくれんかな……ってなってた記憶があるような無いような。

でもまあまだ実験的みたいだし、実際にclass使えるようになって、さらにそのverがさくらインターネットで使えるようになるのっていつよ？　って話になるのと、結局perl用のIDEも相変わらずそんなないよねーっていうのもあるし。

てか5.38.0て2023年7月02日 リリースてめっちゃ最近やん。

5.34でtry/catch使えるようになったり、後発だけあってfinallyもあるらしい(c++にもfinallyほすぃまあRAII的にアレなのでアレなんですけど)

八進数のリテラルに0o (zero, small o) が使えるようになったらしい。
もともとのperlの仕様の先頭に0（zero）つくと八進数ってのは文字も数値も一緒くたに扱えるperl特有の罠で、09月とか09日みたいな日付とか月のデータを文字で持ってるときに、数値として足し算とかすると八進数で09だと11扱いになっちゃって計算がおかしくなるという。
そういうのがあるのでむしろ0付きが八進数てのをやめて0oのみにしてほしいところではある。
そもそも数値としての八進数なんて使わないしね。特殊な用途以外。

結構いろいろと進化続いてるのなperl。

うーむ。
このタイミングでそんなの知っちゃうとなあ。
まあphpとか対して難しくなさそうなので学習コストもそんなかからないっぽいんですけど。
それに慣れた頃にperlが超進化してまた戻るって感じになる流れになりそうじゃないコレ？

ていうかperlって、perl6があまりにもperlとかけ離れた別言語ってレベルだったので結局「Raku」っていう別言語として分かれて。
混乱避けるためかperlの時期verはperl7になるってなのどっかで見たんだけども。
割と最近のverうｐで5.38とまだ5系なのね。

調べてみると、2020/6/24に発表されて以来、とくに目立った動きはないっぽいねperl7。

Perl 5.32以降のverの機能はperl7用の機能のお試し版みたいな感じでもあるらしいので、じわじわとは進んでるみたい？
上記のclassとかtry/catchとか、言語的に新しい要素の追加って感じの方向っぽいし。

まあ、この感じだと使えるのはいつになるんだ……ってところがネックか……。

いっそc++で書ければ一番面倒ないんですけどね。
でも共用レンタル鯖でc++のcgiとか色々問題多いので現実的ではないぽｗ



話は変わって。

ビジュアルアーツが中国の100％子会社化……大丈夫なんかコレ……。
よりによって中国とはねぇ。
この先どうなることやら。


そしてようやく8月か。
まだまだ暑い日つづくなぁ。