EPSG忘備録

どうも、最近 JGD2011 以降の測地系を「日本測地系」と呼ぶらしい。そのせいで、Bessel1841の楕円体を地球の基準としていた日本の「旧日本測地系」のEPSG(SRID)が記載されなくなってきた。 しかしながら、仕事では、まだまだ旧日本測地系の成果を扱う事が多いので、メモっておかないと、わからなくなってしまう。

日本で取り扱う緯度経度座標には2種類あり

EPSG:4301: 旧日本測地系（ベッセル楕円体）
EPSG:4326: WGS84（GPSの標準）

となっている

AIと戯れる

AI方面の知識がなくても、ぱっと思いついたアイディアをなんとなくAIに手伝ってもらいながら試す事ができるようになりました。
趣味のプログラミングが楽しいです。

これは、どういう事か内容を教えてください。と、AIに解説してもらったり

この内容を実装してみたいです。と、AIにお願いしてみたり

この結果は、こういう理由でこうなっているのではないか？こういう風に実装を変えて試してもらえないでしょうか？と、AIにお願いしたり

個人でアイディアをぶつけて、実験する敷居がものすごく下がりました。
なんなら、AIの方から提案してくれたり、お？それいいね！やってみましょう！と二人三脚で、いろいろ試せる
いい時代になりましたね！

以下、こんなアホな事をやらせてました。

EDLA (Error Diffusion Learning Algorithm) 実装履歴

概要

誤差拡散法（ED法）を用いたニューラルネットワーク学習の実験記録。 バックプロパゲーション（BP）を使わない学習手法の可能性を探った。

---

時系列実験ログ

Phase 1: ED法の基本理解と初期実装

着想

• Qiitaの記事からED法について学習開始
• 10層の深いネットワークで勾配消失問題が発生することを確認

実装ファイル

• ed_entropy.py: Python版EDLA（エントロピーベースのu0調整）
• ed_mnist.py: MNIST用Python実装
• ed_network.cpp: C++版（高速化目的）

課題

• 深いネットワークで学習が進まない
• sigmoidの飽和による情報伝達の問題

---

Phase 2: 論文準拠の正確な実装

着想

• arXiv論文（2504.14814v3）を発見
• 公式GitHub実装と比較して、重要な違いを発見

重要な発見: sign(w) の欠落

// 修正前（誤り）
delta = (target - output) * g_prime;

// 修正後（正しい）
delta = (target - output) * g_prime;
delta *= sign(w);  // ← この行が重要！

実装

• edla_paper.cpp: 論文準拠の正確な実装

結果

テスト	修正前	修正後
XOR	-	41エポック
Parity	-	7エポック

収束安定性が向上。

---

Phase 3: 活性化関数の比較実験

着想

• 情報伝達問題の原因は活性化関数の飽和
• 様々な活性化関数でg'(a)の健全性を検証

実装オプション（edla_paper.cpp）

--sigmoid  : 標準sigmoid
--tanh     : tanh(a/5)をスケーリングして[0,1]へ
--wavelet  : Mexican Hat Wavelet
--softmax  : Softmax出力層
--linear   : 線形活性化（実験用）

MNIST結果

活性化関数	Epoch 1	最終精度	勾配 g'(a)
sigmoid	87.76%	94.99%	0.0217
tanh (スケーリングなし)	56.87%	~50%	0.0058
tanh(a/5)	95.01%	97.66%	0.0504
wavelet	42.34%	-	-
softmax	88.20%	88.34%	0.0315
linear	NaN	NaN	発散

結論

• tanh(a/5) が最良（勾配がsigmoidの2.3倍）
• softmaxはED法のP/N構造と相性が悪い（88%で停滞）
• linearは出力が発散してNaN

---

Phase 4: Logic Gate Networks論文の調査

着想

• arXiv:2411.04732（NeurIPS 2024）を調査
• 論理ゲートによる超高速推論の可能性を検討

論文の要点

1. 16種類の論理ゲートを学習可能に
2. Residual Initialization: Identity（素通り）を90%で初期化
3. 訓練時は浮動小数点（微分可能）、推論時はバイナリ
4. CIFAR-10で86%達成

CIFAR-10比較実験（cifar10_compare.cpp）

モデル	Epoch 5精度	時間
EDLA	17.32%	1071s
Logic Gate (簡易版)	10.00%	151s

考察

• LGNは畳み込み構造が必須（今回は全結合のみ）
• 重要な発見: LGNも訓練時は微分が必要 → 勾配消失問題あり

---

Phase 5: Residual概念のED法への適用

着想

• LGNのResidual Initializationは「Identity経路で勾配を維持」
• ED法でも同様の効果が得られるのでは？

実装1: Gated EDLA（edla_residual.cpp, edla_residual2.cpp）

// 各ニューロンでα確率でIdentity、(1-α)で通常計算
output = α × prev_layer_mean + (1-α) × tanh_scaled(activation)

結果（3層ネットワーク）

手法	MNIST精度
オリジナル EDLA (tanh/5)	95.01%
Gated EDLA	86.54%

→ 浅いネットワークでは効果なし（むしろ悪化）

---

Phase 6: Identity経路の導入（ユーザー提案）

着想（ユーザー）

「100x100の入力を400x400に拡張し、25%をIdentityに割り当てる」

層のニューロンを「計算ニューロン」と「Identityニューロン」に分離する方式。

実装（edla_identity.cpp）

隠れ層構成:
[計算ニューロン 75%][Identityニューロン 25%]
                        ↑
               入力平均をそのまま出力

結果（3層、XORテスト）

Identity比率	XOR収束エポック
0%	2533
12.5%	1270 ← 最速
25%	1540
50%	1549

結論

• 12.5%のIdentityが最速収束
• しかしGated方式と大きな差はない

---

Phase 7: 深いネットワーク（10層）でのIdentity効果検証

着想（ユーザー）

「10層ぐらいないと、Identityを使うメリットが無い気がします」

深いネットワークでこそIdentity経路が有効なはず。

実装（edla_deep.cpp）

• 可変深さのネットワーク
• Identity配置オプション追加

結果（MNIST、10層）

方式	最高精度
Identity無し	11.70%（学習崩壊）
Identity有り（全層）	43.00%

約31%の改善！ 深いネットワークでIdentity経路が劇的に有効。

浅い vs 深い比較

深さ	Identity無し	Identity有り	効果
3層	85.90%	85.30%	-0.6%（効果なし）
12層	11.70%	43.00%	+31.3%

---

Phase 8: Identity配置の最適化

着想（ユーザー）

「9層と10層を繋ぐ箇所では勾配消失しても問題なさそう」 「出力に近い層はIdentity不要では？」

実験: Identity配置の比較

Identity範囲	最高精度	解釈
無し	11.70%	学習崩壊
全層（1-10）	43.00%	基準
前半のみ（1-5）	18.50%	部分的効果
後半のみ（6-10）	11.70%	効果なし

追加実験: 最終層を除外

Identity範囲	最高精度
層1-8	30.90%
層1-9	73.65% ← 最良！
層1-10（全層）	43.00%

重要な発見

1. 出力側の層（6-10）にIdentityは効果なし
2. 入力側の層（1-5）にこそIdentityが必要
3. 最終層を除外した方が性能が向上（73.65% > 43.00%）
4. 最終層はIdentityがあると「素通り情報」が出力を汚染

---

基本アルゴリズム

ED法の特徴

• P/Nニューロン対: 正（Positive）と負（Negative）のニューロンをペアで持つ
• 符号制約付き重み: weights_pp ≥ 0, weights_pn ≤ 0, weights_np ≤ 0, weights_nn ≥ 0
• sign(w)更新: 勾配ではなく重みの符号方向に更新
• 活性化関数: tanh(a/5) をスケーリングして [0,1] に正規化

更新式

d = target - output  (誤差)

if d > 0:
    Δw_pp = lr * d * g'(a) * x * sign(w_pp)
    Δw_np = lr * d * g'(a) * x * sign(w_np)
else:
    Δw_nn = lr * |d| * g'(a) * x * sign(w_nn)
    Δw_pn = lr * |d| * g'(a) * x * sign(w_pn)

---

実験1: Identity経路の導入

背景

• Logic Gate Networks (arXiv:2411.04732) の「Residual Initialization」概念を参考
• 深いネットワークで情報が途切れる問題への対策

Identity経路の実装

各層の構成:
  75% = Compute neurons (通常のED計算)
  25% = Identity neurons (入力平均をそのまま通す)

結果

設定	精度	備考
Identity無し（10層）	11.70%	学習崩壊
Identity全層	43.00%	改善あり
Identity層1-9	79.90%	最良
Identity層1-5のみ	18.50%	効果不足
Identity層6-10のみ	11.70%	効果なし

結論

• Identity経路は深いネットワークに必須
• 最終層（層10）にはIdentity不要（出力に直接情報が必要）
• 前半〜中盤の層でIdentityが効果的

---

実験2: ネットワーク幅の検討

比較設定

• 定幅: 128 → 128 → 128 → ... → 128
• 縮小幅: 128 → 96 → 72 → 54 → 41 → 30 → 30 → 30 → 30 → 30

結果

構成	精度
定幅（128固定）	約70%
縮小幅	79.90%

結論

• 幅を徐々に縮小する方が良い
• 後半の層は情報が集約されるため、少ないニューロンで十分

---

実験3: 学習率と安定性

問題

• lr=1.0: Epoch 3で崩壊（73.65%→30%）
• lr=0.5: Epoch 6で崩壊

解決策: 学習率減衰

lr = max(0.05, 0.3 * 0.95^(epoch-1))

結果

設定	最高精度	安定性
lr=1.0 固定	73.65%	❌ Epoch 3で崩壊
lr=0.5→decay	74.35%	❌ Epoch 6で崩壊
lr=0.3→decay(0.95)	79.90%	✅ 安定

学習曲線（lr=0.3, decay=0.95）

Epoch  1: 48.90%
Epoch  5: 72.30%
Epoch 10: 78.20%
Epoch 15: 79.90% ← ピーク
Epoch 17: 79.35%
Epoch 18: 78.85% ← プラトー開始

---

実験4: ED + BP ハイブリッド

アイデア

• 前半8層: ED法で学習（粗い特徴抽出）
• 後半2層: BP法で学習（精密な分類）

実装

• edla_hybrid.cpp を作成
• ED層とBP層を直列接続

結果

• うまく機能しなかった

原因分析

1. 重みの構造が異なる

   • ED法: 4つの符号制約付き重み行列（pp, pn, np, nn）
   • BP法: 1つの制約なし重み行列

2. 出力の意味が異なる

   • ED層: 正負を分離した表現
   • BP層: 通常の実数値特徴を期待

3. 更新方向が競合

   • ED法: sign(w)方向に押す
   • BP法: 勾配方向に引く
   • 互いに干渉する可能性

結論

ED法とBP法のパラメータは「意味が違いすぎる」ため、 同一ネットワーク内での直接結合は困難（「油と水」）

---

他手法との比較

MNIST精度ランキング

手法	精度	備考
SOTA (CNN + Ensemble)	99.87%	最先端
CNN (LeNet-5)	99.0%	古典的
Forward-Forward	~98.5%	BP不使用
MLP (BP)	98.4%	3層1000ニューロン
SVM	98.6%	非NN
ED法（本実験）	79.90%	-
ランダム	10%	ベースライン

位置づけ

• ED法は精度では他手法に遠く及ばない（約20%の差）
• しかし、計算の単純さ・メモリ効率では優位性あり

---

学習率微調整の見込み

予測

改善項目	見込み精度
学習率微調整のみ	80.5% ~ 82.0% (+0.6~2.1%)
+データ増加(60k)	82% ~ 85%
+ネットワーク拡大	84% ~ 87%
全部合わせて	85% ~ 88%

試すべきパラメータ

• 初期学習率: 0.25, 0.35
• 減衰率: 0.93, 0.97
• 最小学習率: 0.08, 0.10
• ウォームアップ: 3エポック

---

実装ファイル一覧

ファイル	用途	Phase
ed_entropy.py	Python版EDLA（エントロピー調整）	1
ed_mnist.py	MNIST用Python実装	1
ed_network.cpp	C++版基本実装	1
edla_paper.cpp	論文準拠実装（複数活性化関数対応）	2, 3
edla_residual.cpp	Gated EDLA実験	5
edla_residual2.cpp	Gated EDLA改良版	5
edla_identity.cpp	Identity経路導入版	6
edla_deep.cpp	深層ネットワーク + Identity配置実験	7, 8
cifar10_compare.cpp	CIFAR-10比較実験（EDLA vs LGN）	4
edla_hybrid.cpp	ED+BPハイブリッド（失敗）	-

---

今後の方向性

ED法を続ける場合

1. データ量増加: 10,000 → 60,000枚
2. ネットワーク幅拡大: 1.5倍（192→144→108→...）
3. 学習率スケジュール: Cosine Annealing, Cyclic LR

別アプローチ

1. 蒸留方式: ED出力を教師としてBPネットを別に学習
2. アンサンブル: ED分類器とBP分類器を投票で統合
3. 別タスク: 異常検知、強化学習など精度が絶対でない領域

---

主な知見

時系列で得られた知見

1. sign(w)の重要性（Phase 2）

   • 公式実装に delta *= sign(w) がある
   • これなしでは収束が不安定

2. 活性化関数の選択（Phase 3）

   • tanh(a/5) が最良（勾配2.3倍）
   • softmaxはP/N構造と相性悪い

3. 深いネットワークとIdentity（Phase 6-8）

   • 3層ではIdentity不要
   • 10層以上ではIdentity必須
   • 最終層はIdentity除外が最適

4. Identity配置の原則

   • 入力側の層（1-5）: 必須
   • 中間層（6-9）: あった方が良い
   • 最終層（10）: 不要（むしろ有害）

5. 学習率減衰が安定性の鍵

   • lr=0.3, decay=0.95 が最適
   • 高すぎると崩壊、低すぎると学習しない

6. ED法とBP法の直接結合は困難

   • パラメータの意味が根本的に異なる
   • ハイブリッドは別の工夫が必要

7. ED法の限界と利点

   • 精度ではBP系手法に劣る（~20%差）
   • 計算効率・メモリ効率では優位

---

実験環境

• OS: macOS
• コンパイラ: g++ (C++17)
• 最適化: -O3
• データセット: MNIST (10,000訓練 / 2,000テスト)
• 乱数シード: 42

---

最終更新: 2026年1月4日

agent が pdf を読めない

今まで Visual Studio 2022 の github copilot の chat モードでAIと戯れていたんですが、 Visual studio code を使うと、github copilot の agent モードというのがあって、こいつ、Visual Studio code で開いたプロジェクトディレクトリ下なら、トランザクション操作付きでファイルを読み書きできると知りました（今まで、全く気が付いていませんでした）。

agent にお願いしたら、markdown 形式のテキストファイルなら、がんがん書き込んでくれます。
ファイルを書き込むためには、最初 mcp-filesystem が必要だと思ってたんで、びっくり。
こちらで実行ボタンを押す必要がありますが、agent にバッチファイルを書かせて、バッチファイルを実行させる事もできます。
調子こいて、Android Studio でビルドしたエラー switch 文を if文に修正する仕事を、Visual Studio code 上で agent に任せて仕事をさせました。
そしたら、ちゃんと修正してくれる。
ただし、書き換えた中身をチェックしないと、前後の id とかいう変数を勝手に if文に組み込んで書き換えようとしたり、時々、とんでもない間違いをします
5000行あるファイルの修正では、

  foo = hoge.bar();

という同じ内容が記載されている行間をバッサリと削除してくれたりもしました。
ファイルが大きいと、エラーメッセージで指摘されている行うよりも下の箇所を修正しようとしたりしまして、「当該箇所より40行ほど上の箇所」とエージェントに指示しないと正しい箇所を修正してくれない時もありました。

まあ、そんな感じでagent使えるじゃん！と、気をよくしてPDFから処理をさせようとしたら、pdfが読めない
先日 markdown ファイルを印刷したいと思って、pandoc を入れました。
PDFを直接読んでくれたら楽なんですけど、まだ、そこまでAIは学習していないようで、mcp-server で pdf を読めるものを試してみましたが、今一つ
ぼやいてたら、ツールの変換内容によって、ちゃんと文字列として変換できない場合もあり、そんな時は精度が上がらないと教えていただきました

じゃ、pdf に変換は？ pandoc input.pdf -o output.md でOKかと思いきや、日本語関係でうまく行かない
で、こちらを試してみたんですが、これも日本語フォントがダメでうまく動かない
という事で、結局、こちらを参考に書きました

ほんと、やっつけです。ごめんなさい

pip install pymupdf4llm

して、下記 pdf2md.py を実行します。

C:\doc>python pdf2md.py

または、

C:\doc>python pdf2md.py hoge.pdf

以下、pdf2md.py です。

import os
import re
import sys
import glob
import pymupdf4llm
import pathlib


def extract_text_from_pdf(pdf_file):
    return pymupdf4llm.to_markdown(pdf_file)


def convert_pdf_to_marp(pdf_file):
    base_name = os.path.splitext(pdf_file)[0]
    md_file = f"{base_name}.md"

    try:
        # PDFからテキストを抽出
        extracted_text = extract_text_from_pdf(pdf_file)
        
        # 変更を保存
        with open(md_file, "w", encoding="utf-8") as file:
            file.write(extracted_text)

        print(f"Converted {pdf_file} to {md_file}")
    except Exception as e:
        print(f"Unexpected error occurred while processing {pdf_file}: {e}")

def main():
    if len(sys.argv) > 1:
        pdf_files = sys.argv[1:]
    else:
        pdf_files = glob.glob("*.pdf")
    
    if not pdf_files:
        print("No PDF files found or specified.")
        return

    for file in pdf_files:
        if os.path.isfile(file) and file.lower().endswith('.pdf'):
            convert_pdf_to_marp(file)
        else:
            print(f"Skipping {file}: Not a valid PDF file.")

if __name__ == "__main__":
    main()

Gradle 8.10.0 への苦難の記録(1)

Android の Project を Build しなくてはならなくなりました。気が重たい。Gradle のバージョンが上がると、必ずビルドが通らなくなります。今回も鬼のように問題が噴出して対応に1週間以上の時間を取られました。過去も大抵、数日から1週間以上の時間を要しました。

　なぜ、こんなに時間を取られるかというと、gradle の api が高速に移動するのでエンドユーザがバージョン毎にapiの書き換えや対応を強要される事、gradle 自身が変更により毎回バグを混入させる事にあります。 例を挙げれば、targetSdkVersion, compileSdkVersion は deprecate ですなんてメッセージが出て、信用して build.gradle の targetSdkVersion, compileSdkVersion の行を削除すると、Sync Gradle では、targetSdkVersion だか compileSdkVersion だかが見つからないとメッセージを表示して Sync に失敗するという体たらくです。 思いつきで、何でも簡単に変更しすぎです。gradle 自身も自身の下した api や property の廃棄や変更についていけてないし、バージョン間の整合も取れないので、ビルドシステム全体として見た場合は、ぐちゃぐちゃでカオスな状況が生じています。

　あなたが、Windows のアプリを開発していて、ある日 CreateFileEx という API名が GenerateFileEx という名前に変更されました。なんてアナウンスを受けたらどうなるか、想像がつきますか？ コンパイルオプション /EHsc が急に廃止されて、config.options というファイルに記述しないと動作しなくなったら、どうなるか想像がつきますか？例外を有効にするオプションがデフォルト true から false に変更されたら、どうなるか想像がつきますか？

gradle では、それが日常的に病的に起こります。数か月前までビルドが通っていたはずなのに、ビルドが壊れて動かなくなるんです。... was moved. ... wad deprecated. ... was deprecated. ... was moved. まぁ、まだ moved や deprecated を表示してくれるようになっただけでも有り難いんですけどね。以前はエラーメッセージを検索して StackOverflowを見て、deprecated だった事を知って対策してましたから。ただ、エラーメッセージを検索してネットの情報を調べないと対処方法がわからないのは、相変わらずです。

  Copilot くんにお願いして名称の変更に限定して、変更をまとめてもらいました。

私の記憶が確かならば、この表は氷山の一角です。taskを使用している場合、taskの依存関係を記述しなければならないのですが、ヒステリックにtask名が変更されて、その都度、プロジェクトの修正を余儀なくされました。ある機能のtask名は、3回以上名前が変更されました。debugは間違ってるreleaseだ、いやJarじゃないRFileだといった具合に…。ころころと名前変えられたら、プロジェクトファイルも全部書き換えないと動きません。ファイルをコピーする関数名も変更されましたし、gradleの変更頻度は病的で、まともではありません。担当者のお気持ちで担当者がその名前が気に入らなければ名前が変更されます。エンドユーザは、気まぐれで変更された名前に合わせるようプロジェクトを修正しなければなりません。毎回毎回、山のように修正を余儀なくされます。

イライラはピークに達するものの落ち着いて、次のような書き込みをする決断に至ります。

Why does gradle deprecate and remove things so often? に象徴されていると思います。

　話を戻します。

　今回ビルドするプロジェクトは、legacy な Java による Application の話であり、KotlinでもGroovyでもありません。AndroidStudioにより作成できるプロジェクトは、Kotlin と Groovy の2択でlegacyのプロジェクトという選択肢が無いのも頭の痛い問題です。KotlinでもGroovyでもないのに、プロジェクトのバージョンアップ中に kotlin や groovy といったエラーを見かけ、これらのエラーを見る度に一体何のエラーなのか意味不明で頭の痛い思いをしました。

ライブラリのビルド

 gradle-3.5-all.zip と gradle-3.5.2

 gradle-7.5-all.zip と gradle-7.4.2 

以上の組み合わせから 

 gradle-8.14.1-bin.zip と gradle-10.0.0

へと移行する形になりました。ファイル名も -all から -bin に変更されています。なんでも allはファイルサイズがデカくなるからなんだそうです。gradle-8.14.0-all.zip ってやってエラーになるから何事や？と思ったら、知らんがな。いちいち、こんな調子で時間を取られます。

ここを参照すればわかるように私も質問者と同じ感覚です。

尚、試行錯誤している間は gradle-8.14.0-bin.zip しか出ていませんでしたが、途中で8.14.1がリリースされて、まともにビルドできるようになりました。その間はライブラリの依存関係バグがあったのか、何をやってもビルドが通りませんでした。

gradle-8.x になって変更された箇所は

・AndroidManifest.xml から package="com.foo.bar" の属性が削除された事

・build.gradle(app) で android { } の 下に namespace = "com.foo.bar" の記述が必要になった事。

ビルド時にサジェストがあったので、これに関しては比較的親切な対応と言えます。

しかし、こんな変更必要ですか？案の定、この変更によって、package.R.class が出力されないバグが混入し、アプリケーションのビルド時に、package R does not exist. というエラーが発生して、apk が作成できませんでしたが、gradle-8.10.1 で修正されました。gradle に振り回されて修正しても直らない地獄を徘徊しているうちに修正されました。

今回も deprecated の嵐で、バージョンアップすると、ことごとくビルドが失敗しました。何箇所も問題が発生し、たくさんの修正が必要でした。ライブラリをまともにビルドできるまでに4日以上費やしました。この他に android API の deprecated 対応にも4日以上の時間を取られました。

まずは、JDKのバージョンの整理が必要でした。今までは、なんとなくビルドできていましたが、そうはいきませんでした。

gradle は JDK のバージョンに煩い。jdk-11 じゃないと動きません。jdk-17 じゃないと動きません。jdk-18じゃないと動きません。と、色々注文が多いです。開発環境では、Oracleがインストールされていると、oracle が javac に対して path を通していたり、Visual Studio が javac に path を通していたり、Android Studio は SDK に設定されている JDKを使用しようと毎回 javac をリセットしたり、gradle は GRADLE 専用の JDK の PATH を設定してたりします。バージョンアップ中に GRADLE_JDK_LOCAL_PATH という名前への変更が行われたので、とにかく専用のPATHが設定されているという事です。これらpathの仕様は担当者の気まぐれで変更される恐れがあります。ライブラリのビルドにはJDK-17、アプリのビルドにはJDK-11を使用しました。プロジェクト＞設定＞検索＞gradle で、モジュール>gradle の JDKの指定と、ウィンドウズの環境変数 path を制御する事で自分は対応しました。これに関しては gradleが JDKxxでは動作しないとメッセージを表示してくれるので対応しやすいです。

いろいろありすぎて、書ききれません…続きます。

android ProgressBar が deprecated

ProgressBar が deprecated になっていた。
ダイアログを表示すると、他の操作ができないから埋込レイアウトにしとけ
というのがGoogle先生の指示なんだけど、アプリケーションのステート的には、このタスクが終了しないと、どのみち次のオペレーションはできないので、埋込にする意味がないと思う。
処理の途中でアプリを切り替えられると、onDestroyが呼ばれるので、それも困る
そんな時はやり直しですしおすし。
それにダイアログを表示していてもアプリは切り替えられる
埋め込んだところで、大差がないと思うのである。
で、いちいち埋込の画面を作成するのは、大変なのでプログレスダイアログは欲しい。

package com.foo.Helper;

import android.app.Dialog;
import android.content.DialogInterface;
import android.os.Bundle;
import android.content.Context;

import androidx.annotation.NonNull;
import androidx.annotation.Nullable;
import androidx.appcompat.app.AlertDialog;
import androidx.fragment.app.DialogFragment;
import android.widget.ProgressBar;

import com.foo.helper.R;

public class CommonProgressDialog extends DialogFragment {

	private final Context context_;

	private final String title_;

	private final String message_;

	private AlertDialog.Builder builder_;

	private AlertDialog dialog_;

	private ProgressBar progressBar_;

	@NonNull
	@Override
	public Dialog onCreateDialog(@Nullable Bundle savedInstanceState) {
		dialog_ = builder_.create();
		return dialog_;
	}

	private void BuildBase(final Context context, final String title, final String message) {
		builder_ = new AlertDialog.Builder(context)
				.setView(R.layout.progress)
				.setTitle(title)
				.setCancelable(false)
				//.setCanceledOnTouchOutside(false)
				.setMessage(message);
	}

	public CommonProgressDialog(final Context context, final String title, final String message) {
		this.context_ = context;
		this.title_ = title;
		this.message_ = message;
		BuildBase(context, title, message);
	}

	/// 中止ボタンを設置する
	public void setNegative(final DialogInterface.OnClickListener l) {
		if( dialog_ == null ) return;
		dialog_.setButton(DialogInterface.BUTTON_NEGATIVE, getString(android.R.string.cancel), l);
	}

	public void setMax(int maxValue) {
		if( dialog_ == null) return;
		ProgressBar pb = dialog_.findViewById(R.id.progress_bar);
		if( pb != null ) {
			pb.setMax(maxValue);
		}
	}

	public void setProgress(int progress) {
		if( dialog_ == null) return;
		ProgressBar pb = dialog_.findViewById(R.id.progress_bar);
		if( pb != null ) {
			pb.setProgress(progress);
		}
	}


	public void show() {
		if( dialog_ == null) {
			dialog_ = builder_.create();
		}
		dialog_.show();
	}

	public void dismiss() {
		dialog_.dismiss();
		dialog_ = null;
	}

	/*
	public CommonProgressDialog(Context context) {
		super(context);
		setProgressStyle(ProgressDialog.STYLE_HORIZONTAL);
	}
	public CommonProgressDialog(Context context, int theme) {
		super(context,theme);
		setProgressStyle(ProgressDialog.STYLE_HORIZONTAL);
	}

	 */
}

progress.xml

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="horizontal"
    android:padding="20dp">
    <ProgressBar
        android:id="@+id/progress_bar"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_weight="1" />

    <TextView
        android:layout_width="0dp"
        android:layout_height="match_parent"
        android:layout_weight="4"
        android:gravity="center"
        android:text="Please wait! This may take a moment." />
</LinearLayout>

WPF ComboBoxにおけるIMEの制御

いやー、WPFのTextBoxならIMEの制御を設定できるんですけど、ComboBox のEditableをFalseのままで、IsTextSearchEnabled="True"とか設定して、項目を[コード]:[名前]にした時にIMEをオフにしないと、コード入力が効かないんですわ。
いろいろ検索してみたんですが、まともなのが無かったんで、書きましたよ。はい。

public class Util
{

    [DllImport("imm32.dll")]
    public static extern IntPtr ImmGetContext(IntPtr hWnd);

    [DllImport("imm32.dll")]
    public static extern Boolean ImmReleaseContext(IntPtr hWnd);

    [DllImport("imm32.dll")]
    public static extern Boolean ImmSetConversionStatus(IntPtr hIMC, Int32 fdwConversion, Int32 fdwSentence);

    [DllImport("imm32.dll")]
    public static extern Boolean ImmSetOpenStatus(IntPtr hIMC, Int32 fOpen);

    [DllImport("imm32.dll")]
    public static extern Int32 ImmGetOpenStatus(IntPtr hIMC);

    [DllImport("imm32.dll")]
    public static extern Int32 ImmAssociateContext(IntPtr hWnd, Int32 hIMC);

    const Int32 IME_CMODE_ALPHANUMERIC = 0x0000;
    const Int32 IME_CMODE_NATIVE = 0x0001;
    const Int32 IME_CMODE_CHINESE = IME_CMODE_NATIVE;
    const Int32 IME_CMODE_HANGUL = IME_CMODE_NATIVE;
    const Int32 IME_CMODE_JAPANESE = IME_CMODE_NATIVE;
    const Int32 IME_CMODE_KATAKANA = 0x0002;  // only effect under IME_CMODE_NATIVE
    const Int32 IME_CMODE_LANGUAGE = 0x0003;
    const Int32 IME_CMODE_FULLSHAPE = 0x0008;
    const Int32 IME_CMODE_ROMAN = 0x0010;
    const Int32 IME_CMODE_CHARCODE = 0x0020;
    const Int32 IME_CMODE_HANJACONVERT = 0x0040;
    const Int32 IME_CMODE_NATIVESYMBOL = 0x0080;

    const Int32 IME_CMODE_SOFTKBD = 0x0080;
    const Int32 IME_CMODE_NOCONVERSION = 0x0100;
    const Int32 IME_CMODE_EUDC = 0x0200;
    const Int32 IME_CMODE_SYMBOL = 0x0400;
    const Int32 IME_CMODE_FIXED = 0x0800;


    const Int32 IME_CONFIG_GENERAL = 1;
    const Int32 IME_CONFIG_REGISTERWORD = 2;
    const Int32 IME_CONFIG_SELECTDICTIONARY = 3;

    const Int32 IME_SMODE_NONE = 0x0; // センテンスに関する情報はなし
    const Int32 IME_SMODE_PLURALCLAUSE = 0x01; // 変換のための複文情報を使う
    const Int32 IME_SMODE_SINGLECONVERT = 0x02; // 単漢字変換する
    const Int32 IME_SMODE_AUTOMATIC = 0x04; // 自動モードで変換
    const Int32 IME_SMODE_PHRASEPREDICT = 0x08; // 次の文字を予想するためにフレーズ情報を使う
    const Int32 IME_SMODE_CONVERSATION = 0x0010;

    /// <summary>
    /// IMEモード
    /// </summary>
    public enum ImeMode
    {
        Off = 1, // IME オフ
        Hiragana = 2, // 全角ひらがな
        Katakana = 3, // 全角カタカナ
        HalfKatakana = 4, // 半角カタカナ
        Alpha = 5, // 全角英数
        HalfAlpha = 6,　// 半角英数
    };


    /// <summary>
    /// IMEを制御する。WPF ComboBox 等の一部コントロールでは、IMEの制御ができない。そのための対応。
    /// TextBox等では、下記で制御できる
    /// <TextBox InputMethod.IsInputMethodEnabled="False"/>　IME無効
    /// <TextBox InputMethod.PreferredImeState="On" InputMethod.PreferredImeConversionMode="FullShape,Native"/>　ひらがな
    /// <TextBox InputMethod.PreferredImeState="On" InputMethod.PreferredImeConversionMode="Katakana,FullShape"/> カタカナ
    /// <TextBox InputMethod.PreferredImeState="On" InputMethod.PreferredImeConversionMode="Katakana,Native"/>　半角カタカナ
    /// <TextBox InputMethod.PreferredImeState="On" InputMethod.PreferredImeConversionMode="Alphanumeric,FullShape"/>　全角英数
    /// <TextBox InputMethod.PreferredImeState="On" InputMethod.PreferredImeConversionMode="Alphanumeric"/> 半角英数
    /// </summary>
    /// <param name="ctrl"></param>
    /// <param name="mode"></param>
    public static void SetImeMode(Control ctrl, ImeMode mode)
    {
        IntPtr handle = IntPtr.Zero;
        HwndSource hwnd = PresentationSource.FromVisual(ctrl) as HwndSource;
        if (hwnd != null)
        {
            handle = hwnd.Handle;
        }
        IntPtr himc = ImmGetContext(handle);
        Int32 dwConversion = 0;

        try
        {
            if( mode == ImeMode.Off)
            {
                if (ImmGetOpenStatus(himc) != 0)
                {
                    ImmSetOpenStatus(himc, 0);
                }
                return;
            } else
            {
                if( ImmGetOpenStatus(himc) == 0)
                {
                    ImmSetOpenStatus(himc, 1);
                }
            }
            switch (mode)
            {
                case ImeMode.Hiragana:
                    ImmSetConversionStatus(himc, IME_CMODE_FULLSHAPE | IME_CMODE_JAPANESE, IME_SMODE_AUTOMATIC);
                    break;
                case ImeMode.Katakana:
                    ImmSetConversionStatus(himc, IME_CMODE_FULLSHAPE | IME_CMODE_LANGUAGE | IME_CMODE_KATAKANA, IME_SMODE_AUTOMATIC);
                    break;
                case ImeMode.HalfKatakana:
                    ImmSetConversionStatus(himc, IME_CMODE_LANGUAGE | IME_CMODE_KATAKANA, IME_SMODE_AUTOMATIC);
                    break;
                case ImeMode.Alpha:
                    ImmSetConversionStatus(himc, IME_CMODE_FULLSHAPE | IME_CMODE_ROMAN, IME_SMODE_AUTOMATIC);
                    break;
                case ImeMode.HalfAlpha:
                    ImmSetConversionStatus(himc, IME_CMODE_ROMAN, IME_SMODE_AUTOMATIC);
                    break;
            }
        }
        finally
        {
            ImmReleaseContext(handle);
        }

    }

}

使い方は、GotFocusイベントをハンドリングして

   private void FooComboBox_GotFocus(object sender, RoutedEventArgs e)
   {
       Util.SetImeMode(sender as ComboBox, Util.ImeMode.Off);
   }

という感じ

コマンドプロンプトとCURLのエスケープ

コマンドプロンプトのエスケープは、\ と " がエスケープ処理の対象となります。

CURL のエスケープは、\ { } | がエスケープ処理の対象となります。

\ をエスケープすると、コマンドプロンプト用のエスケープとCURL用のエスケープが複合し、\\\\という形になります。

ふむふむ…
ふむふむ…
ふむふむふむふむ？…

コマンドプロンプトは \\\\ を " として取り扱います…

(｀□′)╯┴┴