あれから色々とあってなかなか手が付けられませんでしたが、連休なので意を決して着手。(というほど大げさなものではないのですが…)
switch文にcaseを羅列する力業で対処。まぁほかにやりようもないのでしょうけども。これでどうにか問題は解決した模様。
やれやれ
C#とSQLite続き
文字コード自体の問題かと思われたのですが、よくよく調べてみたところUnicodeに実装されている結合文字の問題と判明。
普通の日本語変換ソフトなら濁点と半濁点の付いた文字はそのまま1文字として変換してくれるのですが、元データーはひらがな+結合文字の濁点(半濁点)で作成されていました。
これじゃ文字コードをどう変換したところで普通に手打ちして作ったDBの中身と正しく照合できるはずが有りません。もしかするとUTF16->ShiftJIS(windows codepage 932)->UTF8のルートで変換したらなんとかなったのかもしれませんが、面倒…
面倒ですけど、頭の体操ということで一回試してみますか。
追伸:
試した結果、結合文字はShitJIS側では知らない文字ということで?に変換されてしまいました。なのでこの試みは失敗。濁点がつくのは「か行」、「さ行」、「た行」、「は行」なので地道に変換するしかないですね。面倒…
C#とSQLite
MP3データーのTAGを整理してファイル名に反映させるプログラムを作成中。TAGのデーターにある人名から肩書を追加するのに最初はべた書きしてましたが、ファイル数が膨大になってきたので、対応しきれません。まぁ最初から分かってはいたんですがね。
ならば「DBを用意して、そこから引っ張ってくれば簡単♪」とプログラムを書き始めます。ちなみに最近は脳力減退を補うためにC#で書きますが、なかなか… OOPの場合、classの中身が謎であることが多くて検索ばかりでなかなか進みません。
余談ですが、最近のVSはAI化が進んでいて先回りしてコード例を提示してくるのでちょっと気味が悪かったりします。バリバリコードを書くような場合には便利かもしれませんけどね。
さてDBには使い捨てプログラムと言うことも有って一々インストールしなくて済むSQLiteを選択。別途用意したデーターを書き込んでDBを準備します。そして本番プログラムから検索させるのだけど、全然ヒットしない。アルファベットだけの場合はうまくいくので、文字コードからみだとは思うのだけどいろいろゃっても改善されず。
ならばとC#からデーターを書き込んでやれば良いのではと気が付いて新しいプログラムを作成。ちょっとトラブルはありましたが、無事にDBに書き込みできました。
さぁ、これでどう改善されるのかな。
cmake QT6の謎
Fedora40にUpgradeしたのですが、各モジュールのrebuildで問題多発。QT6のcmake定義がないとかなんとか。kf6(KDE 6)のメインモジュールやplasma関係のrpmがかなり引っかかります。
いろいろ調べて処置してみるのですがまったく改善されません。
しばらくもやもやしていたのですが、VMに新規インストールしたらどうなるのかと気付きました。
VM player ProがVer.17から個人利用であれば使用できるようになったので早速セットアップ。そしてFedora40をISOイメージからインストールしてあれこれ準備。
ちなみにVMへだと、UEFIでなければインストール不能となっているFedora40が若干の問題だけでインストールができます。
さっそくrebuildしたところ問題なく進行していきます。ならばと思い、/usr/lib64/qt6/cmakeの中身を全部取り出して、VMでない方にコピーします。本来は一つずつどこがどう違うか調べるべきでしたが、一気に上書きしたので何がNGだったのかは不明ですが、rebuildは本番環境でも問題なく進むようになりました。あとはネット関係が引っかかるのを解決できれば問題解決なんだけど、どこから調べていきますかね。現状ではVM上のFedoraの方がスムーズに動きますので。
だからと言って全面的にVM環境下へ移行することも検討しましたが、どうしたってパフォーマンスは落ちますから、正しい選択とも思えません。
さてもう一息頑張りましょうか。
Fedora40
有難いことに本業が繁盛で、なかなか遊んでいる時間も取れません。でモタモタしていたら40がリリースされていました。
本当はBootable Mediaから入れ直すのが古いrpmを削除できるので本筋なんですが、UEFI対応ではないこのPCだとBootable Mediaからの起動ができないので、いつものようにdnfの system upgradeを実行。
最初にFedora37時代のモジュールが引っかかったので削除。38,39と無事に過ごしていたのがすごいな…
さらにAkonadi-Serverの絡みでkde側のモジュールと競合するとか言ってきたので–best –allowerasingを追加。あとrustのモジュールでもトラブルが出てましたね。
rustとpythonはいつもモジュール類のバージョンで引っかかって面倒を起こしてくれます。rpmのrebuildに必要となるので入れてますが、本当に迷惑。特にrustのcrateはバージョン0.1とか0.2なんて奴が平気で公開されていて、しかもそいつに依存するアプリケーションが少なからず存在します。なのでrebuildするには複数を入れて置かなければなりません。例えば、
rust-rand0.7+libc-devel-0.7.3-8.fc39.noarch
rust-rand0.7+std-devel-0.7.3-8.fc39.noarch
rust-rand+libc-devel-0.8.5-5.fc39.noarch
rust-rand+std-devel-0.8.5-5.fc39.noarch
てな具合。
C++に比べて堅牢ってことですが、こんなバージョン管理がまかり通っていて本当なんですかねぇ。
トータルで9100余りのrpmが入れ替えになりました。これでまたしばらくrebuild祭りで遊べそう。
KiCAD winbuild
PCのOSがWindows11になりました。なのでと言う訳でもないのですがbuildシステムがpowershellのshell scriptベースとなったので、改めて挑戦。
説明ページ(https://gitlab.com/kicad/packaging/kicad-win-builder)によればgitを入れとけばOKとのことだったので、一式をgitリポジトリから持ってきて実行開始。
いきなり「powershellではスクリプト実行できません」攻撃を喰らい撃沈。セキュリティ上の仕様によりスクリプトは実行できない状態にしてあるとかなんとか。いきなり丸腰ってもどうかと思ったので制限付き実行可状態として再度挑戦。
あれやこれやをダウンロードしているようで順調です。が、「cmakeが無い」と苦情。こんなことも有ろうかと思ってcmakeを最新版を入れてPathも通しておいたのですがダメ。よくエラーメッセージを見るとパス決め打ちでそこにcmakeが無いと。しかもバージョンまで決め打ちされているのでcmakeのアーカイブから当該バージョンを引っ張ってきて、再挑戦。
が、結果的には最後のあたりでエラーになって結局は自前buildには失敗です。
本家ではどうやってパッケージを作成してんでしょうね。毎度のことながら謎だ。
Fedora39 -O3化終了
いろいろあって専念できなかった関係も有ってようやく-O3化終了です。
4453モジュール中4273モジュールが-O3化できました。率としては約96%。まぁそんなものですかね。
さて次は何して遊ぶかな。その前にPCをなんとかするのが先決?
FC39その2
Windows側での作業が一段落したのでLinux側での作業開始。時間はかかったようですが、無事に39にUpgradeができました。
相変わらずなにがどうなったことやら(苦笑)。Consoleのプロンプトの形が少し変わったのは気が付きましたが、他はさっぱり…
思い返せばFedoraCore2からの付き合いですからね。調べたらFC2の登場が2004年5月ですから18年半ほどが経過したことになります。で、使う側の技量がそれだけ上がったのかというと… ですねぇ(苦笑)
Desktopも最初はGnomeでしたが、GNOME3になったときにどうにも違和感だらけだったのでKDEにスイッチして以来KDEとの付き合いです。KDEも5になりたての時はトラブルが多かったのですが、以後だいぶ安定するようになりましたね。そろそろ6って噂も聞こえてきますがどうなりますやら。
さあ、恒例の-O3化。ツールは揃えたのであとはソースを用意するだけ。手始めにめちゃくちゃ時間のかかるgccから行きますか。
FC39
ラジオ放送の整理で時間がとられている間に39がリリースされていました。
Fedoraは半年ごとに更新なのでお約束ではありますが、見た感じ大きく変わったところが無いので更新しがいが…
もたもたしていると40が出てしまうので早めに更新しないとね。
クリーンインストールはできないので祈るようにして実行するdnf upgrade….
さて今回はどうなることやら。
やばいやばい
-O3化が一段落して、日常に復旧しました。で、いつものようにupdateモジュールどものrebuild。ところがまたしても途中でPCが気絶する事態に陥ってしまいました。何をしてもキーボードからは反応がありません。メニューからrebootを選びますが先に進まない… デスクトップのウィジェットはちゃんと反応しているのがなんとも悔しい状態。
しかたがないので強制電源断。このまま再起動すると前回同様怪しいことになりそうだったので、一旦36のBootable Mediaで起動です。しかしKDE spinなので例によって停止します。
毎回ビデオカードの脱着は面倒なので、ここで新しいDesktop環境のBootable Mediaを作ることにします。とりあえず38のCinamonを作成してBoot。見事に起動せず… UEFI未対応PCだとBootable Meidaからも起動できないとは… トホホ と言う訳でアーカイブを漁って36のCinamon DesktopのBootable Mediaを作成して起動します。
lsblkで対象ドライブを確認してxfs_repairを実行。当該デバイスのlogが変だから一旦mountしろやと出ましたので適当にディレクトリを作ってmountしてからumount。
その後再度xfs_repairを実行。いくつか「注意」は出ましたが、さほど大事にならずに修復終了。
あとはシステムを再起動してどこからも苦情が出ないことを確認します。
いやはやびっくりしたな。