僕にとって、ブラウザでBackspaceでページが戻れるのは かなり重要だ。それができないと、いちいちマウスジェスチャするかAlt+←を押さなければならず、煩雑だ(パッとできない)。更に馬鹿なことに、Firefoxはショートカットキーを変更できなくしてしまった。他の件(例: アドオン切り捨て)も合わせて 一体誰のために何をしているのか分からず、とにかく早く他に移りたかった。

そして先日、Chromeのメモリ使用量が少なくなったことに気付き、更に、VivaldiはBackspaceが使える(それどころか、ごく当たり前のことだが、ショートカットを自由に変更できる)ことに気付いた(思い出した)。そして数日前にVivaldiが更新され、Chrome同様にメモリ使用量が少なくなった可能性があるので測ってみた。

その結果、最新のVivaldi(5.1.2567.46)はFirefox(97.0)と比較し得るくらい少なくなったことを確認したので、移ることにした。参考までに、以下にVivaldiとFirefoxの1タブ当たりの平均メモリ使用量を示す。

  • Vivaldi: 201MB/タブ
  • Firefox: 200MB/タブ

測定条件

  • バージョン
    • OS: Linux Mint 20.3
    • Vivaldi: 5.1.2567.46
    • Firefox: 97.0
  • 測定方法
    • 21個のページ(僕が良く使うニュース、買い物、地図など。どちらのブラウザも同じ)を数分間隔で開いたあとのメモリ使用量の増分を求め、ページ(タブ)数で除算して1タブ当たりのメモリ使用量を求めた。
    • メモリ使用量は、ブラウザのプロセスのpsコマンドのRSS(resident set size)の合計とした。

メモ

  • Vivaldiは、ページ(タブ)を開いてから少し経つ(1-2分)とメモリ使用量が減ることが多い。
    • また、ガベージコレクションなのか、タブを開いたあとのメモリ使用量が開く前より減ることもあった。
  • Firefoxも同様だが、全ページを開いたあとで何もせずに居たらメモリ使用量が増えた。メモリリークがあるのではないか。
    • 以前(2018年)はFirefoxは70MB/タブくらいだった(その時はVivaldiは217M/タブだった)が、いつからか浪費するようになってしまったようだ。
      • 今回は途中までは それほど大きくなかった(10タブで154, 20タブで186 MB/タブ)が、全部を開いてから時間が経ったら増大して上の値となった。
    • 近頃、何も特別なことをしていないのにFirefoxやシステムのメモリ使用量が増大することがあって不思議だったのは、メモリリークのせいだと分かった。
  • 仮にメモリリークが直ったとしても、Firefoxに移った当初の2倍以上になってしまい、Vivaldiとの比が当初の1/3から1/1.3まで上がったので、今となっては使う意味が完全になくなった。

Vivaldiは、何もしなくてもタブバーが縦に出せることだけでも充分僕好み(僕に言わせれば、正しい・正しく ものを作っている、あるいは「分かってる」・「筋がいい」)だが、以下をカスタマイズ・調整した(したい)。

  • 「新しいタブ」(Ctrl+T)でアドレスバーにフォーカスしない。→ Quick commandsという機能を使って対応できた(以下にその処理を書く)。それをCtrl+Tに割り当てた。
    1. New Tab
    2. Focus Address Field
  • ウインドウに名前を追加するアドオンがない? → "Window Namer and Restorer BETA"で「概ね」できる(不満はあるが、できないよりは良い)。
    • 複数のウインドウを開いていると、最小化した状態から戻す時に区別できなくなるので、ウインドウ名にそのウインドウのカテゴリを追加して区別を容易にしている。
  • [未解決] タブバーのタブの幅(高さ)が少し高く、タブが増えるとスクロールが要る。 → アドオンで何とかなる?
    • 今は、関連するタブをスタックさせて、見えるタブ数を減らして緩和している。
  • [未解決] カレンダーは どうにか動くが、今ひとつ。: betaのためか。
    • これがちゃんと動けば、Seamonkeyは要らなくなる。
  • [未解決] メールも動かない。: TLSハンドシェイクエラーになる。 → (StartTLSでなく)SSL/TLSならOKだった。
    • これがちゃんと動けばEvolutionも要らなくなる。
    • (2/18 10:44) その後更に試したら結構惜しい。: 最初に使えなかったのは、IMAPがStartTLSに対応していないためのようで、思い付いてSSL/TLSのポートを指定したら使えるようになった。
      • ただ、アドレス帳がCardDAVに対応していないので、まだ実用には向かない。が、ちょっと使った感じは悪くないので、「もう少し」の感じはする。

ちょっと使った感じでは、Firefoxより ずっと柔軟で良い!

のだが、例によって いいことずく目ではなく、以下の問題が出た。

  • サイト・ページとの相性問題
    • Twitter: 日本語入力(Fcitx+Mozc)が駄目。
      • ツイートの入力で、文字抜けや順序の乱れだけでなく それまでに入れた文字列がすっぽりなくなることがある。
        • → Linuxのアプリ(Choqok, Cawbird)は今ひとつだったので、とりあえず、Seamonkeyのブラウザを使っている。
        • → SeamonkeyはFirefox系のためか、やっぱりメモリリークするので、Epiphany(GNOME Web)を試している。 (2/19 5:28)
        • → Epiphanyはページ内の動画が再生できないので、Falkonを試している(Ubuntuのパッケージのものなので少し古い(3.1.0))。これも省メモリ(起動直後で約300MB)だ。 (2/19 9:29)
        • → なぜか、Falkonは すごく重い・遅いことがあるので、Epiphanyに戻した。 (2/20 3:24)
        • → 動画が再生できないのは不便なので、Falkonの余計そうな機能をoffにして再度試している。 (2/21 8:46)
          • なお、その前にEpiphanyの最新版を試そうとしたが、Flatpakなのに ちゃんと動かなかった(「WebViewがクラッシュ」とかいうエラーの連続で表示できない)ので止めた。
        • → Falkonには隠れたプロセス(QtWebEngineProcess)があり、それを合わせたメモリ使用量は約940MB(300+640MB)とFirefox(起動直後にtwitterを表示すると約1.1GB)と同様で わざわざ使う意味がないことが分かったので、twitterだけはFirefoxを使うことにした。 (2/20 18:58)
          • Falkonが重かったのはQtWebEngineProcessのため かも知れない。
      • その他のサイト・ページの日本語入力は、Twitterに比べれば問題ない。
        • WordPressのクラシックエディタは、文字抜けはないが、未確定文字の下線(Fcitxを改造して出るようにした)が出たままになることがある。
        • 「普通の」テキスト入力フィールドは問題なさそう。
    • [暫定対処] Ceron: スレッドを開くとハングすることがある。解決策が分からず、どうしたものか・・・
      • マウスカーソルがブルブル震えて操作できなくなり、強制終了するしかなくなる。大丈夫なこともある。
      • JSの動きの違い? ただ、検索しても出て来ない。 → 何かのアドオンが悪い?
        • → 試しに、CeronではuBlock Originを無効にしたら、その後は起こらなくなった。たまたまか効いているのかは不明だが、これで使ってみる。 (2/17 5:51)
          • Vivaldiには広告ブロック機能があるので、それを有効にしてCeron中の広告をブロックできている。
    • [Vivaldiの問題ではない] Impress watch文字が太い。 ← ページのスタイル設定(CSS)が太字のため(ひどいデザインだと思う。とは言え、比較したITmediaも別の点で ひどい・・・)。それでもFirefoxが細いのは、「太字」(bold)に使う種類(weight?)が違うのかも知れない(逆に、太字なのに太く見えないのは どうかと思う)。
      • 以下に、太字に設定しているソースを示す。
.news-headline-block ul>li {
    border-bottom: 1px dotted #aaaaaa;
    font-size: 81%;
    font-weight: bold;
    width: 100%;
}
      • 実際、ほとんどのサイト・ページでは同じように表示された。(→ 例: ITmediaVivaldi, Firefox)
        • なお、なぜかVivaldiにはtweetのボタンが出てないが、細かいことだし使わないので問題ない。
  • 時々挙動不審。。。
    • 素がいいので、今後段々良くなるのを期待したい。

 

なお、実際に使用している時のVivaldiのメモリ使用量は、5ウインドウで約100個のタブを開いている(ただし、アドオンThe great suspenderで しばらく使っていないタブを休止させている)場合、例えば4-6GB程度と、Firefox(メモリリークしていない場合)の時と大差ない。

そして、Firefoxと同様にメモリ使用量10GBで警告を出すようにしているが、普通に使っていて まだ出ていないから良さそうだ。Chrome系は随分省メモリになったものだ。と書いたが、そうではなく、「Firefoxは随分大喰らいになったものだ」が正しい。

 

PS. 書いてから気付いたが、僕はFirefoxの前はVivaldiを使っていたので、約3年ぶりに戻った。なお、その前はFirefoxだったようなので、行ったり来たりだ。

 

(2/20 8:08 一部の書式を変更、わずかに加筆・修正)

  •  1
  •  0

換気扇の間欠運転システムのタイマー、あるいは周期的on/off制御回路を自作しようと試行錯誤していたのだが、うまく行かないのと柔軟性がないために諦めて、市販のタイマーを使うことにした。

確認のために短いon/off周期にしていた時は さまざまな無茶がありながらも動いて居た感じだったが、実際のon/off周期(例: on: 15分, off: 1時間)にするとうまく動かなくなった。

後述の「非安定マルチバイブレータ版」では、実際の設定でも最初の「一瞬」(1周期= 約1時間)は うまく行ったのが謎だ。たまたまとか勘違いだったのだろうか。そのあとに「改良」しようとして いじったのが悪かったか。あるいは、無茶のために素子(トランジスタ、コンデンサ、抵抗)が壊れるとか特性が劣化して、動かなくなったのだろうか。

確かに、何度か試している時に過電流で抵抗が焦げて異臭がしたから、その前後のコンデンサやトランジスタも駄目になったのかも知れない・・・

その後もいろいろ試したがモノにならなかった。後述の「コンデンサ+リレーでのラッチ版」だけは ちゃんと動いたが、リレーを2個も使うのは綺麗でないので却下した。そのリレーを1個に減らそうとしたら、トランジスタが増えるうえに ちゃんと動かなかった。

試した回路と簡単な説明を、シミュレータまたは実際に組んで試した順に列挙する。

  1. 元々の案 (コンデンサ版)
    • コンデンサを充放電し、その電圧でリレーをon/offさせようとした(イメージはグラフを参照)が、後述のように、充放電をヒステリシス処理していないために期待どおりには動かなかった。
      • 具体的には、充分放電する前(放電開始から0.7Vくらい下がった程度)に充電が始まってしまい、on/off周期が想定より随分短くなった。
  2. コンデンサ+しきい値回路+フリップフロップ版
    • しきい値回路(図の左側, 使用したシミュレータのサンプルのSchmitt Triggerを参照した)とフリップフロップ(図の下部)で充放電の制御をしようとしたが、フリップフロップではヒステリシス処理(後述)にはならないために、うまく動かなかった。
      • このしきい値回路はシュミットトリガと書いてあるものの、期待するようには動かなかった。グラフを見ると、縦線の幅が狭い(= 僕の設計不足)せいだろうか?
  3. 非安定マルチバイブレータ版 (シミュレーションのみ。実際の回路では試さなかった。)
    • 非安定マルチバイブレータ(参照)の左右のトランジスタのon時間(幅)をリレーのon/off時間に対応させることを考えて、シミュレーションではうまく行った(の下部の一番右のグラフのon/off時間が希望の約1:4になっている)が、さすがに無理がある気がしたのでシミュレーションだけで止めた。
  4. コンデンサ+フリップフロップ版
    • 2のしきい値回路は不要な(効果がない)気がしたので省いたが、動かないことに変わりはなかった。
  5. 非安定マルチバイブレータ版
    • マルチバイブレータの左右の回路の(CRの)時定数を別にするのには無理があるようで(論外?)最初は動いたものの、実際の条件・設定(on: 15分, off: 1時間)で試したら動かなくなってしまった。
  6. コンデンサ, コンデンサ+フリップフロップの改良版
    • ちょっと思い付いたことをしてみたが、本質的でなく効果はなかった。
  7. 非安定マルチバイブレータの改良版
    • 5はトランジスタの過電流や電源が不安定とか接触不良などの問題で動かなかったかと思って改良したが、同様の結果だった。
  8. コンデンサ+リレーでのラッチ版: これだけは成功した(と思って居たが、実はシミュレーションのみだった)。
    • リレーを1個追加し、それに充放電の制御を補助させた(後述)。
    • また、PNPトランジスタのコンパレータ回路(参照)で充放電のしきい値を検出するようにしている。
  9. コンデンサ+トランジスタでのラッチ版 (シミュレーションのみ)
    • 8のリレー2個はスマートでないのでラッチ回路をトランジスタにしてみた(図の右端, 参照)が、ラッチ回路の動作が期待と異なっていたために、うまく動かなかった。
      • 具体的には、ラッチ回路は、デジタル的に入力電圧がしきい値(例: 0.7V)を超えたら出力が高電圧(例: 6V)になるが、僕が期待していたのはヒステリシスやシュミットトリガだったので、うまく行くはずがない。
  10. コンデンサ+しきい値(PNPトランジスタ)版 (シミュレーションのみ)
    • コンパレータ回路(図の中央・下部の点線で囲まれた3つの部分, 8と同じもの)で充放電のしきい値検出をするようにしたが、ヒステリシス処理していないために、やっぱりうまく動かなかった。
  11. コンデンサ+しきい値(NPNトランジスタ)版 (シミュレーションのみ)
    • PNPトランジスタの使い方が良く分からないせいもあり、やたらに電流を食って動作に影響を及ぼしたので、NPNトランジスタで簡易なコンパレータを実装してみたが、抵抗で入力を分圧するのが良くなくて今ひとつだった。
    • この辺りになると、何を目的・目標にして回路を構成してるのか(要するに「何がいいか」が)曖昧になり(とにかくリレーを減らしたいだけだった)、考えに誤り・抜けが見つかったら その対処のための部品・回路を増やしたので、どんどん複雑になってしまった。(本末転倒)

一番のポイントは、コンデンサの充放電のタイミングをヒステリシス(あるいはシュミットトリガ)処理する必要があることだ。言い換えれば、最初の発想の「コンデンサの電圧が しきい値低(Vl)以下なら充電、しきい値高(Vh)以上なら放電」という単純な処理では済まないことに薄々気付いて居ながら、思い付いたことをするばかりで根本的な対処をしなかったことが悪かった。

(ずっと、どうすればいいか分からなかったのだが、)ヒステリシス処理をしないと、充電が終わって電圧がVhを超えて放電を開始して少しするとVhを下回るので、すぐに放電が停まって充電が始まる(か何もしないか)の繰り返しになってしまう。グラフではV1(左のVhに相当する)とその少し下辺りの約0.7Vの幅でチョロチョロ上下することになる(例: の下部右側3つのグラフの小幅な上下)。そのため、たとえ希望のon/off時間比が実現できても、周期の長さの上限が大幅に短くなる。

それを防ぐには、充放電を以下のようにしなくては ならない。

  • コンデンサの電圧がV2以下になった場合、V1以上になるまで充電し続ける。
  • コンデンサの電圧がV1以上になった場合、V2以下になるまで放電し続ける。

→ 電圧がV2とV1の間では、電圧が上昇している場合は充電し、下降している場合は放電する。

※上のV1, V2はグラフに対応する。

ソフトなら容易に実現できるのだが※、アナログ回路では僕には かなり難しかった。上の「コンデンサ+リレーでのラッチ版」では追加したリレーで放電処理を保持してヒステリシス処理を実現できた。

※そもそも、ソフトの場合は(クロックで生成される)時間をカウントすればいいので、こういう処理自体が要らない。

今となっては、上のシュミットトリガの参照ページにはトランジスタでの回路が載っているので、2の「コンデンサ+しきい値回路+フリップフロップ版」のしきい値回路をそれに換えれば(更に、フリップフロップも要らないのではないか)できるかも知れない。が、コンデンサの充放電でon/off時間を設定するのは、設定可能な時間に上限(コンデンサの容量や抵抗値による)があるうえに周期やon/off時間の比率の変更・調整が容易でも柔軟でもないので諦めた。

 

という訳で長い回り道をしたが、間欠動作のできるタイマーを注文して届くのを待っている。

でもまあ、最初の僕の考えがイマイチ(実用性に欠ける)だったことが原因も合わせて確認できたし、疲れたけどいろいろ遊べたから良しだ。

今回はAmazonでなくAliExpressにした。というのは、Amazonは(嫌いだし)品数(出店数)が少ないうえに割高な感じ(AliExpressを見て気付いた)だし、機能について問い合わせても(単に「マニュアルを下さい」だけだが)碌な回答がなかったので嫌になり、なおきさんが以前使われて興味があって、試しにサイトを見てみたらすごい品数と割安なので※感激した。

※ただし、送料を合わせると それほど安くならないのが残念だ。いろいろまとめて買うと いいかも知れない(が、楽天のようにそれぞれの店が別なので、一箇所で全部揃わないと割高になる)。それでも、今回は最初だったので、360円くらいのクーポンが使えたのはありがたかった。

タイマーは、メーカー名不詳(いくら探しても出て来ず、医療関係らしい資料に それらしい名前(Belong International Co.)があったが、サプライヤーかも知れない)のXY-WJ01というものにした。いくつか比較して、機能が一番僕の要望に合っていた(かつ豊富な)のと、比較した中では一番新しそうだったからだ。なお、ほとんど同じ仕様で基板単体のもの(XY-LJ02)は安いが、ケースがあったほうが安心なので これにした。単体では約500円で送料とクーポンでの割引きを合わせて約540円だった。

ちなみに、同じものをAmazonで見ると最低でも1125円なので、送料込みで比較すると、Amazon(マーケットプレイス)は220円以上高い。

 

参考までに、タイマーの要求条件と比較した機種を以下に挙げる。

タイマーの要求条件

  • 基本的な仕様・機能
    • デジタル式: アナログ(ボリューム)だと設定の調整が難しそうだし、知らないうちにズレる可能性があるので。
      • アナログのほうが単純だし設定のバックアップが不要なので いいとも思ったが、安定性を重視して止めた。
    • On/off時間(期間)が独立で、それぞれ2時間以上設定可能なこと。
    • 繰り返し動作が可能なこと。
    • 設定が保存可能なこと。
      • デジタル式は、電源を切ったら「設定がパー」になることを心配した。
  • スイッチ: リレー
    • 機械的な強さやサイズではMOS FETだが、電気的な弱さがあるように思うので。
  • 電源: 12V
    • 追加リレーの電圧(12V)と合わせるため。
    • 可変なら なお良い。(将来別の用途に使えるかも知れないので)
  • 表示: LED/LCDどちらでも良い。
  • なるべくケース入り
    • 基板だけのものは安いが、うっかり触ってトラブルが起こったり埃が溜まるので、結局 自分でケースを用意することになるから元からあったほうが良い。
  • 価格: 1000円前後

比較した機種

※ほとんどの中身は いくつかのシリーズで同じもののようだが、メーカーどころか型番すらないものがあって、特定しにくい。

  • XY-LJ02 (= HW-751?): 基板
  • XY-WJ01: ≒XY-LJ02のケース入り(微妙に異なる)
    • XY-LJ02との違い: XY-LJ02は、
      • micro USB(5V)での給電が可能。 → おそらく、XY-WJ01も5Vで動くはず。
        • そもそも外部にリレーを追加する予定で12Vを使うので、問題ない。
      • リレーのNC(normally closed)接点の端子も出ているが、XY-WJ01はNO(normally open)接点のみ。 → そもそも外部にリレーを追加する予定なので、NOだけで問題ない。
        • 使う時は基板のリレーから取れるはず。
      • リレーの容量が大きい。: AC 125V 10A, DC 30V 10A (XY-WJ01はAC 110V 5A, DC 14V 10A) → そもそも外部にパワーリレーを追加する予定なので問題ない。
    • シリアルポート(UART)付き (XY-LJ02も)
      • 使う予定はないが、あとで使えば便利かも。
  • YYC-2S, YYC-2: 基板またはケース入り
    • 2Sと2の違いは表示桁数?
    • 電源電圧が固定なので見送った(ただし、今回は12Vだけで使う)。
  • DIY MOREのタイマー: ケース入り
    • XY-WJ01に似ているが、機能は異なる。
    • 電源電圧が固定なのと、外部トリガー(今回は使わない)がないので見送った。
  • DDC-431, DDC-432: (≒ YYC-2S?) ケース入り
    • 違いはスイッチがリレー(431)かMOS FET(432)か。
      • MOS FETは動作音がしなくていいのだが、使い方を誤った場合に壊れそうな気がしたので却下した。
    • これは電源電圧は固定でない。
  • (ディスプレイが2行のもの): ケース入り
    • 電源電圧が固定なので見送った。
  • (ターミナルのネジ用穴が天面にあるもの): (= YYC-2S?) ケース入り
    • 電源電圧が固定なので見送った。
  • (ボタンが四隅にあるもの): (= YYC-2?) ケース入り
    • 電源電圧が固定なので見送った。

 

PS. AliExpressを見ていて興味が湧いたものとして、PWMコントローラWi-Fiリレーがあった。前者は特に使う あてはないが、後者は今回の用途に使えそうだった。 − PCで換気扇をon/offする(プログラムを作る)のは容易だし、とても柔軟に制御できる。ただ、制御するPCなどを常時稼働させる必要がある(または停めている時は制御しない)のと、Wi-Fiモジュールの初期設定が大変そうだったので、今回は見送った。ただ、あとから今回買ったタイマーのトリガ入力に繋げることはできそうだ。

全くの杞憂だろうが、実はそのWi-Fiモジュール("ESP-01", "ESP-01S": 有名なようだ)に脆弱性があって、外部から侵入されて勝手に操作されることはないのかと思う。

という訳で、電子回路などで欲しい機能があったら、AliExpressを探すと大抵あるような気がした(それが ちゃんと届くかや まともに動くかは別問題で、リスクは高目だが・・・)。

 

(2/16 6:13 わずかに加筆・修正)

  •  1
  •  0

「そうだ 京都、行こう」ではない。栃木市だ。

久し振りにドライブがしたくなり、季節的には水仙かと思って探したら、県内では清水寺(せいすいじ。以下、お寺)が見つかった。ただ、県内の見どころのほとんどは4月頃が最盛期なので ちょっと早いのではないかと心配したが※、調べた限りでは1から2月にかけてが時期のようだったので、行ってみることにした。

※その心配は当たった。

さらに地図を見ていたら、近く(佐野市)に出流原弁天池というのがあり、出流原(いずるはら)という変わった地名は北関東道で何度か見て気になって居たので次の候補にし、お寺のあとに行ければ行こう※と思った。

※実際には結構遠くて、続けて行くのは無理だった。

10時頃出た。途中で寄ったコンビニはトイレが清掃中で使えず、少し待っても終わらず、車内で見ていたら何人か並ぶ人が現れたので、諦めて出た。仕事とかの人は そうそう休めないから、切実だろう。

ここまでは なぜか変な車(例: 右車線をマイペースで走り、突然遅くなって右折)が多かったが、スムーズだった。(以降も、栃木市の市街地以外はスムーズだった)

11:30頃、お寺辺りのぶどう団地(ぶどう畑が多いようだ)のコンビニに着き、ようやくトイレが使えた。ここの店員さんは、丁寧なのだが やたらに早口で、何を言っているか分からなかった。車にレジ袋を忘れた※のと食べたかった冷たい蕎麦(パスタも)がなかったので、食事は延期した(それが良くなかった)。

※こういうところでセクシー野郎の悪行が効く。レジ袋が無料でないために、コンビニの売上が減ると思う。

その後、蕎麦屋を探したが、ラーメン屋ばかりで(近くの佐野名物らしい「青竹打ち」とかが多かった。: 書きたいことはあるが、いつもの毒舌なので止める)丁度良さそうな店(例: 入りやすい)がなく、行ったり来たりするうちに体力が消耗してしまって良くない感じ(例: 「どよん」とした気分)になった。それで、蕎麦屋は諦めてコンビニを探し、何でもいいから食べることにした。

コンビニは比較的多くて見つかった。冷たいのでパスタサラダにしたが、予想通り、どっち付かずのものだった(パスタは弁当の付け合せみたいだし、サラダと言っても葉っぱが少々・・・)。が、小エビ(これがメインなのか?)は まあおいしかったし、お腹は一杯になった。

ここの店員は声が可愛く愛想は良かったけど、袋に入れてくれなくて、ちょっと「何だかなあ」だった。店ごとに やり方が違うのは仕方ないけど、最初に袋を出して「これに−」と頼んだ時には「ありがとうございます」とか言ったのに、会計が終わってから「袋詰ご協力願います」とか言ったからだ。

そもそも、スキャンだけする店員て意味あるのかと思う(そのうち、完全セルフレジで放逐されるだろうな・・・)。あと、自分で袋に入れると停滞して効率が悪くなるのではないか。

そして、「ご協力」とか言っても実際には「自分でやれ」で、言葉が適切でないのにも ちょっとイラっとしたり腑に落ちない感じがした。

今の時期は、車内の温度が(エアコンなしで)丁度いい。結構お寺から離れてしまった(経路の左下端、藤岡町だった)ので、食べてから お寺と弁天池のどちらにするか考えたが、結構疲れたので近いほうのお寺に行くことにした。

ここに来る途中、遠くの山からグライダーやパラグライダーが次々と飛んで行くのが見えた。

13:30頃、お寺に着いた。途中の、以前も通ったことがある山道(地図左下の輪の部分の上側。)が気持ち良かったが、お寺の手前(アプローチ的な道)がすごく細く(1台しか通れない)、両側にぶどう畑の網があって退避するところも少なく、傾斜が結構あったので肝を冷やし、早くも帰りが心配になってしまったw 駐車場は何箇所かあって、結構停められるようだった。

蝋梅はまあまあだったが(かといって、特に好きじゃない)、心配が当たってしまって水仙は(まだか終わりか分からないが、)時期ではなくて期待には合わなかった。一番気に入ったのは菜の花と青空だった。なお、外は風(強くはなかった)で寒かった。

14時頃、帰ることにした。運良く、お寺から出る時に対向車は来なかった。久し振りのせいか、途中で随分疲れて寝たくなった。宇都宮市に入って少ししたところで。右折する時に どこからか長いクラクションが聞こえた。寝ぼけて僕が悪いことをしたかと思ったが、対向車はなかった(はずな)ので、別の車だったのだろうということにした。その交差点の近くのコンビニで ついでの事務作業をしたりして長目に休んだら、意外にも随分回復した。

店の外で延々とスマフォをいじる謎の人が居た。

今はそういう人が多い気がする。人のことは言えない気もするwし、多様性が認められつつあるから、それでいいのだろう(と、意味不明な結論にする)。

17時頃、無事に帰宅した。疲れたけど、いつものように車が調子良くて、運転は楽しかった。

ただ、栃木市の市街地は混むうえに なんか おかしい感じだった。主要な道路なのに混み過ぎているのはバイパスがないから(想像: 有無は不明)なのだろうか? それでイライラして変な挙動の車が居た? あと、市街地なのにトラックが多いのも関係あるかも知れない。他に、おもちゃのまち(随分ファンシーなページだ)も 道が殺伐とした感じで危ない雰囲気だった。

帰路で、近頃は車に乗らないせいでクラッチ側の左足の太腿の筋肉が減って細くなったのかと思った。運動不足なので両方細くなっては いるが、右より左が細いのは、何か良くないこと(例: 左右どっちかは忘れたが、膝の骨折の後遺症)でもあるかと思って居た。

あと、その夜に気味の悪い夢を見て、久し振りに ぞっとした。きっと、疲れとか久し振りの長い運転の刺激、そして お酒を飲んで寝たせいだろうと思うが、果たして・・・

約124km, 約7時間。

 

PS. ついでに書いておく。: 帰路に約4か月振りにガソリンを入れた。近場が多かったせいか燃費は11.9km/lだったが、僕としては何も文句がない^^

  •  1
  •  0

結構前から、MySQLのサーバ(mysqld)が自動更新された後に自動起動せず※、不便な思いをしている。停まると使っている側(例: このブログ)がエラーになるので、ログインして手で起動する必要がある。

※推測だが、更新のスクリプトが間抜けで、更新後にうまく起動できないのではないか。

それが面倒なので、去年くらいから、crontabで定期的(10分ごと)にmysqldが起動しているかチェックし、していない時は起動するようにして居た。

ただ、ほとんどの場合は起動しているので、定期的にチェックするのは無駄だし、起動していない時に10分も待つのが嫌なので、以下のような自動起動処理を作った。

  1. 自動更新のログ(/var/log/apt/history.log)に、mysqldの更新が記録(追記)されるのを待つ。
    • tail -F -c 0 ファイル名 | egrep --line-buffered パターン
  2. 少し(10秒)待つ。
    • もしかしたら起動されるかも知れないので。
  3. mysqldが起動しているかチェックする。
    • systemctl status サービス名
  4. 起動していない時は起動する。
  5. 処理の実行が分かるようにメールを出す。
  6. 1に戻る。

ある程度は動作確認したが、ちゃんと動くかは次回の更新まで確かめられない。

そしてデバッグする羽目になる?w

 

MySQLは(僕にしてみれば出来が悪く、)ことあるごとに面倒を起こすので止めたいのだが、互換性があって容易に移れるものがないので我慢している。

 

PS. 書いたあとで調べたら、mysqldのサービスファイル(/lib/systemd/system/mysql.service)の "Restart=on-failure" を以下に換えるといいようだ。

Restart = always
RestartSec = 10

何かの考えが あった(やっぱりサボりたい?w)のだろうが、MySQLのパッケージに原因があった。ただ、この問題は以前は起こっていなかったため、本当に上の変更でいいのか疑問があるので※、適用するのは保留する。

※妥当であることを確認するには、問題が起こっていなかった時のサービスファイルを「発掘」して比較するのだろうが、面倒だ。

↑ ちゃんと動いていた頃のサービスファイルの発掘はできなかったが、サーバのOSをUbuntu 20に更新した時(2020/11)にsystemd(サービスファイル)による管理に変わったので、その最初のサービスファイルから ずっと駄目だったのではないか。

 

(2/6 5:12 OSのバージョン記載漏れを修正)

  •  1
  •  0

加湿器を買ってから湿度を良く見るようになった。すると、(風呂の)換気扇の効果が良く分かり、逆に、今のPCファンでの常時換気では充分でないことが分かって来た。: 風呂の換気扇を連続して(例えば1時間)回すと加湿していても湿度が下がり、停めると上がるので、確実に換気されていることが分かる。PCファンの効果は0ではないのだろうが、湿度への影響は微々たるもののようだ。

湿気だけが抜けないなら まだいいのだが、当然ながら、CO2の排出もPCファンでは不充分であろうから、(PCファンを付ける前に考えた、)風呂の換気扇を間欠的に回すのをやりたくなった。

まあ、手でon/offすればいいことだが、付け忘れたり消し忘れたりするのが嫌なのだ。

そのためには繰り返しタイマーが要るので探したが、手頃な価格で いいものが少ない。そもそも、時刻に関係なく一定間隔・周期でon/offし続けるものはなく、普通のon/off時刻指定のものでも安いもの(< 千円)は「当たり外れがある」、「すぐ壊れる」などのレビューが付いているのと、出力の接続がコンセントなので、換気扇のスイッチを制御するのには改造が必要で危険が伴う。

海外製の(「どこの馬の骨か知れない」)ものはデジタルなのに安くて良さそうだが、さすがにAC100Vで使うのはリスクが高い。以前も書いたが、企業などで充分な評価や検査をして使うならいいが、1個買って たまたま動いたから使って、あとで発火したら元も子もない。

(1/5 9:52) ところが、日本企業が出している(中国製)PCですら発煙したとのことなので、その国の製品を信用しては いけないのか、余程検査がズボラだったのか、あるいは日本では検査してない(単なる横流し?)のか・・・

そうすると、パナなどのものがいいことになるが、妙に高い。

もちろん、それは安全・安心を担保するためなので、暴利とか言うつもりはない。

いろいろ考えて居たら、(安い)タイマーを改造せずに使うことを思い付いた。タイマー出力のコンセントにACアダプタ(例: 12V)を繋ぎ、その出力をリレー※のコイルに繋いでon/offさせるのだ。リレーの端子(常時開放接点)は換気扇のスイッチに並列に接続する。リレーの端子にはAC100Vが掛かるが、タイマーを改造するよりはずっと危険が少ないし、接続も比較的容易だ。また、風呂を使う時などに、元のスイッチをonにすれば連続onにできるので、使い勝手が良い。

自作アンプのスピーカー保護キットで使わなかったもの(コイルは12V, 端子はAC100V対応)が余っている。

すぐに壊れるかも知れないタイマーを買うのは気が進まないし馬鹿らしいものの、そうしようかと思っていたら、更に考えが発展して(悪乗りして)、タイマー機能を自作したくなった。: 時刻は合わなくても良く、周期的にリレーをon/off(例: 15分on, 1時間off)すればいいので、それほど難しくはなさそうだ。そういうのには定番のIC(NE555)を使ったり、デジタル(マイコン)でやるのが普通だけど、555は手元にないし、マイコンなんて使うのは面倒だから(開発が面倒で、仕事じゃなかったらやりたくない。今は以前より手軽にできるのかも知れないが、コンピュータの数は少ないほうがいい)、アナログ回路で作ろうと思った。

アナログ回路より、マイコンでないデジタル、ロジック回路のほうが ずっと馴染みがあるし、作るのが楽そうだが、手元に部品が全くないので対象外だ。

回路の例などを調べたら いろいろ出て来たので安心(?)した。そして、今は事務やソフト関係の別件もあるので、TODOに書いておいて「落ち着いたらやろう」ということにした。が、昨日の夕方に暇だったせいか、「ちょっとやってみるか」と思ってしまい、(調べたページは見ずに)思い付くままに(アンプのスピーカー保護回路からのひらめきで?)回路をでっち上げてシミュレーター試したら、それなりに動きはするが、on/offの時間(長さ)が想定どおりにならず、深夜まで頑張っても解決できなかった。長さが違う程度ならいいが、長いon/off時間を実現するのが無理そうなので、実用にならなそうだった。

まったく良くある話だw

それで、やっぱり「落ち着いてからにしよう」ということにしたのだが、今朝起きる頃に駄目だった原因が分かったような気がして メモしていたら、対処方法も分かった気がした。が、どっちも気がしただけなので、試すことはせず素直に保留とした。

(下の話を分かりやすくするため、少し回路の動作を説明する。:

回路は、コンデンサと抵抗で時間(遅延)を作っている。具体的には、コンデンサに充電するまでの時間と放電する時間を使っている。

コンデンサが充電されて居ない状態では、1番目(左側)のトランジスタはベースとGNDの電位差が小さいために出力(コレクタ-エミッタ)に電流を流さない(off状態)。1番目のコレクタ-エミッタ間に電流が流れていないため、2番目(中央)のトランジスタのベース電圧が高くなるので、2番目のコレクタ-エミッタに電流が流れ(on状態)、結果的にリレーのコイルに電流が流れて接点がonとなる。

トランジスタを2個にしたのは、トランジスタは(電圧でなく)電流を増幅するので、時間を長くするために充電用の抵抗が大きくて1番目のベース電流が小さいとコレクタ-エミッタ電流が小さくなってリレーが動かないと考えたためである。2番目のトランジスタでリレーを動かせるように電流を増幅する。

コンデンサが充電されると、1番目のトランジスタのベースとGNDの電位差が大きくなってon状態となってコレクタ-エミッタに電流が流れ、2番目のトランジスタのベース電圧が低くなってoff状態となってコレクタ-エミッタの電流が止まり、結果的にリレーのコイルに電流が流れなくなって接点がoffとなる。

放電の場合はその逆である。

結局、コンデンサが充電されるまでの間、リレーの接点がonになって換気扇が回り、放電するまでの間、リレーの接点がoffになって換気扇が停まっている。

回路は上のとおりに動いたが、動作は期待どおりではなかった・・・)

On/offの長さが おかしいのは、特にoff時にコンデンサの電荷を完全に抜けないせいだと思って居る。コンデンサへのチャージ(貯める/抜く)制御(切り替え)をリレーで行っているのが良くないのではないか。いや、トランジスタの特性で電荷が充分に抜けないうちにonになるのが主因で(= 回路が悪い)、リレーは関係なさそうだ。

というのは、トランジスタのoff/onを決めるベース-GND間の電位差のしきい値は約0.7Vであるが、換気扇のoff時にコンデンサから放電している途中でベース-GND電圧が その しきい値を下回っただけで(想定では約0Vだった。 ← これが大きな間違い)トランジスタがoffになってリレーがonになってしまうので、換気扇のoff時間が想定より短くなるのだろう。

そうでなく、フリップフロップのようにon/off用の2組のトランジスタで貯める/抜くを制御すべき、あるいは、on/off用の2組のコンデンサを使うのだろうかと思っているが、こうやって書いている間にも考えが変わるくらいなので、先は長そうだ。

まあ、素直に、検索して見つかった回路を実装すればいいのだろうね・・・w

でも、なんか惜しい・もうちょっとの気がする。

そうこうしているうちに別のアイデアが出て来た。: リスクが高いから止めた海外製の安いデジタルタイマーのDC12V動作のものを選び(あった気がする)、それをACアダプタで動かし、出力(on/off)を換気扇のスイッチには直接繋がずに上述のようにリレーで制御すれば、比較的安全そうだ。(上の図でタイマーの電源をACからDC12Vに換え、リレーの電源もその12Vにしたものに相当) 少なくとも、タイマーが異常になっても発火はしない。

日和るか?

そもそも回路を作るのが目的ではないし、作るのは面倒で確実に疲れるし、「楽したらイカン」なんてクソな考えは持ってないので※w、安いタイマーが使えれば手軽だけど、(手持ちの部品だけでできそうなこともあって)ちょっと作ってみたい気持ちもある。

※むしろ、「楽するためには いくらでも苦労しろ」だ。

 

まあ「落ち着いてから」決めよう。

 

PS. 上の回路を ものすごく分かりやすく書くと、「ししおどし」だ。: コンデンサは竹筒。電流・電荷は水。竹筒に水が溜まったら下がって水がなくなり(= 放電 → 回路がoffになる)、上に上がる(→ 回路がonになる)。その上下する時間を、こっちの都合に合わせて設定しようとしているだけのことだ。 (2/4 18:51)

  •  0
  •  0

大げさな題だ。

Ceronで思わぬ情報を目にして少し慌てた。: Blu-rayディスク(以下、BD)はCD・DVD用の不織布ケースで保管すべきでないとのこと。BDの表面(読み取り面、以下同)の保護層はDVDなどより薄いため、CD・DVD用の粗い不織布では傷が付いたり保護層が歪むことがあるので、BD対応の不織布にすべきだそうだ。 (→ 参照)

僕は そんなことは全く知らずにCD・DVD用のファイルケースに入れていた(BDのリーフレットに書いてあったのかも知れないが、読んだことがないw)。まあ、BDは ほとんど持っておらず(全部で12枚。うち1枚はボックスに入っていたので対象外)、観ることも まずないが、一応、持っているものは ちゃんと保管しておきたいので、どうなっているかチェックした

結果は大丈夫だった。目視だけだが、表面に傷や歪みはなかった。ただ、今後もずっと仕舞ったままだろうから、駄目になるリスクを減らそうと思った。

事後の推測だが、実際には粗い不織布でも問題ない気がする。というのは、確かにBDの保護層は薄いけど、そんなことで駄目になったら全く手軽に扱えず、今までにかなり多くの問題が起こっているはずだけど、聞いたことがないからだ。薄くても大丈夫なのは、メーカーが強力な保護層を開発したおかげではないか。

調べたら、TDKの技術(DURABIS)が採用されたそうだ。

そして、保護層は一種の塗料だと考えると、(塗料は乾燥後に硬くなるものと柔らかいままのがあるが、)硬いものなら不織布で押された程度で跡が付く(歪む)とは思えない。傷については分からないが、頻繁に出し入れしなければ大丈夫だろう。

一つ気になるのは不織布の材質だ。不織布は「布」とは書くが、実際にはプラ(PEやPPなどのようだ)なので、それと保護層が(化学的に)反応したら駄目で、跡が付くだろう。「BD対応」というのは実は そのことかも知れないと、想像した。

それが正しいとしたら、BD対応の不織布でも、材質やBDとの相性によっては「くっ付く」可能性があるだろう。ただ、表面が平坦なので跡が付きにくく(薄く広く付く)、読み取りの問題が起こりにくいのではないだろうか。

CD・DVD用の不織布のケースで更に安全を見るとしたら、ディスクに強い力が掛からないように、ケースの左右を押さないようにすればいいのではないか。

上に書いたように ほとんど再生することがないので、BD対応の不織布を使ったケースを買うのはもったいない。最初は、いかにも柔らかそうな、ティシューをディスクと不織布の間に挟むことを考えたが無理があった。ティシューを均一に挟むのは難しく、しわや段差が却って良くなさそうなので止めた。

それから、クリーニングのカバーの不織布(上の写真の背景の白)は目が細かそうなので試そうと思ったが、ティシュー同様に挟むのが難しそうだし、本当にBDに いい(目が充分細かい・柔らかい)のか分からないので止めた。

結局、ディスクに何も接しなければ良いだろうと思い、スピンドルケースに入れ、軸の余分なところに段ボールで作ったスペーサーを挟んで ぐらつかないようにし、ケースの前後(元の上下)を挟んで垂直に立てて保管することにした。

却って悪いことにならなければいいが・・・ まあ、何年か経たないと分からない。

ところが、書いたあとで考えたら、PCの内蔵ドライブは寿命で壊れてしまって(ポータブルのDVD用しか残っていない)、そもそもBDを再生できるドライブがない。つまり、元々再生できないんだから気にする必要は なかったという、大山鳴動オチかも知れないw

 

チェックをした時に気になったのは、(BDだけではないが、)クローゼットの中の段ボールに まとめて入れていたボックス物や紙ジャケが湿気気味でカビが生えそうな感じだったことだ。※ ただ、同じように段ボールに入れていたファイルケースの中は乾燥していたのが不思議だが、ボックスなどは紙製のために湿気を吸収しやすいせいかと思っている。それで、少し高いところに移し、段ボールの口を開けておいた。: 僕としては、こっちの今後が気になる。

※その後、一部の内側にカビが生えていることが分かった。いつ生えたかは不明(旧居か こっちか)。どうすればいいのだろうか?

そういえば、少しだけど以前からクローゼットの中がカビ臭かったので、こっちで? うむ、なぜ・・・

  •  1
  •  0

濁音に苦労した話」の続きである。元の稿に加筆したように、SpotifyのAPIで取れる曲情報でもcombining charactersが使われている(= 本体と(半)濁点が分離している)場合があることが分かった。

確かに、APIとそれ以外で別の情報を格納して別々に出すのは無駄だし、合理的でない。

表示は文字列が綺麗に出ればいいが、APIで取った曲情報は自作の音楽再生履歴記録システム MlhiのDBに格納しているので、今ひとつ良くない。というのは、今はまだ完全でない(イマイチな)ので余り使っていないが、将来は自分が聴いた曲をフレキシブルに(要するに、手軽に思ったとおりに)検索できるようにする予定で、その時に、combining charactersの濁音や半濁音を含む曲が出て来ない可能性があるからだ。

そういえば、以前、なぜか検索出来ない曲があったが、それだったのかも知れない。

(1/27 14:55) ちなみに、DBを調べたところ、曲情報(タイトル、アーティスト名、アルバム名、アルバムアーティスト)のいずれかにcombining characters(濁音、半濁音)が使われているものは、延べ27曲だった。DB全体は約1万曲なので、割合は約0.3%未満と少ない。ただ、僕は洋楽やクラシック音楽を聴くことが多く、曲情報が英語のものが多いから、日本の曲での割合は数%くらいではないか。

これを解決するには、以下の方法が考えられる。

  1. DBに正規化した曲情報を格納する。
    • 今までにDBに格納した内容は正規化する。
  2. 検索時に、検索文字列とDBの内容を正規化して比較する。
    • DBには、取得した情報をそのまま格納する。
  3. × 検索時に、検索文字列として、正規化したものとそうでないものを両方指定する。
    • 正規化された文字を逆変換(分離)するのが面倒そうだが、uconvでできそうだ(本当?)。
    • 曲情報に正規化されている文字と そうでないものが混ざっているので、検索パターンが多くなり過ぎる。

Bが筋が良さそうだが、結構面倒そうだ(そもそも、DBに使っているSQLiteはUnicodeのこういう処理に対応しているのだろうか??※)。一方、前者は やればできそうなので、そうすることにした。

sqlean: All the missing SQLite functionsというソフトがあり、それは限定的なUnicode処理機能(upper/lower, like, unaccent)を持つので、SQLite自体は対応していないようだ。

ここで問題になったことがある。: 前の稿に書いたように、uconvで正規化すると、かな に正規化漏れが起こるのと、漢字の旧字体が新字体に変換されてしまう。前者は自作の処理(テーブル変換)で対応できているが、後者に対応するには、日本語の文字(漢字)を正規化しない必要がある。※

※幸い、日本語の漢字には濁点のような着脱可能な要素が なさそうなので、正規化対象から除外するだけで良い。ただ、例えば「辶」(しんにょう)のように、場合によって個数が違う点のような要素はある(→ 興味深い読み物があった)。が、それは純粋に文字の形の問題と思われ、意味や読みは変わらないので別件としたい。

他には、たまに、富と冨ののような着脱可能っぽい点はあるが、それらは同じ文字らしいし、相互に入れ替えて意味を変えることはないので(しんにょうと同様に)ヨシ、だ。

そもそも、今までに、(遊びをのぞいてw)漢字に かな のように点や丸を付けて意味などを変えたことはないし、そういうことを教わったこともないから、それで良さそうだ。

UnicodeやICUに不慣れなので、日本語を除外して正規化することができるのか分からなかったが、いろいろ調べたら できそうなことが分かった。

Unicodeにはscriptという概念があり、Latin文字(いわゆる英字)、カタカナ、ひらがな、漢字※のようなカテゴリ(Unicodeにはcategoryという概念があるが、それではない)を示すことができる。それを使って、uconvの正規化ルール(日本語除外フィルタのようなもの)を指定すればできそうだ。

※実際には、Unicodeの資料では漢字は"Han"と書かれており、おそらく中・日・韓の漢字を一緒にしたもの(≒ CJK Unified Ideographs)を差していると理解している。

具体的には、以下のコマンドで日本語(正確には、漢字、ひらがな、カタカナ)以外の文字を正規化できるはずだ。

uconv -f utf-8 -t utf-8 -x '::[ [:^Katakana:] & [:^Hiragana:] & [:^Han:] ]; ::nfc;'

処理内容は、-xの最初のルール(最初の ; まで)でカタカナ、ひらがな、漢字を除外し、残ったものに正規化(NFC)を実行する("::nfc")。

実は、上の処理には欠陥がある。おそらく韓国語(ハングル文字)はcombining charactersをバリバリ使っているはずだが、それも除外されるのではないか(ハングル文字がHanに含まれているとした場合: 実際には、scriptには"Hangul"というのがあるから、ハングル文字はHanには含まれていなさそうだ)。

が、僕の好みからして、曲名などが韓国語で書かれた曲は聴かないだろうから、とりあえずは良しとする。あと、中国語には簡体字も繁体字もあるし(それは関係ないのかも知れないが)、どうなのか想像も付かないw

上の処理は、以下のテストパターンで うまく行った。

  • パ が 神: 正規化されずに出た。
  • (A + U+0304: Combining Macron): Ā (U+0100: Latin Capital Letter A with Macron)になった。※

を使ったのは たまたま最初に できた(macronなるものが付いた単体のĀがあった)からである。この文字がどういう意味なのか全く分からないし、実際に使われるのかも知らない。

と、出来そうになって気分がいいところで、「残りはあとで」にしたw

 

参考にしたページは以下である。

uconvに指定するルールの書き方は最初と2番目(特に後者)が参考になった。最後に残った謎(どうやって日本語を除外するか? そうするパターンをどうやって書くか?)を解く鍵になったのは、最後のUnicode Regular Expressionsだった。

それについては最初の2つを丹念に読めば分かったのだろうが、余りにも知らない概念が多いうえに機能が多過ぎてチンプンカンプンだった(→ 読む気が起こらなかった)。一方で、-Regular Expressionsは馴染みの正規表現の話なので良く分かった。※ 更に、Hanが かな を含むという思い違いに気付かせてくれて、上のルールが出来た。

※実際、このページを見付けた切っ掛けは、ICU(uconv)のルールが全然思ったように動かないので諦めて、grepで正規表現で除外しようと思い、「『漢字全部』の うまい指定」があればと思って"Unicode regexp"で検索したことだ。

ちなみに、grepは-PオプションでUnicodeに対応した動作(PCRE)になる。

 

PS. Unicode(ICU)の処理には、カタカナ→ローマ字みたいなものがあって(→ Script Transliterationの表の「キャンパス: kyanpasu」)、「誰が使うの?」と思う。ちゃんと動くのならいいが、正規化みたいに中途半端だったら実装するだけ無駄だし、ほとんどの開発者は知らないので、使われない気が・・・ (いやいや、僕が無知なだけだよね)

PS2. こういう細かい話は嫌いだけど好きだ。: 実装や確認は面倒でやりたくないけど、豆知識的に調べるのは好きだ。発展したのがタモリかw

  •  0
  •  0

Chromeブラウザはメモリを大食いするのでメインには使っていないが、追跡されたくないとかプロファイルを完全に分離したい場合などに使っている。それが数日前から、妙な感じになって居た。普通は、タブを多く開くと使用メモリ量が多くなって警告メールが来る※はずなのが、来なくなったのだ。

※システム全体がメモリ不足になるのを防ぐために、定期的に「大食いアプリ」のメモリ量をチェックして出すようにしている。

うるさくなくていいけど却って気持ち悪いのでw、手で使用メモリ量を確認したら確かに少ないようだ。そういえば、近頃バージョンが上がったので改良されたのかと思った。

ただ、不思議なことに、調べてもそういう情報がない。Chromeのリリースノートのようなページには、「詳細は追ってブログに出る」のようなことが書いてあったので、これから分かるのかも知れない(→ 調べると、97での変更内容は山ほどあるので出なさそうだ)。あるいは、Linux版(の情報)は どうでもいいのかも知れないw

なお、一つだけ、外部のページ"Google Releases New Version of Chrome With Extra Security and Memory Safety Features"(2022/1)に近いことが書いてあった。以下に引用する。

... it is important to note that Chrome 97 also incorporates several upgrades to how it uses and manages memory. A common complaint that several users tend to have about Chrome is that it uses too much memory, and to fix this the new version of Chrome is no longer going to keep user profiles and settings saved after it is exited completely which will prevent these settings from using RAM in the background.

ただ、良く読むと終了後の話のようなので、違うのかも知れない。

「それじゃ、同じChromeベースのVivaldiも?!」と期待して調べたら、残念ながら大食いだった。大体、1タブで370MBくらい食う。Firefox(96.0.1)は約230MBなので、約1.6倍だ。そして、最新のChrome(97.0.4692.99)を調べたら約220MB/タブと、わずかながらFirefoxより少ない。

Vivaldi(5.0.2497.48)のUA文字列には"Chrome/96"とあるから、ベースは一つ前のようで、メモリ削減の改良がされていないのだろうと想像した。

ここで、省メモリだという評判のあるEdgeを思い出した(これもChromeベースなので、省メモリになっているかも知れないとも思った)。大嫌いなMS製だが、もし かなり省メモリなら(我慢して)使うのもありだと思って試したら、約370MB/タブ(Edge 98)とVivaldiと同様だったのでがっかりした。

どうやら、省メモリなのはWindowsでの話のようだ。想像だが、ChromeやVivaldiもWindows版とLinux版ではメモリ管理方法が異なっていて、Linux版は ずさんでメモリを浪費しているのではないか? あるいは、Windowsではアプリの使用量は少なく見えるが、実際には陰で大量に使っているのかも知れない。

まあ、いずれにしても、Edgeを使う意味は全くないことが分かった(そもそも使いたくないから、それでいいw)。

 

参考までに、以下に、各ブラウザのタブ1個当たりのメモリ使用量(増分)をまとめる。

  • Firefox(96): 約230MB/タブ
  • Chrome(75): 約220MB/タブ
  • Vivaldi(5): 約370MB/タブ
  • Edge(98): 約370MB/タブ

※すべてLinux版で、約6個のタブを開いて増加したメモリ使用量から求めた。メモリ使用量はpsコマンドの"RSS"(resident set size)を使った。

 

結局のところ、Chromeの使用メモリ量が減ったと言っても、ようやくFirefox並みになっただけなので、すぐに移る意味は ないことに気付いた。そもそも、Chromeには標準で縦のタブバーがないなど使いにくいので、移るとしてもVivaldiだ。それが更新されて省メモリになるのを待ち、それから使い勝手で判断することにした。

Vivaldi以外に ほのかに期待しているのは、同じく大食いのElectronやSpotifyも使用メモリ量が減らないかということだ。それらもChrome(chromium)を使っているはずなので、改良の効果があるのではないか。

 

以前にも書いたが、MozillaにはThunderbirdでも嫌気が差しているので、Firefoxから移れば離脱できそうだ。Mozillaは もう少し、ユーザーや開発者が喜ぶ(せめて、怒らない・使う気を なくさせない)ような進め方を考えればいいのにと思う。

  •  1
  •  0

夏が来た!
夏が来た!

上下の違いが分かる方は居るだろうか?: 同じに見えるけど違う。ブラウザ(かなり古いもの?)やフォントによっては、分かるかも知れない。

答えは、題にあるように、濁音「が」の造りである。今まで知らなかったのだが、Unicodeのひらがな・カタカナは、濁音や半濁音を半角カナ的に 本体+(半)濁点 のように分離して記述し、なおかつ くっつけて一文字のように表示することができる。Combining charactersとかいって、日本語以外でも そういう処理ができるとのことだ。

上の例の「が」は、最初の行はcombining charactersで 「か」+「”」(← 見にくいのでダブルクォートにした) で、2番目は普通に書いてある。全く区別できない。※ 良く出来過ぎていることに、マウスでコピーする時は1文字として扱われるし、等幅フォントのエディタやターミナル(コンソール)でも くっついた状態で表示される。

※おそらく、フォントの字体としては、本体に濁点を加えたものが濁音の文字になっており、combining charactersの濁点は それを再現するような位置に表示されるようにできているのだろう。ただ、この方式ではすべての濁音で濁点が同じ位置に置かれるが、そこはフォントの 描き方でうまく合わせたのだろうか。

↑ ちょっと確かめたら、そう単純なことではないようだ。というのは、下の左図のように、「ヾ」と「ヷ」では濁点の大きさや形が明らかに違うからだ。ということは、フォントに濁点を付けるための情報があるのか、表示する時に、combining charactersの濁点が付く場合は自動で濁音の字に変換されるのか。見たところ、濁点の形が微妙に違う気がする(特に、線の太さ)ので前者なのかも知れないが、本当に そこまでやっているのかという気はする。どちらにしたって、「余計なところに力を入れ過ぎていないか?」と言いたくなる。 (1/22 5:18)

その後、文字に色を付けて濁点を重ねて比べたところ(下の右図)、同じ文字の濁点の形状は、combining charactersでもそうでなくても同様だが、異なる文字同士では異なっている(この例では、「ヾ」の濁点は「ヷ」のより大きい)ことが分かった。 (1/22 14:19)

僕が見付けた唯一の識別方法は、エディタ(ペーストする)で濁点側から1文字削除することだ。Combining charactersの場合は濁点だけが消えるが、そうでない場合は全部消える。

そして、今回の切っ掛けに関係することは、どういう訳か、Spotifyで出る曲情報(タイトル、アーティスト名、アルバム名)※の中に、本体と濁点・半濁点が分離して記述されたものがあるのだ。全部ではなく、たまにあるのが不思議だ。特定のレーベルという訳でもない気がするが、老舗(例: ビクター、ソニー)や昔の曲に多い気がしている(と書きつつ、1990年代の(一番下の図)もあるので関係ないかも)。

想像だが、レーベルが曲情報を電子形態に登録する際、打ち込む人の癖などで分離してしまったか、それ以前の半角カナも使うシステム(そういうものがあったかは不明)から変換した時に、濁点・半濁点を統合しないままだったのではないか。

※詳しく確認していないのだが、同じSpotifyでも、アプリから取れる情報(Dbusのイベントで取れるもの)とAPIで取れる情報の記述が異なるようだ。前者は分離していることがあるが、後者はそうではない。 ← どちらも同じように分離している場合があることが分かった。例: 飯島真理 「palette(パレット)」(2007)の「パ」。 (1/25 16:31)

それで何も問題が起こらなければ気付かずに過ごせたのだが、自作のSpotifyのミニプレーヤーMinispが駄目だった(これが発端である)。次の左図のように、combining charactersである「が」のあとに空白が出来て、半角カナ的な見苦しさになってしまっている。今見ると、本体(か)と濁点の間隔も少し広い。本来は右側のようになるべきである。

どうやら、表示に使っているTcl/Tk(wish)がcombining charactersに対応していないようだ(調べた限りではTcl/Tkのページの"Unicode combining characters"の項にはコメントだか状況説明が書いてあるだけのようだし、 そういう設定や属性などがなかったので非対応なのではないか)。

これを何とかしようと調べたら、Rubyのソフト(unicode_utils)の紹介が出て来たものの、インストールするのが面倒なので試行錯誤したら、既存のプログラム iconvでは駄目だったものの、既に入っているパッケージ icu-devtoolsのuconvでできることが分かった。

Combining charactersを まとめる(くっついた文字にする)のは「正規化」という処理で、uconvのマニュアルに例(下記)が書いてあった。

uconv -f utf-8 -t utf-8 \
  -x '::nfkc; [:Cc:] >; ::katakana-hiragana;'

上は他の処理も混ざっているので、以下の例のように、曲のタイトル、アーティスト名、アルバム名をそれぞれ正規化してから表示するようにし、上の右図のように解決した。

echo "夏が来た!" | uconv -f utf-8 -t utf-8 -x '::nfc;'
夏が来た!

※正規化処理は、マニュアルではNFKCだが、調べたらNFCのほうが良さそうなので そうした。この辺りは全く詳しくないので手探りだ。また、上のコマンドでnfc前後の :: ; は なくていいようだが、例にならって付けている。

今 上の参照ページを読んだら、NFCでも今ひとつな場合(「例6: 神と神」)があって気に入らないが、仕方ない(レーベルも、旧字体は余り使わないだろう)。一番いいのは、正規化しなくてもwishで綺麗に表示できるようにすることか。

あるいは、(一番最初に考えた方式の、)uconvでなくプログラムで変換するのがいいか。ひらがな とカタカナだけの対応になるが、濁音・半濁音と そうでない音の文字の順序には概ね規則性(元の音のコード= 濁音-1, 半濁音-2)があるので、それでcombining charactersを くっついた文字に置換するのだ。これなら漢字の旧字体は問題ない。

というか、いちいち計算するのでなく、今の追加処理のテーブル方式で全部処理するほうが良さそうだ。濁音・半濁音は多くないから、テーブルを作るのは容易だ。 → 基本的に、uconvを使うのを止めて追加処理だけにすればできるので、早速そうした。

この方式なら、あとから追加変換が必要になことが分かっても、変換テーブルに追加するだけなので容易だ。 (1/21 17:05)

ところがどっこい!w

下の左図の「グ」のように、なぜか、頑固に正規化できない文字がある(図で「ベ」は くっついているので、処理されていない訳ではないことが分かる)。

更に調べたら、どうやらuconv(使っているのは uconv v2.1 ICU 66.1)が正規化しない(素通しする)文字があるようだ。ひらがな・カタカナの濁音・半濁音について調べたところ、以下の文字が駄目だった(正規化されずにそのまま出て来た)。

ど ば べ ぼ ぱ ぺ ぽ ガ ギ グ ズ ゼ ゾ ダ ヷ ヾ

ところで、上の最後のほうにある見慣れない文字、Unicodeにある「ヷ」、「ヸ」、「ヹ」、「ヺ」って実際に使われたのだろうか? どういう読み?? 謎だ。 (→ 4/1に出た、参考になるページがあった。)

その後、PHPの国際化関数のTransliteratorのtransliterator_transliterate()でuconvと同様の正規化処理を試したら、なぜか上の文字も正規化できた。よって、下ではICUやUnicodeのライブラリの問題と書いているが、uconvの問題の可能性が高い。だが、どうしたらこういう抜けが起こるのか見当がつかない。 (1/27 16:08)

実際には、原因はuconvではなく、それが使っているICUやUnicodeのライブラリの問題だろう(日本語に詳しくない人が作った??)から、パッケージを(Linuxディストリビューションのものでない、)オリジナルの最新に入れ替えるか、設定とか調整すれば直せる気はするのだが、パッケージの交換は あとあと面倒になるのでせず、設定・調整はuconvなどのマニュアルを読んでも分からない用語が多くて どうすればいいか分からなかったので、以下のような力技で対応した。

  1. 起動時(初期化)
    1. uconvで正規化できない濁音・半濁音を調べてリストを作る。
    2. それらの正規化後の文字のリストを作る。
  2. 曲情報(タイトル、アーティスト名、アルバム名)を表示する前
    1. uconvで正規化する。
    2. uconvで正規化できなかった文字がある場合は、正規化した文字に置換する。

これなら、将来ICUやUnicodeのライブラリが更新されて、すべての濁音・半濁音が正規化できるようになれば(なんか、永遠にそうならない気が・・・w)、自動的に追加処理が不要になる。

処理を実装し、上の右図のように、駄目だった文字が ちゃんと表示され、(今のところは)一件落着となった。ただ、いつものように、他にも何か問題がありそうなので、表示やログを注視しながら音楽を聴いている。

これ、日本語以外でも あったらお手上げだが、読めなくて気付かないだろうから良し?www

 

PS. 中程("1/21 17:05"の辺り)に書いたように、これを書いたあとで、実は、uconvを使うのでなく一番最初に思い付いた単純なテーブル変換方式が一番良かったというオチだった(今のところは)。Unicodeの考えは基本的には いいと思うが、(何かで必要なのだろうが)複雑な概念をいろいろ作り出して、それが日本語や実際の用途に合わない、あるいは完全な実装ができていないために、いろいろなところで苦労してそうなのが残念だ。

  •  0
  •  0

元日に実家に行ったら、母が「スマホにしようと思う」とか言い出したので驚いた。そもそも、使えるあてもないのに、なぜそんな考えになったのか分からなかったが、下のまとめを読んで分かった。

【悲報】ガラケー歴20年目のワイ。ドコモから最後通告が届く

ドコモが、ガラケーを持っている人に脅迫的な案内を出しているからではないか。古い端末が修理できなくなるのは当たり前のことで仕方ないが、それとスマフォへの移行は関係ない。ドコモが従来型の端末を出して(あるいは、他社の製品を)、それを紹介するだけでいいのに、余りにも恣意的にスマフォに移行させて、金を巻き上げる魂胆が透けて見える。

この件については、意図しているのか単に頭が悪いのか、以下の異なるものをごちゃまぜにしているように思う。

  • ガラケー終了 (メーカーのやる気の問題)
  • 3G終了 (電波・キャリアの問題)
  • i-mode終了 (ドコモの都合)
  • スマフォブーム(に乗じて収益を増やしたいキャリアの魂胆)

最初の2つについては、4Gなどで使える、ガラケーでもスマフォでもない従来型の端末、フィーチャーフォンを出せばいいのだ(今は1機種だけあるようだ)。高齢者はアプリとかの高機能なものは要らなくて、電話機能に加えてメールと写真程度で充分ではないか。

でも、それらすらガラケーの範疇になるのかも知れない。であれば、これまでガラケー・i-mode※で たっぷり稼いで来た責任があるのだから、ガラケーを使いたい人が居なくなるまでスマフォを押し付けようとすべきではない。それと電波(3G→4G)は全然別なのに、分かっていない人には もっともらしい説明になるのが嫌らしい。

これは、良くある詐欺の、「これからは*が使えなくなるので、これを買って下さい」みたいだ。

※i-modeについては、勝手な(まさにガラパゴスそのもの)規格・仕様(そのために、世の中の標準的仕様と合わないことが多くて移行が難しいだろう)をでっち上げた責任は大きい。ユーザーが不利益を被らずに終了させる責任は大いにある。

その点、Apple・ジョブズ(iPhone)は(いくら大嫌いでもw)すごい。まあ、少なくとも3Gがなければできなかっただろうし最初は無理があったけど、標準規格ベースで あれだけのもの(サービスと言える)を成立・普及させたのだ。

例えば、3Gが終わって使えなくなるiPhone(Androidも)の機種はあるが、それらで使えていたサービスが使えなくなることは まずない。対応する機種に換えれば それで済む。ごく当たり前のこと・考え方ではあるが、できない会社は多い。

それにしても、これからしばらくは、ガラケーしか使えないのにスマフォを押し付けられて文鎮化させてしまう、あるいは、詐欺(フィッシング、ガラケー・3G詐欺なんてのも出そうだ)などに引っかかる高齢者、ガラケー難民(?)が増えそうだ。全く無責任だ。

そもそも、高齢者に限らず、今もこれからも「普通の携帯電話」が必要な人・場合は多い※のに、それを切り捨てるのは正しい進み方ではないと思う(まあ、会社自体が正しい進み方をしていたかという疑問はあるが)。

※例えば、「(それしかないので)いつでもどこでもデカくて重いタッチパネル端末を使え」ってのは、無理もいいところだ。

 

(てな、全然おめでたくない話を年頭から書くのは さすがに気が引けたので保留していたが、日が経った(それでもイライラは減らない)のと、丁度 最初に挙げたまとめが出て状況が分かった気がしたので、出した。)

 

PS. 母については、以前聞かれて、(本文にも書いた、)従来型の端末があることを教えて居たのに、再びスマフォなどと言い出したので、そこでブチ切れた。たまたま とか高齢だからという訳ではなく、あの人は、昔から人の話を聞き流す(賛成でなくても分からなくても、賛成のような分かったような返事をする)癖があり、それを目の当たりにして、昔からのトラウマが出たような(フラッシュバック?)嫌な気分が続いている。

スマフォに移るにしても、そういう考えになった理由や経緯を説明してくれれば まだいいのだが、あの人は僕が子どもの頃からそれをせず唐突に言い出すので、いつも混乱させられ、嫌な目に遭って来た(説明不足のために、こっちが被害・誤解を受けた)。

あと、ガラケーですらまともに使えない癖に、ある時、「こんなのテキトーに使えば使える」とか口走ったのにも大変ムカついた。テキトーに使える機械なんてない! だったら、スマフォもそうすればいいのに その気はなく、以前僕の余ったものを試すか聞いても乗り気でなかった。「(その癖に、)なぜ今スマフォなんだ!」と、正月から何重ものイライラが爆発した。

 

(18:25 わずかに変更・修正)

  •  1
  •  0