トップ 追記

Orz日記 by Akio Morita

ToDo:

  • 15 SAD Fit[]回りの障害事例の解析
  • 10 smart pointer版PEGクラスの再実装(Left Recursionまわり)
2006|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|06|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|09|10|11|12|
2013|01|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|06|07|08|10|12|
2016|01|02|03|05|06|08|10|11|
2017|01|02|03|04|05|06|07|09|10|11|12|
2018|01|02|03|04|06|07|08|09|10|11|12|
2019|01|03|04|05|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|12|
2025|01|02|03|04|05|06|07|

2025-07-28 [長年日記]

_ [雑記][Ryzen]Zen5 Ryzen Threadripper雑感

先に販売が開始された12CCDのTR Pro 9995WXが予価11,699ドルで国内初値が〜210万円なので、レート設定は179円/ドルあたりの模様

7月31日販売開始予定の8CCDのTR 9980Xが予価4,999ドルなので、国内の初値は89万円前後か?

ちなみに、9995WXのシステム一式見積りだとグラフィックカードを3万円台のA400あたりにダウングレードした構成でもシステム価格が400万円前後スタートっぽぃので、並列化時の通信帯域がいらない場合は2CCDの9950Xを2.5G ethernetで結合したシステムの方がCP比は良さそう(管理工数が増えるが)


2025-07-16 [長年日記]

_ [雑記]Xperia1vii文鎮化問題

Xperia1viiが文鎮化する件ですが、不良ロットの交換が始まるそうなので、該当ロットか確認したところセーフだった


2025-07-10 [長年日記]

_ [FreeBSD]ibusでXIM EUC-JP localeを動かすパッチ

ibus-1.5.32で動かなくなっているXIM EUC-JP locale(ja-ktermで必要)を動かすパッチのまとめ

  • 本質は、post-patchターゲットで行っているibus Issue 2547のロールバック
  • util/IMdkit/i18nOffsetCache.c側の修正は、realloc時のoffset_cache->capacityの扱いがおかしい部分の修正
--- textproc/ibus/Makefile.orig
+++ textproc/ibus/Makefile
@@ -108,6 +108,10 @@ PLIST_SUB+=       COMPDIR=""
 PLIST_SUB+=   COMPDIR="@comment "
 .endif

+post-patch:
+      # Rollback https://github.com/ibus/ibus/issues/2547 for ja_JP.eucJP locale XIM on ja-kterm
+      ${REINPLACE_CMD} -e 's/gdk_init/gtk_init/' ${WRKSRC}/client/x11/main.c
+
 post-configure:
       # Clean pre-generated source code, which may not match the options selected.
       ${MAKE} -C ${WRKSRC}/ui/gtk3 maintainer-clean-generic
--- /dev/null  2025-07-10 11:37:47.184390000 +0900
+++ textproc/ibus/files/patch-i18nOffsetCache  2025-07-03 17:34:38.139498000 +0900
@@ -0,0 +1,15 @@
+--- util/IMdkit/i18nOffsetCache.c.orig        2025-04-08 21:57:26.000000000 +0900
++++ util/IMdkit/i18nOffsetCache.c     2025-07-03 17:34:35.553162000 +0900
+@@ -84,10 +84,10 @@
+
+     if (++offset_cache->size > offset_cache->capacity) {
+         Xi18nAtomOffsetPair *pair = (Xi18nAtomOffsetPair *) realloc (data,
+-                offset_cache->capacity * sizeof (Xi18nAtomOffsetPair));
+-        offset_cache->capacity *= OFFSET_CACHE_GROWTH_FACTOR;
++                offset_cache->capacity * OFFSET_CACHE_GROWTH_FACTOR * sizeof (Xi18nAtomOffsetPair));
+         if (pair) {
+             offset_cache->data = pair;
++            offset_cache->capacity *= OFFSET_CACHE_GROWTH_FACTOR;
+         } else {
+             offset_cache->data = data;
+             --offset_cache->size;

2025-06-18 [長年日記]

_ [FreeBSD]textproc/ibusの件

packageで1.5.32から1.5.31_1へ巻き戻すと今まで通り、ktermも含め問題なくXIMが動作することを確認した

次に調べるべきは…

  1. 1.5.31_1のportsからの再コンパイルで動作を確認する (2025-07-01追試 → 問題なく動作する)
  2. portsのMakefile更新に伴うコンパイルオプションの変化を確認する (2025-07-02追試 → configure option/gtk3 UI code regenまで揃えても 1.5.31_1は問題なく動作する)
  3. ibusの更新差分を調べる

XIM + ktermの動作なんてニッチ環境の不具合レポートなんて、ibusのIssue Trackerにはあがってないに違いない… Orz

portsのMakefileを順序等を整理して本質的差分のみ抽出 (2025-07-01)

diff -dur /usr/ports/textproc/ibus/Makefile Makefile
--- /usr/ports/textproc/ibus/Makefile  2025-06-11 17:14:07.686474000 +0900
+++ Makefile   2025-07-01 09:59:02.972368000 +0900
@@ -1,5 +1,6 @@
 PORTNAME=     ibus
-DISTVERSION=  1.5.32
+DISTVERSION=  1.5.31
+PORTREVISION= 1
 CATEGORIES=   textproc
 MASTER_SITES= https://github.com/${PORTNAME}/${PORTNAME}/releases/download/${DISTVERSION}/

@@ -31,6 +32,7 @@
 CONFIGURE_ARGS=       --disable-install-tests \
               --disable-python2 \
               --disable-systemd-services \
+              --disable-python-library --disable-systemd \
               --with-html-dir=${PREFIX}/share/doc \
               --with-ucd-dir=${LOCALBASE}/share/unicode/ucd

@@ -78,7 +80,6 @@
 GTK3_IMPLIES=                 WAYLAND
 GTK3_LIB_DEPENDS=             libdbus-1.so:devel/dbus \
                               libnotify.so:devel/libnotify
-GTK3_USES=                    vala:build
 GTK3_USE=                     GNOME=cairo,gtk30,pango
 GTK3_CONFIGURE_ENABLE=                gtk3 libnotify
 GTK3_LIBS=                    -lX11
@@ -97,7 +98,6 @@
 WAYLAND_LIB_DEPENDS=          libwayland-client.so:graphics/wayland \
                               libxkbcommon.so:x11/libxkbcommon
 WAYLAND_CONFIGURE_ENABLE=     wayland
-XIM_IMPLIES=                  GTK3
 XIM_CONFIGURE_ENABLE=         xim

 .include <bsd.port.pre.mk>
@@ -107,10 +107,6 @@
 .else
 PLIST_SUB+=   COMPDIR="@comment "
 .endif
-
-post-configure:
-      # Clean pre-generated source code, which may not match the options selected.
-      ${MAKE} -C ${WRKSRC}/ui/gtk3 maintainer-clean-generic

 post-install:
       ${MKDIR} ${STAGEDIR}${PREFIX}/etc/xdg/autostart

暫定的結論 (2025-07-02)

  • ports側のbuild設定を最新のibus-1.5.32と揃えて1.5.31_1を再ビルドしても問題なくktermへ入力できる
  • 従って、kterm + ibus 1.5.32での不具合は、1.5.31→1.5.32の差分に原因があるはず

調査メモ (2025-07-03)

clientソースの差分から怪しい変更を探してみた

--- ibus-1.5.31/client/x11/main.c      2024-11-08 19:35:46.000000000 +0900
+++ ibus-1.5.32/client/x11/main.c      2025-04-08 21:57:26.000000000 +0900
@@ -2,7 +2,7 @@
 /* vim:set et sts=4: */
 /* ibus
  * Copyright (C) 2007-2015 Peng Huang <shawn.p.huang@gmail.com>
- * Copyright (C) 2015-2023 Takao Fujiwara <takao.fujiwara1@gmail.com>
+ * Copyright (C) 2015-2025 Takao Fujiwara <takao.fujiwara1@gmail.com>
  * Copyright (C) 2007-2015 Red Hat, Inc.
  *
  * main.c:
@@ -1363,7 +1363,7 @@
     gdk_set_allowed_backends ("x11");
 #endif

-    gtk_init (&argc, &argv);
+    gdk_init (&argc, &argv);
     XSetErrorHandler (_xerror_handler);
     XSetIOErrorHandler (_xerror_io_handler);
  • 領域拡張のためreallocする際のサイズが増えてないのはenbugに見える
    • reallocする際に一時ポインタ変数で受けてから更新するのは理屈通りだが、fallbackが同じなので拡張失敗時の結果は同様
--- ibus-1.5.31/util/IMdkit/i18nOffsetCache.c   2024-11-08 19:35:46.000000000 +0900
+++ ibus-1.5.32/util/IMdkit/i18nOffsetCache.c   2025-04-08 21:57:26.000000000 +0900
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2014 Peng Huang <shawn.p.huang@gmail.com>
- * Copyright (C) 2014 Red Hat, Inc.
+ * Copyright (C) 2014-2025 Red Hat, Inc.
  *
  * Permission to use, copy, modify, distribute, and sell this
  * software and its documentation for any purpose is hereby granted
@@ -83,10 +83,12 @@
     }

     if (++offset_cache->size > offset_cache->capacity) {
-        offset_cache->capacity *= OFFSET_CACHE_GROWTH_FACTOR;
-        offset_cache->data = (Xi18nAtomOffsetPair *) realloc (data,
+        Xi18nAtomOffsetPair *pair = (Xi18nAtomOffsetPair *) realloc (data,
                 offset_cache->capacity * sizeof (Xi18nAtomOffsetPair));
-        if (offset_cache->data == NULL) {
+        offset_cache->capacity *= OFFSET_CACHE_GROWTH_FACTOR;
+        if (pair) {
+            offset_cache->data = pair;
+        } else {
             offset_cache->data = data;
             --offset_cache->size;
         }

i18n offset cacheの変更のみのロールバックでは挙動は変わらなかったが、gtk_initへロールバックしたら1.5.31同様にktermへEUC-JP経由のXIM入力が出来るようになった

おそらく、gtk_init -> gdk_initで省略される初期化項目にXIMのi18n関連の項目が含まれ、localeの初期化が不十分でXIMメッセージのUTF-8 -> ja_JP.eucJPの変換が機能しなくなったのではと思う…


2025-06-12 [長年日記]

_ [FreeBSD]textproc/ibus 1.5.32

ktermへのXIM入力が機能しなくなった Orz

現状まとめ

  • ibus 1.5.32による XIM入力
    • x11/xterm OK
    • japanese/kterm NG
    • editors/emacs OK

ほかにもwww/firefoxやgraphics/gimp-appも問題無さそう…

  • 更新前のibus 1.5.31_1まではktermでも問題なく動いていた
  • ja-ibus-anthy側も再コンパイルしたけど状況変わらず
  • 入力確定時に半角数字を混ぜて確定すると「半角数字」の部分はkterm側に入力される

原因究明には、kterm側がXIMから受け取ってる符号列がどうなっているか確認する必要がある? → input.cレベルだとXIM側からCJK文字が渡ってきていないぽぃ

xterm/ktermの違いとして、XIMでやりとりする符号列がUTF-8 vs EUC-JPな違いがあるが、X11側で適宜変換しているはずなのだが…

XIMレベルで有りそうなバグとしては、ibus側からEUC-JPへマップできないコードポイントが紛れ込んでおり、UTF-8 → EUC-JP変換時にCJK文字が欠落しているとか…


2025-05-22 [長年日記]

_ [雑記]CGI backend Ruby更新

Ruby3.3へ移行に伴いtDiaryにパッチ当て

最新のrackup v2.2.1を入れるとCGI版でエラーが出るので、GitHub上の開発版からリリースに含まれない対応パッチを吸い出してきた

まあ、Gemfileに手を入れてrackupをv2.2.0に抑えた方が簡単か…


2025-05-20 [長年日記]

_ [FreeBSD]ZFS on SN770

掲示板でも不安定報告がある組み合わせだが、手元でも安定しない環境が出る模様

  • Intel N305 + WD SN770 + FreeBSD 14.3-STABLEは安定している
  • Ryzen 7950X + WD SN770 + FreeBSD 14.3-STABLEは微妙に不安定(buildworldは出来ているが、長時間動作でZFSの書き込み系でスタックする模様)
  • Ryzen 7950X + WD SN850X + FreeBSD 14.3-STABLEは安定している

SATA SSD時代もZFSだと安定しないSSDがあったのでファームに癖があるのか? それとも、Cache抜きの廉価版なのがいかんのか?

流石に人知れずハングするのは遠隔運用に難有りなので、時間が出来たら予備のSN850Xに換装予定


2025-05-07 [長年日記]

_ [FreeBSD]14.3-BETA1

14.3系のリリースエンジニアリングが本格化した

これが終わると次は年末に予定の15.0の作業が…

drm的にはさっさと15系に切り替えたいところだが、いろいろ検証が必要か?


2025-04-10 [長年日記]

_ [SAD]Stringのエンコード操作

現状の実装方針

  • Code-point表現はUnicodeベースとし、CSI実装にはしない
    • 現用環境では、UCS-4でもメモリサイズ的に実用に耐える
    • 最近の外部のエンコードライブラリは、UCS-4実装が主なのでCSI化するメリットが薄い
  • ToCharacterCode, FromCharacterCode, Characters, StringLengthを再実装し、エンコードオプションをサポートする
    • デフォルトエンコードは、Unibyteとする (0x00-0xff ⇆ U+0000-U+00FFを1対1にマッピング)
    • デフォルトエンコードをUTF-8化した変種を用意する
      • ToUCS, FromUTF8 (UTF-8 → UCS-4)
      • FromUCS, ToUTF8 (UCS-4 → UTF-8)
      • UTF8s (UTF-8文字列の分かち書き)
  • エンコードモジュールが見つからない場合は、当面エラー扱いとする
    • 二次開発で、iconvバックエンドの実装を行う
      • 一旦、UCS-4-INTERNALバッファに貯めることで、ステートフルエンコードもサポート可能に(ISO-2022系とか)
    • StringEncode - Stringのエンコード変換の実装も二次開発項目
      • UCS-4経由であれば、FromCharacterCode[ToCharacterCode[s, Encoding->from], Encoding->to]相当

2025-04-08 [長年日記]

_ [SAD]文字列Encodeの扱い

やはり、Encodeオプションのような形で、String処理時のEncodeを指定できる方がスマートな気がする…

その場合、サポートするEncode名とバックエンドの関係を定義するframeworkを実装すべきか?

現在の状況では、実用的なコードポイント集合はUnicode(UCS-4)になるので、CSI実装をする必要は無いと思われる

基本的なPrimitiveは、multibyte bufferからコードポイントを拾う・multibyte bufferへコードポイントを書き出す辺りか?

ISO-2022系のような状態遷移を持つ系はどうするのが良いのだろう… (一旦、UCS-4列にパックしてからiconvだと一時領域を割り当てる必要がある)

現時点での改修案

  • String encodingを扱いFrameworkを実装する
    • 外部化するCode PointはUnicode(UCS-4)とし、CSI実装にはしない
    • iconv(3)による変換サポートを実装(UCS-4-INTERNALへ正規化後に変換するフロー)
    • 1-character単位の変換が可能なEncodingに関しては、put/get手続きを実装し、methodテーブルに登録する形にする
      • Encode名・1文字put・1文字get・1文字String生成(分かち書き用)・内部分類コード (backend routineの共用化用との識別符号)
  • 現行実装済みのUTF-8サポートは、Encode/Unicode等の符号化サポートモジュールの形に再実装する
  • API/StringUtilsからは、上記Frameworkを経由してEncodeサポートを行う
    • Encodeオプション付きのToUCS, FromUCSを汎用APIとして整備する
      • Default Encodeは、Unibyteとして ToCharacterCode, FromCharacterCodeと互換を取る
      • ToCharacterCode, FromCharacterCodeを別名化する余地あり
      • 派生する文字への分かち書き・文字数カウントAPIは、UCSsUCSLength辺り?
        • もしくは、Characters及びStringLengthEncodeオプションを持ち込む
    • ToUTF8, FromUTF8に関しては、特化APIとして残す?(外部との入出力の取扱いで頻度が多いはず)

カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記