昔の最近の出来事(2025.11)

2025/11/30

AM中に起床。

掃除したり洗濯したり。

gptelを使ったコード生成の実験をしてみていました。 試しにN角形を三角形に分割する関数の作成とかどうだろう?と思って試してみたところ、 少し手直しする必要はありましたが、動く感じのものが生成されました。 生成の元になる文言は以下のような感じ。

/*
  平面上の任意のN角形を三角形に分割してその三角形群を返す関数を作成してください。
  - 点は
    struct Point {
      double x,y;
    }
    で表現してください。
  - 任意のN角形は
    Point[] polygon;
    のようなPoint構造体の配列で表現してください。
    配列の要素はN角形の頂点を示します。
    内角が180度よりも大きな凹角を持つ凹多角形の場合もあり得ます。
  - 三角形
    struct Triangle {
      Point p0,p1,p2;
    }
    で頂点を格納する構造体で表現してください。
    メンバー変数 p0,p1,p2 はそれぞれ三角形の頂点を表現しています。
  - 関数は「Triangle[] devide_polygon(Point[] poly)」という戻り値の型と引数を有します。
    polyは任意のN角形lを示す頂点の配列で、分割した三角形群を Triangle型の配列で返してください。
    分割された三角形は分割前のN角形に含まれる頂点のいずれかで表現されるものとし、
    N角形の辺上に新たな頂点を置いて分割しないでください。
  - 生成するコードのインデントは半角スペース2個としてください。
  - コード内のコメントは日本語で記してください。
 */

これで gptel-rewrite してみたところ、ごく簡単なテストコード付きで生成されました。 ただし、以下の点でコンパイルエラーになる箇所があったのを手で直す必要がありました (完全なコード生成を期待していた訳ではないのでこれらを直す指示はせず)。


これら以外は一切弄らずに動かしてみたところ 4角形くらいは大丈夫そうだったのですが、 分割された三角形の頂点を writeln()で表示するだけの結果確認コードだったので、 頂点数が多いと合っているかどうかわかりません。そこで画像描画するコードを別途自前で用意して 確認してみた感じ 頂点を増やしても大丈夫っぽい。

N角形を三角形に分割した結果

赤の辺が元の多角形。赤の辺と青の辺で囲まれた三角形が分割された三角形。 因みに、生成されたコードはいわゆる「耳刈り取り法(Ear Clipping)」を実装しているようです (参考Wikipedia)。もっと高速なアルゴリズムもあるようですが、 名前が付いていないのか検索ヒントが無くてどういうものかは判りませんでした。

2025/11/29

AM中に起床。

デスクトップPCのバックアップを取っておくかと思い取ってみたり。 現デスクトップPCは今年の5月から稼働を始めたのですが、前デスクトップPCのファイルをほぼ そのままコピーしたので容量的には変わらないくらいに思います。が、前PCでは数日かかっていたのですが、 8時間ほどで終わったのでマジでかと思ったりも。とは言え、野良ビルドしっぱなしの古い Emacsのソースディレクトリとかは適度にアーカイブするとか消すとかした方が良いなとは思います😓。

調べ事。

2025/11/28

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

調べごとをして終了。

2025/11/27

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

D言語で、例えば「struct Point{int x, int y}; struct Line{Point p0, Point p1};」の Lineのように 入れ子になった構造体をリテラルで初期化する方法を Ollamaの gpt-oss:120b で聞いてみたら 「Line l0 = Line(Point(0, 0), Point(10, 10));」のように書けばよいという回答が返ってきて、 確かにこれで大丈夫だというのを知りました。応用の範囲内なのかも知れませんがドキュメントには 明に記されていない例だったので、ほぅ...と思ったり。

2025/11/26

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

デスクトップPCのFirmwareアップデートが来ていたので入れてみたり。 前回、アップデートに失敗したのを受けてUSB-typeCのケーブルを抜いて 望んでみたのですがアップデートに成功しました。ケーブルを抜いておいた効果があったのか否かは定かではありませんが 次回以降もFirmwareアップデートの際はこれで対応してみようかと思います。

2025/11/25

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

たまにEmacsで tar.xzファイルの中身を tar-modeで見る事があるのですが、 よく見るとファイル一覧に日付が表示されていないなぁ?と思ったり。 表示する方法は無いのだっけ?と思って調べてみたらカスタム変数 tar-mode-show-date を tに設定すれば良いらしい。 てか何故デフォルトで tになっていないんだ?🤔 あと知らなかったのですが、tar-modeでは自力でアーカイブを操作しているらしい。ほぅ...

2025/11/24

AM中に起床。

体調がイマイチ。録画を消化したりぐうたら過ごして終了。

2025/11/23

AM中に起床。

掃除したり。

たまたま見たTVCMで「ケイト リカ」なるリカちゃん人形があるのを知ったり (公式商品情報ページ)。 これ、対象年齢何才なんだ? あと 今年の下期向けカタログ があったので見てみたのですが、コラボ商品も沢山あるのだなぁ と思ったりも。 送葬のフリーレンリカちゃん は2026年1月からの二期放送に合わせたものだとは思いますが、 判る年齢は高めな気もします。リカちゃんのターゲット層に合っているのだろうか?

2025/11/22

AM中に起床。

OllamaとEmacsのgptelで遊んでいて 時々モデルを切り替えたくなります。 一つのモデルで色々できれば良いのですが速度の差や得手不得手があるので仕方がない所です。 gptel本体には複数のモデルとバックエンドを切り替える仕組みは無いっぽいので、 scratchバッファで変数gptel-model と 変数gptel-backend を手動でセットし直して切り替えていました。 しかし、特定の用事が終わったらまた元に戻すのも面倒臭いなぁ?と思うようになったので、 モデルの切り替え関数を作ってみました。

(setq my-gptel-model-alist
      `(
        (gpt-oss:20b . ,(gptel-make-ollama "Ollama"
                          :host "localhost:11434"
                          :stream t
                          :models '(gpt-oss:20b)
                          ))
        (gpt-oss:120b . ,(gptel-make-ollama "Ollama"
                           :host "localhost:11434"
                           :stream t
                           :models '(gpt-oss:120b)
                           ))
        (qwen3-vl:30b . ,(gptel-make-ollama "Ollama"
                           :host "localhost:11434"
                           :stream t
                           :models '((qwen3-vl:30b :capabilities (media) :mime-types ("image/jpeg" "image/png")))
                           ))
        (qwen3:30b . ,(gptel-make-ollama "Ollama"
                        :host "localhost:11434"
                        :stream t
                        :models '(qwen3:30b)
                        ))
        (qwen3-vl:8b . ,(gptel-make-ollama "Ollama"
                          :host "localhost:11434"
                          :stream t
                          :models '((qwen3-vl:8b :capabilities (media) :mime-types ("image/jpeg" "image/png")))
                          ))
        ))

(defun my-gptel-set-model (&optional model)
  "Set gptel model"
  (interactive)
  (unless model
    (let ((modlist))
      (dolist (el my-gptel-model-alist)
        (push (car el) modlist))
      (setq model (intern (completing-read (format "Model[%s]: " gptel-model) modlist)))
      )
    )
  (if (assoc model my-gptel-model-alist)
      (setq gptel-model model
            gptel-backend (cdr (assoc model my-gptel-model-alist)))
    (message "Error: Invalid model %s" model)
    )
  )

(setq my-default-gptel-model 'gpt-oss:20b)
(my-gptel-set-model my-default-gptel-model)


因みに .emacsに直置きで、示してるのは切り替え器の部分だけです。 ちょろっと切り替えて用事が終わったら元に戻すのが楽になった気も。

どうやらgptel本体の「M-x gptel-menu」(チャットモードの右上に表示されるモデル名のマウス左クリックと同等) というコマンドで、「-m」サブコマンドによりモデルの一覧から選択できるっぽいのを知ったり。 でも、追加したOllamaのモデルは一つしか表示されていなかったので、デフォルトで色々表示されている ChatGPTのメニューを調べてみたところ、リストで複数並べて書けば良いらしい。

(gptel-make-ollama "Ollama"
  :host "localhost:11434"
  :stream t
  :models '(
            (gpt-oss:20b)
            (gpt-oss:120b)
            (gpt-oss-safeguard:20b)
            (gpt-oss-safeguard:120b)
            (qwen3-vl:30b :capabilities (media) :mime-types ("image/jpeg" "image/png"))
            (qwen3:30b)
            (qwen3-vl:8b :capabilities (media) :mime-types ("image/jpeg" "image/png"))
            )
  )

サンプルとかではモデルを一つだけ指定する方法しか示されていないのですが、 関数gptel-make-ollamaにより 第一引数の文字列「Ollama」をprefixとして :modelsに並べたモデルが gptel-menu の -m の一覧として表示されるようになるようです。 また、gptel-request.elの 変数gptel--openai-models のように ちゃんとプロパティも書けば モデルの説明なども一覧に表示されるようです。 因みに拙作の切り替え方法では、my-gptel-model-alistの中で 関数gptel-make-ollama を 実行しているので、モデルが一つだけ定義された Ollamaのデータベース(説明の便宜上の用語)が構築されます。 my-gptel-model-alist設定後に 全部入りのOllamaデータベースを関数gptel-make-ollamaで(再)構築すれば同居は可能です。 my-gptel-model-alist設定前に 関数gptel-make-ollamaで構築しても、 my-gptel-model-alist設定内の最後に実行された 関数gptel-make-ollama の内容で上書きされてしまいます。 さておき、gptel-menuの方は1ストロークで選択メニューに辿り着けないのと、デフォルトのChatGPT項目が 結構多くて邪魔なので、手前味噌ですが拙作の切り替え器の方が使い勝手は良いかな?とは思ったりも😅。 御参考まで。

2025/11/21

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

Web巡回して終了。

2025/11/20

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

そういえば以前、Ollamaで扱うモデルのサイズってダウンロードしてみないと 判らないんだっけ?と思ったのですが、 こちらのページのモデル一覧から調べられる事を知りました。

気づいていませんでしたが GIMPの 3.2 RC1がリリースされている模様 (GIMP 3.2 RC1: First Release Candidate for GIMP 3.2)。

2025/11/19

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

調べごとをして終了。

2025/11/18

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

ひかりTVのチューナー交換。7月に通知が来ていたのですが いつ届くのだろう?と思っていたら今日届きました。 古いのを外して新しいのを設置。初回のファームウェアアップデートに随分待たされたり。 送ってくる事は判っているのだから新しいのを入れておいてくれれば良いのに。しばらくしてアップデート完了、 移行操作をして移行完了。 前のに比べて操作レスポンスが良くなってて快適。あと、4K対応チューナーになっている模様。 HDMIの信号表示上は常に4Kで表示されていて、2Kのコンテンツはアップコンバート(ただの拡大かも知れませんが) されているみたい。4Kの無料コンテンツを見られるのかと思って試してみたら、1分くらいだけ観る事が できましたが 続けて観たいなら 4K視聴権 的なものを申し込む必要があるみたい。

2025/11/17

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

AIコーディングに対するAI回答 何気にGoogleで「AIコーディング 結局修正や検証が面倒臭い」で検索したら、右のようなAI回答がありました。 この回答を読んでなんかモヤっとするなぁ?と感じました。で、思ったのですが、「AIは」を 人間の体で「私は」に置き換えて読むとなんとなくモヤっとする理由が判る気がしたりも。 例えば、ブラックボックス問題に記されている文言を 「私がどのようにその結論(コード)に至ったのか、その処理過程が人間にとって理解しにくいことがあります。 そのため、生成されたコードの信頼性を確保するには、人間による徹底的なレビューとテストが不可欠です。」 と読んだら、「こいつ何言ってんだ?」と思えてしまいます。
「コーディングスピードは速く、ある程度優秀なのかも知れませんが、細かいところは指示しなくてはならないし、 自分では確認もテストもしないし、レビューには参加しない(参加しても恒久的な経験値として覚えてくれない)人」 という印象を受けます。結局、自分で確認しないので「動かないので直してほしいのだけど?」という場合でも、 再現条件やらなんやらバグレポートを事細かく伝える必要があるだろうし、 場合によっては こちらで直しているのと変わらないかも知れません。そして修正した(つもりの)コードをこちらが テストしなくてはならない。 盛大に書き換えられてしまう可能性もあって、最悪テスト自体も最初からやり直さなくてはならないかも知れません。 .....というプログラマが書いたコードだと100歩譲ったとしても、 「あなたは私が書いた(生成した)コードの品質保証、テスト、および最終的な意思決定に集中することが重要です」 と言われたらイラっとはするかも知れません。 「責任を持つのはあなたで~す、私は何の責任も持ちませ~んw」という感じがなんかモヤっとするのかなぁ? と思います。 個人的に思いますに、機械的にやれば良いけど量が多くて面倒臭いみたいな事をやって欲しいので、 どちらかというと テストや動作確認の方ってできないの?とは思います。 まぁそれも「メイン機能の不具合をちょいちょい見逃す」みたいな感じだとダメかも知れませんが。

2025/11/16

AM中に起床。

掃除したり洗濯したり。

Web巡回をしたり調べごとをしたりして終了。

2025/11/15

AM中に起床。

Emacs31系となる予定のmasterブランチをビルドして list-charset-chars で文字の一覧を見ていたら 何故かグリフの無い文字コードの表示が変になっているなぁ?と思ったり。

Emacs31.0.50 list-charset-chars 表示 Emacs30.2 list-charset-chars 表示

左(or上)が31.0.50の表示で、右(or下)が30.2の表示です。 グリフが無い場合は四角の枠の中にコードが表示されるのですが、31.0.50ではバイナリを表示する場合の 8進数表示方式になる「場合が」あるようです。全てが8進数表示になる訳では無いようで 境界がよく分かりません。 31.1がリリースされるまでに気づいて直してくれる事を期待したい。

そういや30.2は Unicode 15.1 のカラー絵文字までしか対応していないな?と思い、masterブランチの admin/unidata を使って30.2をビルドしてみたり。だた、admin/unidata/unidata-gen.elの中で 使用していた 関数cl-incf が masterブランチでは incf に書き換えられていているのですが、30.2ではそんな関数知らんと 言われてエラーになるようです。以下のようなパッチで対応してみました。

$ diff -u admin/unidata/unidata-gen.el.orig admin/unidata/unidata-gen.el
--- admin/unidata/unidata-gen.el.orig   2025-03-29 01:16:50.000000000 +0900
+++ admin/unidata/unidata-gen.el        2025-11-15 23:45:01.686650700 +0900
@@ -1004,7 +1004,7 @@
              (dotimes (i (length vec))
                (dolist (elt (aref vec i))
                  (if (symbolp elt)
-                      (incf (alist-get elt (cdr word-list) 0)))))
+                      (cl-incf (alist-get elt (cdr word-list) 0)))))
              (set-char-table-range table (cons start limit) vec))))))
     (setq word-list (sort (cdr word-list)
                          #'(lambda (x y) (> (cdr x) (cdr y)))))


以下の様に Unicode 16.0 の絵文字も表示されるようになりました。

Emacs30.2 Unicode16.0 カラー絵文字表示

当面 Emacs-31.1はリリースされないと思いますので、30.x系はしばらくこれで。

2025/11/14

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

Web巡回して終了。

2025/11/13

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

調べごとをして終了。

2025/11/12

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

ノートPCでEmacsのハング対応パッチの確認を18日ほど続けていたのですが WindowsUpdateの為に停止。 もう実績的には問題無さそうなので、起動したままの確認は一旦終了。

WindowsUpdateついでに Windows11 25H2化してみたり。特に見た目の違いは判らず。

2025/11/11

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

REALFORCE。キーレイアウトを4面持てますが、そのうちの一つを何もいじっていない面、 もう一つをCapsとCtrlスワップ面にしました。で、電源投入したときは初期値は必ず第1面になっているようです。 レイアウトの切り替えは意図的にキー割り当てしないとダメなので、割り当て面を覚えてしまうと 切り替えられなくなる可能性があるのでこうなっているのかな?とは思ったりも。

唐突に「アンテナや釣り竿のような伸び縮みする構造」のことをなんて言うんだっけ?と思い Google検索してみたらAI回答に「テレスコピック構造」という回答があったり。 テレスコピックのWikipedia によると望遠鏡(telescope)に由来している言葉らしい。ですが、英語圏の人間では無いので 覚えられない🥺。そして人に説明するときにも「アンテナや釣り竿」で例えるに違い無い。 Ollamaでgpt-oss:20bを使って同じ質問をしてみたら「テレスコピック」という単語は出てこずに 単に「伸縮構造」の説明が返ってきました。 「伸縮構造」の一つに「テレスコピック構造」が含まれるような感じだと思うので、 「伸縮構造」だと範囲が広すぎるように思います。

全然関係ない流れで知った「大阪ガスのインターネット回線スピードテスト」の サイト。なんでガス会社が?と思ったのですが、 インターネットサービスプロバイダもやっているからという事らしい。 かつて東京電力が「TEPCOひかり」をやっていたのと同じ形態かと思って勝手に納得。

2025/11/10

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

Web巡回して終了。

2025/11/09

AM中に起床。

掃除したり洗濯したり。

「ONEPIECE(113)」。ネタが山盛り過ぎる。ワノ国編以降 ネタ回収される度に、 これって いつから考えられていたのだろうか? と思ってしまいます。 現在を起点に新たな話が展開されていく物語と違って、現在に至るまでの過去の話が後で展開される 感じなので、後で考えて辻褄を合わせる事は不可能では無いにしても、これだけネタがあると 予め考えておかないと辻褄合わせるのは無理じゃなかろうか?と思う訳です。 そういえば前巻から登場している「軍子」の髪色って青なのかと思ったり。

キーボードの馴らしは一旦終了。あとは使い続けてみてどうかな?という感じで。

2025/11/08

AM中に起床。

午前中に散髪に。

午後から急に思い立って秋葉原へ。「REALFORCE R4」を調達。

本物お仕事では社給のノートPCを使用しているのですが、CtrlとCapsLockの入れ替えをソフト的に行えない 事情があったため、ハードウェア的にキーレイアウト変更が可能な「REALFORCE R2」を使用しています。 元々は2018年6月頃に 指が痛くてその対策としてキー荷重30gを買ってみたのですが (以前の日記)、あまり改善はせず、加えて Ctrlキーとして使っているCapsLockキーに突っかかりがあり 普段使いするにはイマイチだったので しばらく放置していました。コロナ禍でテレワークとなった訳ですが、ソフト的にキーレイアウト変更ができない という理由から 2020年3月に再び使う事にしました(以前の日記)。 スペーサーを入れて(R2には標準添付)、ACPも調整して、更にキーキャップもヤスリで面取りするなどして 使えるようにして現在に至っていました。しかし、ここ最近「N」キーの反応が極端に悪い感じになっていて 押しているけど抜けるのでTypoになり、なんかイマイチな状況になっていました。 ハード的にキーレイアウト変更ができるとなるとREALFORCEくらいしか無いので、そういや最近はどうなっているんだっけ? と検索してみたら 10月に R4が出ているというのを知ったのと、R2でキータッチ以外にも不満に思っていた点が 軒並み解消されていそうだったので 急に思い立ったという次第。

R2の時は「日本語配列、テンキーレス、キー荷重30g、黒」でしたが、 今回のR4は「日本語配列、テンキーレス、キー荷重45g、白」にしました。 30gを45gに変えたですが 30gだと軽すぎたかな?と思うところがあったので思い切って変えてみました。 色についてはタッチタイピングなので 黒に黒刻印のキーキャップでもあまり困る事は無いのですが、 たまに見たときに「読めん」って思うことがあったのと、R4ではFnキーによる操作の刻印もあることから 「夜にサングラスをする」的な機能不美(造語)は不要と思った次第です。 4mmストロークはしばらく使っていなかったので(本物お仕事はスペーサーを挟んで3mmにしたREALFORCE、 プライベートは3mmのロープロファイルメカニカルスイッチのキーボード)、 ちょっと感覚的な調節が必要なのと 30gに比べるとやっぱり重いかも?と感じましたが、使っていれば慣れるかな? という感じです。R2とR4ではキーのサイズが微妙に変わっている所があるので、R2のスペーサーはR4では使えなさげ。
キータッチ以外では、R4ではケーブルがUSB-Cで本体から脱着可能になりました。USB-Cは向きがリバーシブルなので、 コネクタ形状が J型の向き L型の向きといった区別も無いので ケーブルの取り回しが良いです。 R2ではCtrlとCapsLockの交換しかできなかったのですが、R4ではどのキーもほぼ自由に入れ替え可能です。 加えて4つのキーレイアウトを保持/切り替えできるようなので、PCのソフト環境に合わせるのが簡単になりそうです。 TANE自身は恐らく使う場面はほぼ無いと思いますが、Bluetoothでワイヤレス対応だったり 乾電池が使える(リチウムイオンは処分が面倒)というのも場面によっては良いかも。

ダメもとで R2のスペーサーを取り外して R4にあてがってみました。すると、一番下の段(スペースキーのある段)が ほんのりズレているだけで、上から4段分はピッタリはまるようでした。という訳で、 下の段の合わない部分をハサミで切り離して、合うところをなるだけそのまま生かしてみたところ、 それとなくつかえるんじゃないか? という感じになりました。スペーサーを挟むとキーの押し込み感覚は無くなってしまうのですが、 R2で慣れてしまっているのもあってひとまずこれで使ってみることに。 ACPは2.2mmに設定されているのを1.5mmに変更。R2と感触的には変わらないかも。

R2でイマイチになってしまっていた「N」キーの反応も問題無し(当たり前かも知れませんが)。よき😄。

そういえば REALFORCEを買った時に レジでボタン電池の回収について聞いたら その場で引き取ってもらえたり。 ありがたや。因みにヨドバシです。

2025/11/07

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

Web巡回して終了。

2025/11/06

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

調べごとをして終了。

2025/11/05

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

Fedoraの43ってのがリリースされたようなので、VirtualBoxで動かしているのをアップグレードしてみたり。 壁紙が変わった以外の変化はよく分からず。

2025/11/04

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

プログラム言語などでの「変数」を「箱」に例えて説明する場合がありますが、これって万国共通なのかしら? と思って 検索してみたところ AI回答によると 海外でもよく使われる一般的な比喩表現らしい。へぇ。

2025/11/03

AM中に起床。

以前手持ちのD言語コードでdmdコンパイラがICE落ちすることがありました。 今年の4月にリリースされた 2.111.0 で起こる話ですが、今日時点で新しいのはリリースされていないので特に何かする 訳ではなかったのですが、Nightlyで直ってたり しないだろうか?と思って試してみたり。 2.112.0-beta.1 というバージョンだったのですが、 やっぱりICE落ちするようなので修正は(発見も?)されてはいなさそうです。

$ dmd -m64 -O -I. -version=Unicode -version=Windows10 -version=IE5   -c GameFrame.d -of=GameFrame.obj
tym = x14
Illegal instruction

$ dmd --version
DMD32 D Compiler v2.112.0-beta.1
Copyright (C) 1999-2025 by The D Language Foundation, All Rights Reserved written by Walter Bright

「-O」を付けなければ大丈夫そうなのも変わらず。
因みにWebページでは 2.113 となっていますが、順番でいえば次は 2.112.0 のように思うので、 Webページの値が間違っているのか?🤔

2025/11/02

AM中に起床。

掃除したり。

そういえば Emacs31系はまだmasterから分岐はしていませんが いつ出す予定だろうか?

Qwen3-VLで画像の内容ではなくフォーマットについて尋ねたところ、なんだかモンヤリした推測交じりの 回答が返って来たり。恐らく画像認識にはデコード済の状態で渡されるので、デコード前のフォーマットに ついては知りえないという事なのだろうと思われます。「仕組み的に元の画像ファイルフォーマットは判らない」と 回答してくれれば良いようにも思うのですが、何やら頑張って推測するようです。

先日アップデートした新しい gptelのチャットでは回答結果に「#+begin_reasoning ~ #+end_reasoning」というブロックが 表示されるようになっているようです。推論の過程が表示されているようで、これらを踏まえて回答結果が表示される という感じになっているようです。gpt-oss:20bでは割とあっさりとした内容ですが、 qwen3:30bでは割と長めの(場合によっては最終的な回答よりも長い)自問自答を行っているようです。 英語で表示されていますが、HTMLにエクスポートしてChromeで表示してページ翻訳すると人間にも意味が判るように 推論していて面白いなぁと思いました。画像認識の場合は色々推論して間違えてるってパターンもあるようです😓。 さておき、reasoningブロックは HTMLにエクスポートすると非表示にはできないので、 回答結果を読むのに邪魔になる場合があります。カスタム変数 gptel-include-reasoning を nilに設定すると reasoningブロックは出力されなくなるようです。

qwen3の推論(reasoning)の中でEmacsユーザーである可能性について触れられている事があったので 「なんで分かるんだ?🤔」と思ったのですが、gptel-directives という変数の中で 「(default . "あなたはEmacs上で動作する大規模な言語モデルで、役立つアシスタントです。詳しく教えてください。")」 って記してあるからっぽい。 言ってなければ判る訳が無いので、判っているという事はどこかで言っているって事になるのかなと思います。 これって対人の時は逆の方向で気を付ける所かも。 直接会話ではない公開チャットのようなもので言ったつもりになったところで、 それをみんなが読んでいるとも 意図通りに解釈しているとも 限らないってのはよくある事です😓。

2025/11/01

AM中に起床。

Ollamaのv0.12.7というアップデートが来ていたのですが(ついさっき見たらv0.12.8が出てましたが😅)、 Qwen3-VLというモデルを使用可能になったらしい。 どんなモデルなのかと思って調べてみたら画像も認識できるらしいというのを知り試してみたり。 話は一瞬逸れますが モデルのファイルサイズってダウンロードしてみるまで判らないのだろうか?🤔 さておき、適当に試しながらダウンロードしてみたところ 以下のようなサイズのようです。

$ ollama list
NAME            ID              SIZE      MODIFIED
qwen3-vl:8b     901cae732162    6.1 GB    7 hours ago
qwen3:30b       ad815644918f    18 GB     7 hours ago
qwen3-vl:30b    eda0be100877    19 GB     8 hours ago
gpt-oss:20b     17052f91a42e    13 GB     2 weeks ago
gpt-oss:120b    f7f8e2f8f4e0    65 GB     6 weeks ago

qwen3-vlの方が画像認識機能(Vision Language model)も持つ方みたい。 Emacsのgptelで試してみたのですが、 「現在の設定ではファイルシステムにアクセスできないため、画像の内容を確認する事ができません。」 という回答が返ってきました。OllamaのGUIでは画像ファイルをドラッグ&ドロップして「画像の説明をしてください」 というメッセージを送ると解釈しているようなので、Emacsおよびgptel側の方に問題がありそうな予感はしたりも。
そういやと思い、GUIの方で「describe this image '/path/to/foo.jpg'」というメッセージを送ると、 やっぱりローカルファイルにアクセスできないという旨の回答が返ってきました。 でも、コマンドラインから「$ ollama run qwen3-vl:8b 'descrive this image ./foo.jpg'」と実行すれば うまく動くようです。画像の渡し方に秘密がありそうな予感がしたりも。

使用しているgptelは 20250909.1755 というバージョンで 画像ファイルの送信には対応していそうに思ったのですが、 更新版が出てそうだったのでgptelパッケージを 20251031.251 というのにアップデートしてみたり。 ファイルを送るか否かの表示が判りやすくなった感じだったので送れるか? と思ったのですが、「error in process sentinel: Search failed: "....."」というエラーが出て 実行に失敗しているようだったり。むーん?

原因判明。データを含むような場合、Ollamaに投げるリクエストは リクエストボディを 一旦 tmpの.jsonファイルに保存しておき、それを curlで送っているっぽいのですが、 curlに「--data-binary @/tmp/*/gptel-curl-*.json」のような感じでファイル名渡ししているようです。 しかし、curlは Windows標準の c:/Windows/System32/curl を使っていた為、 /tmp/* はCygwinパスでWindows標準のcurlにはパスが解釈できず実行に失敗しているという感じのようでした。 Cygwinパッケージのcurlをインストールして(デフォルトでスキップになっている模様)みたところ、 画像ファイルのデータを送って答えを得る事ができました。前述した通り途中で .jsonファイルを生成しますが、 画像ファイルはbase64エンコードして画像データとして埋め込まれる感じになっているので、 画像ファイル自体のパスは問題にならないようです。 この為、curlのファイルパス指定問題が解決すればデータの添付に関する問題は全て解消する感じだと思います。


TOP PREV