昔の最近の出来事(2023.07)

2023/07/31

テレワーク。早めに終了。

「Lv1魔王とワンルーム勇者」ってアニメ。 なんかこういう魔王のキャラ設定ってどこかで見た事あるような...?と思ったのですが、 「ジャヒー様はくじけない!」がこんな感じだったなと思ったり。 そういやなんか声似てないか?と思ってWikipediaを調べてみたら 同じ声優さん (参考Wikipedia)でした。

そういやEmacsの Haiku OS へのポートって29からだよね?って確認してしまうくらい、 Emacs29.1リリースのニュースサイト記事で触れられていない...

Windows11の Segoe UI Emoji をモノクロで表示してしげしげと眺めた事無かったな?と思い表示してみたり。

emacs-w32(Emacs29.1)でSegoe UI EmojiをWindows11上でモノクロ表示

顏の絵文字はカラー表示と違って白目が無いデザインの為か、カラーとは違うフォントのように感じます。 一度カラーで見てしまうとモノクロは何の絵文字か識別できないものも多いなぁと 改めて感じたりも。赤い林檎(🍎)と青林檎(🍏)とかもカラーで表示される事が前提だよね? と思ったりします。因みにどちらの林檎絵文字も Unicode 6.0で入ったらしい。 2010年に仕様としてリリースされたようです。 以前知った 記事の通り、 スマホとかでカラー絵文字として世界的に使えるようになった黎明期なので、 カラーじゃない場合はあまり考えていなかったのかも?とは思ったりも。 他にも、カラー表示が前提だと困る絵文字に「国旗」があるかと思います。 Segoe UI Emoji は旗のデザインは行なわずに「JP」みたいに 国名コードで デザインされていますがモノクロ表示の事を考えると正解と思います。

2023/07/30

AM中に起床。

掃除したり洗濯したり。

Emacs 29.1がリリースされた模様(Emacs 29.1 released)。 29.1-RC1 リリース後に少しだけ修正コミットがあったのですが、RC2は経由せずにそのまま29.1としたようです。 ともあれ長いリリース作業おつかれさまでした。

という訳でIMEなどパッチをあててビルドしてみたり。 RC1から関係する箇所の変更は無かったので特に問題無くパッチはあたり エラー無くビルド完了。 Cygwinの emacs-w32 29.1がパッケージリリースされるまで普段使いでテストしてみよう。

ノートPCに色々ツールを入れたりCC2からファイルをコピーしたり。地味に時間がかかる...😓

そういやセブンイレブンで うなぎ弁当 が売っていたのですが お値段約2500円也。 近年は1500円でギリ試してみようと思う事もありましたが もう手が出ない😓。 ウナギの完全養殖は実現されていますが、Webで調べてみるとまだ量産コストがかかるらしい。

2023/07/29

AM中に起床。

散髪にお出かけ。午前中に行ったのですが暑すぎる。

ノートPC環境。先日のEmacs起動時のtree-sitterのワーニングは DLLをビルド&インストールする事で対応。

今回買ったノートPCですが、Lenovo製で CPUは i7-13620H、 GPUはGeForce RTX4060 LAPTOP GPU というスペック。 何気に今メインで使用しているデスクトップPCよりも性能が高いかも知れず。 購入検討中にWebで下見をしていて、そういや最近のCPUはPコアとEコアがあるらしいなぁ? (以前のメモ)とか、RTXってどんなもの? ってのを見る事ができそうな ノートPC(カテゴリ的にはゲーミングノートPCのようですが) があるっていうのをたまたま知ったのと予算的に許容できる(いや、発作的に許容した)ので選んだ感じです。 で、実際に動かしてみると思ったのと違っていた点があって、ノートPC本体のディスプレイ(Full-HD 144Hz)は CPU内蔵GPUで表示されていて、RTX側は外付けのディスプレイでしか表示できていない というのを、メガデモ表示確認していて気づきました。 なので、ノートPC本体だけで使っている場合はRTXは完全に休んでるという事になります。 そういや以前デスクトップPCで グラフィックボードが載っているのにオンボードのビデオ出力を繋いでいる事に気づかない人が居る って話に本当か?って思った事がありましたが、 今回のノートPCのような感じだと、気づかない人が居てもおかしく無いかも?とは思ったりも😓

CPU内蔵GPUとRTXの切り替え。本当にそんな事あるんだっけ?と思い調べてみると、 どうやらプリインストールされている専用アプリを使って切り替えなくてはならない模様。 アプリでは便宜上、「内蔵型グラフィックスカード(CPU内蔵GPU)」と「専用グラフィックスカード(この製品ではRTX4060)」 と定義しているようです。 デフォルト設定は先に述べた通り、「ノートPC本体のディスプレイは内蔵型GPU、外付けディスプレイは専用GPU」と なっているようですが、「全て専用GPUにする」とタスクマネージャ上も 内蔵GPUは負荷表示されなくなり、 本体ディスプレイもRTXで表示されるようになりました。流石にGPUを使うのに外付けディスプレイ必須って事は無いか。 失礼しました😅。 でも、デフォルト設定では 本体ディスプレイは CPU内蔵GPUで表示されているので、 やっぱり気づかない人は一定数居そうな予感はします。

CPUはIntelの仕様によると (参考) Pコアは6個、Eコアは4個で、物理コア数は合計10個、論理コア数(スレッド数)は 2*6+1*4=16という事になるみたい。デスクトップPCの i7-7700K(基本速度4.2GHz)と ノートPCのi7-13620H(基本速度2.4GHz)とで Emacs29.1-rc1の makeにかかる時間を 調べてみたら以下のような感じでした。

  |---------------------------+-----------------------+--------|
  |                           | time make -j $(nproc) | 速度比 |
  |---------------------------+-----------------------+--------|
  | i7-7700K(基本速度4.2GHz)  | real    2m49.890s     |   1.00 |
  | 物理Core 4                | user    11m36.482s    |        |
  | 論理CPU  8                | sys     2m21.168s     |        |
  |---------------------------+-----------------------+--------|
  | i7-13620H(基本速度2.4GHz) | real    1m43.670s     |   1.64 |
  | 物理Pcore 6 + Ecore 4     | user    6m19.945s     |        |
  | 論理CPU  16               | sys     0m59.099s     |        |
  |---------------------------+-----------------------+--------|

因みに「基本速度」はタスクマネージャーに表示されている値を記しました。 実際には i7-13620H の方は4GHzを超えて動いたりする事もあるようです。CPU使用率100% になると 3.8GHz~4.0GHzで動いているようです。 さておき、環境の微妙な違いはあるかも知れませんが、実時間で 1分くらいの差があるので ノートPC→デスクトップPC の順で確認すると デスクトップPCの方が物凄く遅いように感じます😅。 恐るべし。てかなんかコワっ

Cygwin 3.4.xのメモリリークの件はWindows11でも再現するようです。 まぁ今の所Cygwinが被疑箇所なので再現してくれないと困りますけどね😓

「Windows11の Segoe UI Emoji」がサポートしているUnicode絵文字。 先日のEmacsの表示は設定が悪くて表示可能な絵文字が豆腐になっていました。 どうやら Unicode 14.0 までは文字があるようです。 Unicode 15.0の分はまだ入っていないみたいです。

emacs-w32(Emacs29.1-rc1)でカラー絵文字をWindows11上で表示その2

昨日豆腐になっていた分については既にサポート済み文字でした。 スクリーンショット画像の、例えば「FAE8」(#1FAE8の事)に対応するのは震える顔(🫨) なのですが、Unicode 15.0の文字なので (参考) Windows11の Segoe UI Emojiでも(まだ)表示できません。 Windows11の開発版では表示可能になっているようです (参考記事)。
因みに、我が家のEmacs設定では Noto Emojiにフォールバック しています(勿論 Noto Emojiは自分でフォントインストールする必要があります)。 スクリーンショット画像でモノクロ表示されている文字は Unicode 15.0の分って感じです。

Windows11機からNASドライブの共有フォルダが見えないなぁ?と思って調べてみたら、 何やら意図的に設定変更しないとダメらしい(参考)。 そういうもんだっけ? 以前にも明示的に設定した記憶は無いのですが....? 忘れているだけかも知れませんけれども😓

2023/07/28

テレワーク。早めに終了。

まだ準備は整っていないのですが、Windows11のノートPCをぼちぼち弄ってみたり。 今回 見たかったのはEmacsでカラー絵文字がどうなるか?でした😅
CygwinのインストールとEmacsをビルドできるだけのツール群を入れて、Emacs-29.1-rc1を パッチをあててビルド。tree-sitter関連でワーニングメッセージが出るものの 一応起動はできました。emoji-listコマンドを実行したのが以下。

emacs-w32(Emacs29.1-rc1)でカラー絵文字をWindows11上で表示

絵文字フォントはWindows10と同じく「Segoe UI Emoji」設定のままですが、 フォントファミリ名はそのままに いわゆる Fluent Emoji(以前のメモ)となるようです。 所々表示できていない文字があるのですが、Windows10ではこれらの文字は表示自体が スキップされていた(emoji-listコマンドがフィルターをかけてるっぽいですが どういう仕組みなのかよく解っていません😅)ので、今後サポートされるのかも? 因みにレンダリングは COLR/CPALテーブル方式で行なっているので、 以前のメモで想像した通り 「Flat」でレンダリングされているものと思われます。

2023/07/27

テレワーク。早めに終了。

この前の休みの時に散財した品を開封。Windows11のノートPCを購入してみました。 CC2のバッテリー膨張が気になってきたので、セカンドマシンとしての交代をしておこうという感じ。 でも色々準備が足りなくて、電源入れてちょろっと動かしただけ。

2023/07/26

テレワーク。気持ち早めに終了。

調べ事をして終了。

2023/07/25

テレワーク。気持ち早めに終了。

Inkscapeの1.3が7月23日付けで出ている模様。 Edgeでの表示が壊れているので出ているアナウンスを見逃していました😓。 パターンフィルが良いかも。

2023/07/24

テレワーク。早めに終了。

TwitterがXになるらしい。ロゴはXになっているようですが、ロゴだけが変わってサービス名は Twitterのままなのか、Twitterというサービス名も変わるのかはよく判らず。 ただ、「ツイートする」っていう言葉は 短文型のSNSに投稿する事を指す言葉として残りそうな気もします。

2023/07/23

AM中に起床。

ちょろりお出かけ。散財。詳細は後日。

Emacs 29.1 RC1が来た模様 (Emacs 29.1 RC1 is available)。 今までの感じからいくと、一週間くらい置いて問題無ければ rc1のバイナリそのままを ファイル名変更してリリース版に昇格する感じかな?
29.0.92のIME等パッチを 29.1 RC1 にあててビルド。少しズレてる箇所があるようでしたが、 特に問題無くビルド成功。ちょろっと立ち上げてみた感じではいきなりSegfaultしたりはしなさげ。

Cygwin 3.4.xのメモリリーク調査。 リストを追加していったり、文字列を段々長くするようなコードを無くすように vector型で予め最終サイズの配列を作っておいて内容を更新して最終データを構築 するようにしてみたものの状況はあまり変わらず。 やり方を変えるとそちらは大丈夫みたいな事があるかな?と思ったのですが、そうはうまく行かない感じ🥺

東京MXの日曜ゴールデン枠で、放送延期されていたニーアオートマタのアニメ 9話~12話が放送されてたり。 一応放送枠を確保したんだと思ったのですが、どうやら第2クールが制作される事になっているらしい。 ほぅ.... そういや最後の人形劇で「またみてね」って書かれてて、最後なのにまたってどういう事だ?...と 思ったのですがそういう事だったのか? 判りませんけど。

2023/07/22

AM中に起床。

掃除したり。

Cygwin 3.4.xのメモリリーク調査。 恐らく SVGとは関係無いところで(ところでも?)リークしているのですが 関係する操作はなんなんだ?と思ったり。 SVGデータを直接生成する為に文字列操作を行なっているだけにしているつもりなのですが、 頂点データのリストを文字列化するのに

 (let ((plist-str ""))
        (dolist (p svg-poly-list)
          (setq plist-str
                (format "%s %s %s" plist-str (car p) (cdr p))
                ))
      :

みたいなことはやってます。この場合、古い文字列 plist-strに 1つ頂点が追加された新しい 文字列が生成されますが、plist-strが新しい文字列に参照を切り替えた所で 古い文字列の領域が紐切れの未参照領域になります。 ここで紐切れの未参照領域が再利用されないような事があればメモリリークする事にはなると考えられます。
あるメモリ領域を 再利用無しで前述コードのように段々文字数が増えるような文字列を割り当てる場合を 想像すると、

    メモリ使用状況(□未使用,■使用,△未参照ゴミ)
0   □□□□□□□□□□□□□□□□□□□□
1   ■□□□□□□□□□□□□□□□□□□□
2   △■■□□□□□□□□□□□□□□□□□
3   △△△■■■□□□□□□□□□□□□□□
4   △△△△△△■■■■□□□□□□□□□□
5   △△△△△△△△△△■■■■■□□□□□

みたいな感じで、見掛け上どんどん未使用領域は減っていくのかなと思います。
直ぐに再利用する例を考えてみると、

    メモリ使用状況(□未使用,■使用,△未参照ゴミ)
0   □□□□□□□□□□□□□□□□□□□□
1   ■□□□□□□□□□□□□□□□□□□□
2   △■■□□□□□□□□□□□□□□□□□
3   △△△■■■□□□□□□□□□□□□□□ ※ここは長さ3の文字列が生成されるまで前の長さ2の領域は必要
4   △△△△△△■■■■□□□□□□□□□□ ※ここも長さ4の文字列が生成されるまで前の長さ3の領域は必要
5   ■■■■■△△△△△□□□□□□□□□□
6   △△△△△■■■■■■□□□□□□□□□
7   △△△△△△△△△△△■■■■■■■□□
8   ■■■■■■■■△△△△△△△△△△□□
9   △△△△△△△△■■■■■■■■■△□□

みたいな感じになるかな? 文字列は段々長くなるので最終的な長さになるまでは未使用領域が 減っていきますが、その後 生成した文字列を使用しなくなった時点で全て「△未参照ゴミ」化 するので、メモリリークする事にはならないだろうと思います。
で、Cygwin3.4.xでリークが発生するようになったので、そこから考えると Emacs上で解放忘れが無いのであれば、Cygwinのfree()が何かしらバグっているとか、 free()された領域の malloc()、realloc()による再利用が うまく行なわれていない可能性に疑いを持つ所です。 でも、単純なmalloc(),realloc(),free()を使ったテストコードでは再現できていないという感じ。 また、sysmonのテキスト描画モードであれば大丈夫だったり、普段使いでEmacsを数日起動しっぱなしで 使用していてもプロセスサイズが爆増する事は無い所を鑑みると ピンポイントで地雷を踏んでいるように思います。 ただ、ピンポイント過ぎて捉える事ができていません🥺

2023/07/21

テレワーク。気持ち早めに終了。

gdbで思った位置にブレークポイントが設定できない件は ただの見誤りでした。 ブレークポイントを仕込んだ行は よく見ると #ifdef ブロックで有効ではないコードの行でした。 結構大きな #ifdefブロックで ごっそりコードが無くなってるのに気づいてなかったというオチです。 修行が足りません😓

2023/07/20

テレワーク。気持ち早めに終了。

Cygwin 3.4.xのメモリリーク調査。 先日の ビルドしたEmacsのバイナリを調べようとしたところ gdbで思った位置にブレークポイントが設定できない件。 全然関係無い流れで configureオプションに --with-dumping=unexec を追加したところ、 思い通りの行番号にブレークポイントを設定できるようになったような? 因みに、 --with-dumping= は指定しない時のデフォルトは --with-dumping=pdumper と同じ模様。

2023/07/19

テレワーク。気持ち早めに終了。

普段使いで立ち上げているEmacsが長時間固まる件。多分これだったのだろうという原因。 先日予想したのとちょっと違うかも知れませんが、フォントのサーチに 時間がかかっているものと思われます。 絵文字フォントを設定した際に「▀(U+2580)~▐(U+2590)」の文字コードが テキスト文字用フォントと異なるフォントで表示されて等幅にならない事がありました。 それに対応する為に前述文字コードのフォントをリセットするという設定を行なっていたのですが (参考)、Cygwin3.4.xにすると何故か フォントを 探すのに異常に時間がかかるようになっているようです。仕方ないので、

  (mapcar
   #'(lambda (charcode)
       (set-fontset-font t charcode "MS Gothic" nil 'prepend)) ;;ブロック文字は半角幅になるフォントを設定する
   '(#x2580 #x2581 #x2582 #x2583 #x2584 #x2585 #x2586 #x2587 #x2588 #x2589 #x258A #x258B #x258C #x258D #x258E #x258F #x2590))

のように、明示的にフォントを設定すれば時間はかからなくなるようです。 なんかこれ、もうちょいなんとかならないものなのだろうか?とは思います。

そういえば、数日前からInkscapeのページをEdgeで表示すると 壊れた表示になっています。何故すぐに修正されないのだろう?と思っているのですが、 どうやらGoogleChromeだと大丈夫みたい。だからか。

2023/07/18

テレワーク。早くもなく遅くもなく終了。

Cygwin 3.4.xのメモリリーク調査。 もしやこれか?と思ってELISPのコードを変えて反応を見てみるも変わらず。しょんぼり🥺

gdbで観察しようと思い、コマンドライン起動したgdbのプロンプトからブレークポイントを 行番号指定で設定しようとしたのですが、 何故か思った行とズレた位置に設定されたり。実際に実行するとブレークポイントで停止するのですが、 やっぱりズレた位置で止まってて、どうにも思った位置にブレークポイントを設定できないようだったり。 何だこりゃ?🤔

2023/07/17

AM中に起床。

掃除したり洗濯したり。

Cygwin 3.4.xのメモリリーク調査。 念のためというのも含めて インストール済みのパッケージを全て再インストールしてみたり。 でも状況は変わらず。ただ、パッケージの emacs-gtk(28.2)でも再現しているので、 野良ビルドやemacs-w32だからという原因では無さそうという事だけは言えそうかも?
Cygwin 3.3.6だと再現しないってのを再度確認しようと思ったのですが、Cygwin本体以外の いくつかのパッケージを先祖返りさせなくてはならないという自動判定が行なわれてしまい、 Cygwin本体だけをダウングレードする事ができないようだったり。むぅ、退路を断たれた....🥺

もう一度考え直し。emacs-gtkでも再現するという事は、やはり RSVGの表示の関与が一番強いと 考えられるのですが、


ってパターンがあり得るかなと。
一応Cygwin側のコードも眺めてはみてます。3.3.xのメモリ割り当てに関するコードは winsup/cygwin/の下に直置きされていたのが、3.4.xではwinsup/cygwin/mm/ に移動されている ようです。しかし、コードの中身自体は定義の参照場所の変更に合わせてコードを直したという 感じに見えて、何かやってる事を大幅に変えたという感じではないように思ったりも。 となると、librsvgの方も調べてみたくなるのですが、 最新のlibrsvgをビルドしようとすると依存ライブラリが色々古いと言われてビルドに挫けました😖

先日も確かめていたのですが、SVG画像を表示しなくてもリーク自体はしていて、それはemacs-gtk(28.2)でも 起こっているようです。実際にSVGデータが画像としてレンダリングされるのは 関数insert-image でカーソル位置に画像を挿入する時で、それまでは単なるELISPのリストの中に 文字列としてSVGデータが保持されているだけとなります。 先日 SVGデータを文字列で直接生成するようにしたのは、svg.elやdom.elを被疑対象対象から 外す目的もあった訳ですが、一旦SVGからは離れて考えた方が良いのかも?と思い始めたり。 という事であれば、観察向けのdebug仕込みはEmacsの中だけに行う事でなんとかならないかなぁ?🤔

そういや毎秒更新の為に run-with-timer を使って定期的なバッファ表示の更新を行なっているのですが、 時間を縮めれば加速できるんじゃね?と思って、1.0秒待ちだったのを0.1秒待ちに変えたら 少しだけ加速したような気が。だったらいっそのこと 1フレーム分のデータを作る関数を dotimesとかで3600回繰り返せば 実質1時間分(1.0秒待ち換算)を全力実行する訳だから、 あっという間にプロセスサイズが大きくなるハズ。 と思って試してみると、全くプロセスサイズが変化しない事が判りました。むむっ? もしかして run-with-timer との組み合わせに秘密があったりする? だとしても、SVGじゃない文字表示だとプロセスサイズ増加が起きないというのは納得できませんが🤔

そういや run-with-timer は、時間と実行したい関数を指定すれば何やらうまく関数が実行される というテンプレート的な使い方しかしていなくて、 どういう仕組みで非同期っぽい動作を実現しているんだ?と改めて思ったりも。 少し見たのですが まだよく判らず。

run-with-timerは一旦置いといて、dotimesで繰り返した時に様子が違うってのはなんなんだ?と思い、 sleep-forを挟んでみたり messageでミニバッファに出力してみてても様子が変わらず。 で、以下の様に read-from-minibuffer で入力待ちを行うと様子が変わる事が判りました。

    ;; 抜粋
    (dotimes (n 1000)
      (sysmon-main)
      (read-from-minibuffer (format "%d:" n))
      )

続けるにはリターンキーを押すだけですが、描画(テキスト文字の情報表示だけですが)が行なわれて プロセスサイズ増加も再現するようです。そしてSVGじゃない文字表示だとプロセスサイズ増加も起きない。 という訳で、ELISP上で絞り込みができそうな気がしてきたようなそうでもないような。
スクラッチバッファで関数をこねくり回しながら動きを観察してみたのですがどうにも挙動が不信な感じ。 弄っている間も再現したりしなかったり、ほぼ何もしていないコードでも再現する事があって、 変なのは確からしいのですが何が起こっているのかはさっぱり判らず。挫けそう...🥺

普段使いで立ち上げているEmacsが長時間固まる件。もしかしてフォントのロードに時間がかかっている? と思ったり。ダーク系のテーマとして leuven-dark を使っていたのですが、 Cygwinの入れ替えとかでEmacsを立ち上げ直した時に、別のも試してみようと manoj-dark を選んでみたら、 つっかかりが若干軽減しているような気がしたりも。 ふと思ったのが、テーマによってはfaceを変更する際にフォントを変えるものがあるのですが、 例えば別の事をしていてしばらく操作しなかった場合などに、フォントキャッシュが時間切れで 再ロードが必要になると時間がかかる事があったりする?と思ったりも。こちらはしばらく様子見。

2023/07/16

AM中に起床。

Cygwin 3.4.xのメモリリーク調査。 一晩経つと、memory-reportのメモリ使用量と 関数memory-limit によるプロセスサイズとは 大きく乖離しているので、ELISPの管理下に無いメモリが解放されていないのだろうと考えられます。

先日、svg.elを使わずにSVG画像を生成するコードを試してみたのですが、 厳密に同じ画像を生成するコードではなかったので作り直し。 文字列操作だけでSVG画像を生成するようにしてみたので観察開始。どうなるか....

数時間試してみたけどプロセスサイズの増加はやっぱり起こっているようです。 何かしらワークアラウンドになる事を期待したのですがダメそう。うーむ🤔

それにしても、普段使いで立ち上げているEmacsが長時間固まる事の方が段々と許容できなくなってきた気も。

2023/07/15

AM中に起床。

Cygwin 3.4.xのメモリリーク調査。 今更ですが、Emacsでのメモリ使用量を調べる方法に memory-reportというコマンドがあるのを知ったり。 Emacs内で何にどれだけメモリを使っているかが表示されるようです。 ガベージコレクトを実行した後の値を表示しているようなので、Emacsの管理下に置かれたオブジェクト のメモリ使用量が表示されているものと思われます。 もう一つは 関数memory-limit で、Emacs自身のプロセスサイズが KiB単位で返ってくるようです。 前者の memory-reportコマンドの結果と 関数memory-limit の値とのギャップがメモリリークに 対応する値という事になるのかしら? と思い、再度観察中。

SVG画像を動的生成する為に lisp/svg.el を利用すると lisp/dom.el や lisp/xml.elが require されます。で、観察の結果から 関数insert-image で実際に画像として表示しなくても、 svgデータを生成する段階でメモリリークしているんじゃなかろうか?という疑惑が湧いていました (先日からそういう疑いがありました)。 単純なループで繰り返しただけではリークが再現しなかったのですが、 逆にsvg.elを使わずにSVG画像を表示するだけだとリークしないのか?というのを確かめてみる事にしてみたり。 画像を表示すると増減が激しいので裏が取れるのには時間がかかりますが果たして....
ただ、svg.elも dom.elもELISP上のリストを操作しているだけで、外部のライブラリに依存するような 組み込み関数呼び出しはしていないように思えるのだけれども....?

ところで、メモリリークの話とは別に、Cygwin 3.4.xにしてからEmacs自体が定期的に 長時間固まるようになってます。うーむ、やっぱり何かあるのは確からしいのですが...🤔

2023/07/14

テレワーク。早くもなく遅くもなく終了。

Cygwin 3.4.xのメモリリーク調査。 最小コードでの再現を試みているのですがうまく再現せず。ハズしているのか?🤔

2023/07/13

テレワーク。早めに終了。

Cygwin 3.4.xのメモリリーク調査。 先日の絞り込みで 関数svg-create を実行するかしないかでプロセスサイズが増えるか止まるかの境目 があるのが判りました。そこで svg-create を繰り返し実行するような単純なループをスクラッチバッファ で実行してみたのですが、プロセスサイズが増える感じにはならなかったり。あれぇ?🤔

2023/07/12

テレワーク。早めに終了。

昨日付けでSAI2の新しいのが来ていたり。おつかれさまです。

Cygwin 3.4.xのメモリリーク調査。 ELISP上の svg-imageを生成する関数呼び出しを潰してもメモリが増えている感じなのが分かってきました。 SVG画像レンダリングの前にリーク要因がありそう。ただ、現状 色んな所を潰して絞り込んでいるので、 その中に先頭じゃないだけで要因にはなっている箇所がまぎれている可能性は否定できません。

どうやらELISP上の SVGデータを生成するコードまで潰すとメモリリークが収まるようだったり。 lisp/svg.el の中の関数(例えば関数svg-createとか)やその中で実行している lisp/dom.el辺り の関数に何かありそうな予感。SVGデータとして描画しなくても適当なSVGデータやXMLデータを 生成するようなELISPを書けば再現できるかも?

2023/07/11

テレワーク。早めに終了。

GIMPの開発版リリース 2.99.16が 来ている模様。 Windows版をインストールしてみたところ、開発版なのでコンソールウインドウが開いたり 開発版という断りが表示されたりしますが使用できそうです。 3.0に近いバージョンがリリースされた事が大きいかと思います。

Cygwin 3.4.xのメモリリーク調査。 メモリ割り当てしているコードを順に潰しながら観察してみているのですが、 ごく少量ながらじわじわプロセスサイズが大きくなります。明示的に garbage-collect関数を 実行しても減らないので、これがリークしている成分なのかしら?と思ったりも。 もうしばらくコードを潰しながら調べてみようと思いながらも、 このままいくと最悪RSVGのライブラリの中でリークしている可能性も出てくるかもなぁ?

2023/07/10

テレワーク。気持ち早めに終了。

Cygwin 3.4.xのメモリリーク調査。 メモリの増減が邪魔で観察しにくいので DIBをすぐに解放するコードを使って観察してみたのですが、 なんとなく振動せずにじわじわ増えているような気も。これで調べられるか?とも思ったのですが、 「strace --mask=malloc -p xxx」でstraceをアタッチしてみると 普段からメモリの割り当てと解放が 激しく行なわれているようで、当たりが付けられそうにありません🥺

2023/07/09

AM中に起床。

掃除したり洗濯したり。

Cygwin 3.4.xのメモリリーク調査。 先日の解放コードの観察は少し見誤っていたかも。free()した後のポインタの内容を 参照する形になっていたので、内容は不確定だったかも知れません。

もう少し仕込みを入れながら調べたところ、Emacs_Pix_Containerを生成する関数の中で Win32APIの CreateDIBSection()を使って DIBを生成しているのですが、それで得られたDIBハンドラってどこで解放しているんだ?と思ったり。 生成した Emacs_Pix_Container を割り当てただけで描画に使用しないコードにすると メモリが消費されるのですが、そのコードのまま生成したDIBハンドラを直ぐに解放してしまう コードにしてみたところメモリ消費が発生しないようだったり。 うーん? でも Cygwinをアップデートする前は大丈夫だった事との関係が説明付かないな....🤔

DIBをどこで解放しているか調べてみたところ、w32term.cの中に w32_free_pixmap()という 解放関数がありました。Emacsのimageタイプのオブジェクトとして保持されるので、 解放はガベージコレクタが忘れた頃に行うという仕組みみたい。 割り当てたときのハンドルが解放されているかを少し付き合わせてみたのですが一応大丈夫そう。 忘れた頃にまとめて解放される感じですが、この時にはプロセスサイズが縮んでいるのと、 DIBオブジェクトの削除(Win32APIのDeleteObject())にも失敗していないようなので、 DIBオブジェクトの方は大丈夫そうな気も。ふーむ。

もしかして、たまたまメモリリーク量が多いのがSVG描画でアニメーション的な事をしている場面ってだけで、 条件が揃えば場面によらず再現するのかしら?と思い、単純にmalloc()とfree()を繰り返すみたいなプログラムで 再現できないだろうかと試してみたのですが、ちょっと試した範囲では再現せず。

2023/07/08

AM中に起床。

Cygwin 3.4.xのメモリリーク調査。 EmacsでSVG描画を行うとプロセスサイズがじわじわ増えるのですが、ガベージコレクションにより増減振動 している為、本当に蓄積しているものをどうやって当たりを付けたものか困ったり。 「strace --mask=malloc」を使って malloc/calloc/realloc と free の関係が観察できるかな? と思ったのですが、mallocは細かく実行されているのがトレースできるものの、 それに対応する freeが必ずしも記録されていないようでイマイチ使えない感じに思ったり。

Emacs29で追加される image-cropのプリビューにはSVG描画を使用しているのですが、 領域選択をぐりぐりすると蓄積速度が速い気がしたりも。

そういえば メモリリークの話は 野良ビルドした emacs-w32を前提として確認していたのですが (パッケージ版の emacs-w32は SVG描画ができないから)、パケージのemacs-gtk(28.2)だとどうなんだっけ? というのを確認してみたり。こちらもじわじわ増える模様。ふーむ🤔

少し解ってきたようなそうでもないような。 SVG描画データをハンドリングしている src/image.c 内の svg_load_image()という関数に仕込みを 入れて観察してみたり。どうやら SVGデータは 一旦 GdkPixbuf 形式の画像バッファを介して、 Emacs_Pix_Container というこれまた画像バッファに変換した後、imageという構造体に変換 されると、文字扱いになって描画されるようです。 ここで、Emacs_Pix_Containerを確保しなければ、描画がされない代わりにメモリのリークが起きない事が判りました。 Emacs_Pix_Containerは一時的に確保されるのですが、image_put_x_image()という関数を使って Emacs_Pix_Containerを image構造体に変換すると同時に image_destroy_x_image()という関数で Emacs_Pix_Containerを解放するコードになっていて、 解放後はNULLになるっぽいのですが、何故かNULLにならない場合があるようです? というか、なんかバッファオーバーラン的なものでぶっ壊れているような気も? 何が起こっているのかは まだイマイチよく判らず🤔

2023/07/07

テレワーク。早くもなく遅くもなく終了。

Cygwin 3.4.xのメモリリーク調査の為にまずはCygwin本体を3.3.6からアップデート。 Emacsで SVG描画を行なわなければプロセスサイズが増える事が無いのを確認。 そういや SVGに限らずイメージキャッシュが解放されないのが原因だったりしないよね? って事で image-dired のスライドショーで画像を表示してプロセスサイズを観察してみたのですが、 一時的にプロセスサイズが大きくはなるものの、少し放置すればサイズが縮む模様。 てことはやはりSVG表示の場合に地雷を踏んでいるのは確からしい。

拙作のsysmonの SVG描画モードで再現確認。やっぱりじわじわプロセスサイズが増えます。止めれば増加も止まります。

2023/07/06

テレワーク。早めに終了。

ちょろり調べ事。

2023/07/05

テレワーク。早めに終了。

去年末から今年初め以降 悩まされている Cygwin 3.4.xでのメモリリークをそろそろ調べようかと思い、その準備の為に Cygwinのスナップ ショットアーカイブをダウンロードしようとしたのですが、 いつの間にかスナップショットアーカイブのページ自体が無くなっているようだったり。えー?そうなの?

という訳でこちらのページの 下の方に記されている Gitリポジトリをcloneしてビルドできるか試してみたり。 しかしビルドに失敗。「shilka」ってコマンドを実行するようなのですが 何者なのかがよく判らず。 どうやら winsup/cygwin/scripts/gendevicesというスクリプト(この中でshilkaを実行している)を使って winsup/cygwin/devices.in というファイルから winsup/cygwin/devices.cc というファイルを 生成するのに必要みたいですが、winsup/cygwin/devices.cc は既に出来上がっているようだったので、 touchで日付を新しくしたら先に進んだり。なんだかな....🤔
しばらく待つと一応 new-cygwin1.dll のビルドには成功。ドキュメントの生成は何やらメッセージが出てるけど エラーにはなっていないみたい。ひとまず最適化オプションを変えたりして様子を見る準備は出来た気も。

2023/07/04

テレワーク。早めに終了。

何気にEmacsの29と30の差分を眺めてみたのですが、結構差分があるんだなぁと思ったりも。 仮にEmacs29.1が7月中にリリースされたとしても、現状のEmacs30の変更箇所がリリースされるのは 1年以上先になると考えると、なんか寝かしすぎだよなぁ?とも思います。
そういやPS3世代のゲームって、制作中な事が発表されてから実際に発売されるのは1年以上先 みたいになってましたが (以前の日記)、それに似た感覚を覚えます。

2023/07/03

テレワーク。早めに終了。

調べ事して終了。

2023/07/02

AM中に起床。

掃除したり洗濯したり。

我が家では過去の日記を検索するときに、Emacsの moccur-grep を使って文字列を HTMLファイル群から 全文検索しています。大抵はこれで事が足りるのですが、ごく稀に 「(記憶にあるだけの)あの画像っていつ頃の日記に貼ったっけ?」 という場合に えーっと? ってなる事がありました。
で、遊びでしか使った事がありませんでしたが(ぉぃ💦)、image-diredを使えばいいじゃん?と 思ったり。実際に使ってみると image-diredのバッファだけだとファイルの情報があまり表示されなくて (ファイル名とサイズしか判らない)、それに連動する diredウインドウと同時に表示しながら 画像ファイルの日付を突き止めるという感じになりました。ただ単純に image-diredでサムネイルを選択した時の ファイル情報に日付を含んでくれるだけで十分なのに.... と思って対応方法を探ってみたり。
Emacs29で調べてみたところ設定で変更する事はできないようだったので、.emacsに以下のように 改造した関数と設定を置くという雑な方法で対応してみました。

;; image-diredのサムネイル選択時のファイル情報表示にファイルの最終更新時刻表示を追加するパッチ
;; "%T"を追加してみた
(defun image-dired-format-properties-string (buf file image-count props comment)
  "Format display properties for Image-Dired.
The properties are formatted according to specification
in `image-dired-display-properties-format', which see.
BUF is the associated Dired buffer, FILE is the original image
file name, IMAGE-COUNT is a string like \"N/M\" where N is the
number of this image and M is the total number of images, PROPS
is a stringified list of tags, and COMMENT is the image file's
comment."
  (format-spec
   image-dired-display-properties-format
   `((?b . ,(or buf ""))
     (?d . ,(propertize
             (file-name-nondirectory
              (directory-file-name
               (file-name-directory file)))
             'face 'image-dired-thumb-header-directory-name))
     (?f . ,(propertize (file-name-nondirectory file)
                        'face 'image-dired-thumb-header-file-name))
     (?n . ,(propertize image-count
                        'face 'image-dired-thumb-header-image-count))
     (?s . ,(propertize (if (file-exists-p file)
                            (file-size-human-readable
                             (file-attribute-size
                              (file-attributes file)))
                          "<File missing>")
                        'face 'image-dired-thumb-header-file-size))
     (?T . ,(propertize (if (file-exists-p file)
                            (format-time-string
                             "%Y-%m-%d %H:%M"
                             (file-attribute-modification-time
                              (file-attributes file)))
                          "")))
     (?t . ,(or props ""))
     (?c . ,(or comment "")))))

(setq image-dired-display-properties-format "%n %d/%f %s %T %t %c")

確認はEmacs 29.0.91と29.0.92で行ないました。 Emacs 28.2でも同じ関数と設定変数はありますがこのままだと動きません。 さておき、以下のような感じで、

Emacs29 image-dired ファイル情報表示の改善

image-diredバッファの上に ファイル名とファイルサイズに加えて ファイルの日付が表示されます。 image-diredの表示だけで日付の当たりが付くようになったので個人的にはこれでOK。 そもそも 画像ファイル名に日付文字列を付加しておけばいいだけじゃね? という話はありますが、それはそれとして...😅

そういやTwitterがアカウント無しで見られなくなってるみたい。 これとは別に閲覧可能な数にも制限がかかっているらしい。 機械で大量アクセスされたのが理由としてあるようですが 本当の所はよく判らず。 前にもアカウント無しでの閲覧制限はかかった事がありましたが、 いつの間にかその制限も無くなっていました。今回はアカウント無しでは完全に見られないみたい。 個人的にはアカウント無いので見られないけど まぁいいかって所です。 そういやGoogle検索でもいずれTwitterの書き込みは引っかからなくなるのかしら? 見られないなら検索結果に出てこない方が都合が良いとは思います。 ただ、検索できない/検索しても見られないと途端にデータとして価値が下がる、 でも自由に見られるようにすると今回のような事にもなり得るというジレンマ。

2023/07/01

昼前起床。寝すぎ。

たまたまチャンネルがそのままになっていた NHK総合の放送が なんだか画質が低いなぁ? と思ったのですが、いわゆるマルチチャンネル放送 (参考Wikipedia) になっていただけらしい。2021年に開催された東京オリンピックの時は、 途中でニュース番組が挟まる場合とかにマルチチャンネルになる事がありましたが、 普段でも使っているのかとは思ったりも。

そういや、この日記でEmacsの話をする場合は、環境の前提が概ね Cygwinの Windows-GUI(emacs-w32の野良ビルド) での話なのですが、 たまに Cygwinの GTK-GUI(emacs-gtk)だったり、 VMware上で動作させるLinuxの GTK-GUIだったり、稀に MinGWの Windows-GUIだったり、 --no-window-systemの話だったりと 組み合わせがあります。 Emacsに関する Webの記事や質問とかを見ていると、どの環境の話なのか判らないなぁ? と思う事はあります。例えば、カラー絵文字の話をしたとしても 以下のように環境によって事情が全然違うのかなと思います。

| OS        | System            | UI  | カラー絵文字表示可否     | 備考                     |
|-----------+-------------------+-----+--------------------------+--------------------------|
| Windows   | Cygwin(emacs-w32) | GUI | パッケージ版は不可能     | ごにょごにょやってる環境 |
| Windows   | Cygwin(emacs-w32) | -nw | ターミナルソフト次第     |                          |
| Windows   | Cygwin(emacs-gtk) | GUI | 可能                     |                          |
| Windows   | Cygwin(emacs-gtk) | -nw | ターミナルソフト次第     |                          |
| Windows   | MinGW             | GUI | 不可能                   | いわゆるWindowsバイナリ  |
| Windows   | MinGW             | -nw | ターミナルソフト次第?   | いわゆるWindowsバイナリ  |
| Windows   | WSL2              | GUI | 多分可能                 | 詳しく知りません...      |
| Windows   | WSL2              | -nw | 多分ターミナルソフト次第 | 詳しく知りません...      |
| Linux     | -                 | GUI | 可能                     |                          |
| Linux     | -                 | -nw | ターミナルソフト次第     |                          |
| macOS     | -                 | GUI | 可能                     | 詳しく知りません...      |
| macOS     | -                 | -nw | ターミナルソフト次第?   | 詳しく知りません...      |
| その他... | ...               | ... | ...                      |                          |

加えて、Emacsや各要素のバージョンによるとか ビルド(configureオプション指定)によるとか フォント設定によるとか フォント自体(フォーマットなど)によるとかも あると思います。 シンプルに「Emacsで絵文字がカラーで表示されません なぜですか?」という質問に 答える事ができないのは、前述事情を踏まえると色々と情報が足りないので まぁ仕方ないかなという気もします😓。 とは言え、「良し悪しは問わない」としても 面倒臭い感じには思います...🤔

GIMPの公式ページから、 「Wilber Week 2023: report」 ってイベントレポートのページがあるのを知ったり。 この中に「Autotools is finally gone from our main repository! (though it is still present in the stable branch)」 (訳: Autotools がついにメイン リポジトリから削除されました。 (ただし、安定版ブランチにはまだ存在します)) てのが記されていました。 ここでのAutotoolsは autoconf/automake/libtools の事(参考Wikipedia) のようです。で、 cmakeになったのかしら?と思ったのですが、 gimpGitHubリポジトリを見てみたところ mesonていうビルドシステムを使ってっぽい(The Meson Build system)。 Autotoolsと同じくフロントエンドという位置づけのようなので、 バックエンドは別途指定が必要みたい(GIMPでは ninjaを使う模様)。 ほぅ....


TOP PREV