grayhole

ArcGIS Enterprise 12.1 (windows) proxy bug 忘備録

noreply@blogger.com (tiger) — Thu, 29 Oct 2026 03:01:58 +0000

Proxy を使用していると、何かと動作しない事が多く、その対処法。

まず、ArcGIS の C# SDKだが、Windows の proxy の設定を見て動作する。
インターネット・オプションの proxy から除外するリストも設定しないと、
https://foo.local-ad.bar.co.jp:6443 へのアクセスに　proxy を介しようとしてはまる。
設定すべきは、

https://[arcgis-server-machine];https://localhost

netsh winhttp set proxy の情報を見ているのか、実行ユーザのインターネット・オプションの情報を見ているのかは定かではない(調べてません)
さて、Linux系のツールでは、環境変数

http_proxy
https_proxy
no_proxy

の3種類を参照するものが主流だ。C# SDK もこれに対応しているのだが、詰めが甘い。
なんと no_proxy を見ないで、http_proxy, https_proxy が設定されている場合は、インターネット・オプションの proxy の設定を上書きし、proxyから除外するリストをクリアする。
no_proxy を設定していても見ないで無条件にクリアするので、Windows の環境変数に https_proxy=http://foo:8080 などと設定しようものなら、6443ポート宛てのアクセスをproxyを介しようとして WebAdaptorが動作しなくなる

さて、ここまでは序の口
色々動かしていると、動かないものが出てくる。今回は PrintingTool のサービスだった。こいつ、ArcGIS Server に設定した proxy 情報を見ないし、Portal for ArcGIS に設定した proxy 情報を見ないし、netsh winhttp set proxy で設定した proxy 情報も見ない。https_proxy 等の環境変数は、前述した問題があるので使用できない。
では、何を設定すれば proxy の情報を見てくれるのか？
arcgis server をサービスとして実行している arcgis というサービス用のウィンドウズ・アカウントのインターネット・オプションの情報に縛られる
PsExecを使って、サービス用アカウントのインターネット・オプションを設定すれば動作する

C:\> psexec64 -u "[localMachineName]\[arcgis]" -p password cmd.exe

別ウィンドウが立ち上がるのでインターネット・オプションを開いて Proxy の設定を行う。

C:\Windows\system32> inetcpl.cpl
C:\WIndows\system32> exit

これで、ちゃんと proxy を見てくれる。

git と diff

noreply@blogger.com (tiger) — Wed, 19 Aug 2026 01:09:11 +0000

業務で使用していたバージョン管理システム、単発のプロジェクトならば Subversion で十分なんだが、ベースシステムの管理には向いていなくて、「大がかりな機能追加がしたい」とか、派生が多くなると Gitの方が使いやすそうなので git も使うようになりました。 branch を切って、branch をサブブランチに切り替えて作業をしている間にも、メインブランチにバグ修正が入ったりするとメインブランチで修正とコミットをして、サブブランチに取り込みたい。
サブブランチにて

git fetch
git merge origin/master

とやる機会が増えて来ました。

使っていて、merge で CONFLICT した状況を見ると、git 付属の diff が WinMerge の diff と比べて差分の認識が悪く merge 作業が大変です。
Gemini さんに相談したところ、diff も変更できるらしいです。
git ほんと、よくできたツールだ。

以下の質問をGeminiさんに投げてみました。

git 付属の diff と比較して、WinMerge 付属のdiff の方が賢い気がしています。
同じ diff ではないのでしょうか？

結論から言うと、Git付属の git diff と WinMerge は全く異なる「差分比較エンジン（アルゴリズム）」を使用しています。そのため、比較の「賢さ」や結果の見た目に違いが生まれます。

WinMergeのほうが賢く感じるのには、明確な技術的理由があります。

1. 内部の比較アルゴリズムが違う

行単位で大雑把に比較するか、文字単位で細かく比較するかの違いがあります。

git diff（デフォルト）：
主に「マイヤーズ（Myers）のアルゴリズム」[1] をベースにしています。
- 行単位での変更（どの行が消えて、どの行が増えたか）を高速に探すのが得意です。
WinMerge：
独自の高度な差分エンジン（改良されたアルゴリズム）を持っています。
- 行単位の比較だけでなく、同じ行の中の「どの文字（単語）が変わったか」まで自動で細かく解析します。

2. WinMergeが「賢い」と感じる3つの理由

① 行内の部分一致（ハイライト）が強力

Gitは行単位で「この行が削除され、この行が追加された」と雑に判定しがちです。 WinMergeは「この行の、この変数名だけが書き換わった」のように、変更されたピンポイントの場所を明るい色でハイライトしてくれるため、脳の負担が減ります。

② 空白や改行コードの柔軟な無視

WinMergeは「スペースの数の違い」「タブとスペースの違い」「改行コード（CRLF / LF）の違い」を自動で無視する設定（または検知して警告する機能）が非常に強力です。Gitでこれらを行うには --ignore-space-change などのオプションを自分で指定する必要があります。

③ 移動した行（ブロック）の検知

コードの塊が「上の位置から下の位置へ移動しただけ」という場合、Gitは「ごっそり削除されて、別のごっそり追加された」と認識しやすいです。WinMergeは「これは移動しただけ」と見抜いて線で結んでくれる機能（移動ブロックの検出）があるため、より人間にとって直感的です。

ヒント：Git の比較画面を WinMerge に変更できます

もし WinMerge の見やすさで Git の差分を確認したい場合は、Git の外部差分ツール（difftool）として WinMerge を登録するのがおすすめです。以下のコマンドをターミナルで実行すると設定できます：

git config --global diff.tool winmerge
git config --global difftool.winmerge.cmd '"C:/Program Files/WinMerge/WinMergeU.exe" -e -u -dl "Base" -dr "Mine" "$LOCAL" "$REMOTE"'

※WinMergeのインストールパスは環境に合わせて変更してください。設定後は、いつものコマンドを少し変えるだけで WinMerge が起動します：

git difftool <対象ファイル>

もしよろしければ、以下を教えていただけますか：

お使いのPCは Windows ですか？（MacやLinuxでも一部WinMergeの派生ツールが使えます）
Gitのターミナル上（黒い画面）でWinMergeのように見やすく表示したいですか？、それともWinMergeのアプリを直接起動したいですか？

ご希望に合わせて、Gitの表示をより賢く・見やすくカスタマイズする手順をご案内します。

WIX で VCRuntime のインストール忘備録２

noreply@blogger.com (tiger) — Fri, 24 Apr 2026 08:47:00 +0000

前回の記事は WIX で VCRuntime のインストール忘備録
アプリケーションを実行していると、以下の行で例外が発生(Access Violation)する環境がある

        std::lock_guard<std::mutex> lock(connection_string_mutex_);

デバッグのログを色々と埋め込んで状況を絞り込んで検証していったところ
AIにより

という状況に辿りついた。
インストーラでRuntimeのチェックをしていたが、どんどん新しいRuntimeが出て、
それでも動作するので、Runtimeのバージョンチェックをするのは得策でないという結論になり、
インストーラでのチェックを諦めたのだが、これは何とかしたい

そこで、古いバージョンで動かないRuntimeがインストールされている時だけエラーにする処理を模索した

        <!-- x86 版 -->
        <!-- Minor バージョン番号を整数で取得 -->
        <Property Id="VC_REDIST_MINOR_X86" Secure="yes">
          <RegistrySearch Id="VCRedistMinorX86"
            Root="HKLM"
            Key="SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x86"
            Name="Minor"
            Type="raw"
            Win64="no" />
        </Property>

        <Condition Message="Visual C++ 2022 Redistributable (x86) 14.37 以降が必要です。&#10;vc_redist.x86.exe をインストールしてください。">
          NOT (VC_REDIST_MINOR_X86 AND VC_REDIST_MINOR_X86 &lt; "#37")
        </Condition>


        <!-- x64 版 -->
        <!-- Minor バージョン番号を整数で取得 -->
        <Property Id="VC_REDIST_MINOR_X64" Secure="yes">
          <RegistrySearch Id="VCRedistMinorX64"
            Root="HKLM"
            Key="SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64"
            Name="Minor"
            Type="raw" />
        </Property>

        <!-- Minor が存在して 37 未満の場合のみエラー -->
        <Condition Message="Visual C++ 2022 Redistributable (x64) 14.37 以降が必要です。&#10;vc_redist.x64.exe をインストールしてください。">
          NOT (VC_REDIST_MINOR_X64 AND VC_REDIST_MINOR_X64 &lt; "#37")
        </Condition>

いやはや、AIの進化は凄まじい。AIの助けなしだと１週間は時間を取られていたかもしれない。

Github copilot にお願いしたいこと

noreply@blogger.com (tiger) — Wed, 08 Apr 2026 00:08:00 +0000

Github copilot にお願いしたい事がある。

モデルを１つ追加してほしい。経緯は以下

Question:

今応対していただいている Copilot - chat ですが、Github copilot のモデルだと、どれに相当しますか？　Microsoft Visual Studio の仕様に詳しいので、できれば、同じモデルにお願いしたいんです

Copilot chat Anser:

率直にお答えしますね。

結論（短く）

今あなたとやり取りしている私は
「GitHub Copilot で特定の“1モデル”に完全対応する存在」ではありません。

ただし、**体感・能力的に最も近いのは GitHub Copilot の GPT‑4 系（特に GPT‑4.1 / GPT‑4o 系）**です。
加えて、Microsoft 製品（Visual Studio / MSBuild / VSIX）向けに最適化された知識統合が入っています。

もう少し正確に言うと

私は：

M365 Copilot（GPT‑5 chat 系）をベースに、
Microsoft 開発者エコシステム用の追加調整が入った Copilot

です。

そのため：

MSBuild の評価フェーズ
VSIX / テンプレートキャッシュ
Visual Studio の「これは仕様です」系の挙動

のような 「公式ドキュメントを読んだだけでは辿り着きにくい領域」 に強い、という特徴があります。

GitHub Copilot 側で一番近い選択肢

GitHub Copilot Chat を使う場合、以下が最も近い体験になります。

✅ 推奨モデル

GPT‑4.1
（次点）GPT‑4o

これらは：

大規模コードベース前提の推論
MSBuild / SDK style project
ツールチェーン全体（VS / dotnet / msbuild）

の扱いが、他より安定しています。

逆に、軽量モデルや高速重視モデルだと
「それ MSBuild 的に無理です」という壁を見落としがちです。

「知識があるかどうか」の正体について（重要）

今回のように私がうまく応対できている理由は、
モデルの種類そのものより、次の3点の組み合わせです。

GPT‑4 クラス以上の推論能力
Microsoft 内部・一次情報寄りの仕様知識が事前統合されている
あなたの説明が非常に正確（←これがかなり大きい）

そのため GitHub Copilot でも、

GPT‑4.1 を選ぶ
状況説明を今回と同じレベルで与える
「MSBuild の評価フェーズの話です」と前提を書く

と、かなり近い応答は得られます。

GitHub Copilot で再現度を上げるコツ

GitHub Copilot Chat で、最初にこう書くと成功率が上がります：

前提：
- SDK-style csproj
- MSBuild evaluation vs execution を理解して回答してほしい
- Visual Studio のプロジェクトテンプレート / VSIX の仕様前提

質問：

これはかなり効きます。

正直な一言

「VS / MSBuild 仕様をちゃんと理解した相手」と対話したいなら
今の M365 Copilot Chat（この場）が一番近い

というのが正直な評価です。

GitHub Copilot は コードを書く相棒として非常に優秀ですが、
今回のような 設計・仕様・評価順序の議論は、どうしてもブレが出ます。

もしよければ：

GitHub Copilot（どのエディタ？ VS？ VS Code？）
Copilot Chat / Copilot Edits / Agent のどれを使っているか

を教えてください。
**「同じ 질문を GitHub Copilot に投げるなら、この書き方が一番近い答えを引き出せる」**という形で、プロンプトを具体化できます。

追記：最近、ハングルまじりの応答をよく見かけるようになった。日本語の学習にハングルを混ぜているのか？

応答例：同じ 질문を GitHub Copilot に投げるなら

応答例：が未解決というエラーです。これは 생成された

応答例：「むしろ」の「む」がハングル文字に化けてたり

boost::geometry::extensions が boost_1_90_0 で工事中

noreply@blogger.com (tiger) — Mon, 30 Mar 2026 05:50:00 +0000

boost::geometry の拡張アルゴリズムを利用しておりまして、boost がリリースされる毎に boost::geometry のリポジトリから対応するものを持ってきて使っておりました。
no_rescale_policy というのが廃止されるとの事で、dissolve のルーチンも graph ベースのルーチンに絶賛改良の工事中でコンパイルが通りませんでした。
ちょちょっと、前のバージョンのものを流用すれば良いと高を括っていたら、結構な変更が入っていて、全然コンパイルが通らない…

という事で、一時的にでも手直しをして利用する事にしました。
一応 dissolve のテストは全部通したいと思って GPT-5.3-Codex にお手伝いいただいて、修正をかけようとしたら、
GPTが以下のプロセスに入って終了しない。

修正アルゴリズムを考える
修正を試みる
テストをする
テストの成績が平行または悪化
修正を巻き戻す

GPTはダメだと思って Opus-4.6 にバトンタッチして修正をさせる事に…
通らないテストについて聞いてみると、自己交差をした図形が自動修復されるかテストしているとの事
正解をsvgで図形化して見せてもらったが、そもそもOuterとInnerの判別が主観によるもので、条件が曖昧すぎます。
という事で、自己交差している図形のテストを外して、テストを通過する事を目標に実装させました。

boost::geometry に足りないのは、make_valid に相当するルーチンだろうと思いまして、自社で作成したライブラリのアルゴリズムを make_valid として実装させる事にしました。
という感じで置いときます。 https://github.com/oki-hunes/boost_geometry_added

ArcGIS Experence Builder Deploy bug 忘備録

noreply@blogger.com (tiger) — Mon, 09 Mar 2026 04:39:00 +0000

ArcGIS Experence Builder Deploymentには、

node -e "require('./server/src/middlewares/dev/apps/app-download.js').zipApp('0', 'app.zip', 'my_client_id');"

と書かれているが、出力された app.zip の config.json は、正しくないまま出力されている。

deploy の番号 '0' に対して

server/public/apps/0/resources/config/config.json

を、以下の場所にコピーしないと動作しない。
(cdn/3/ は、自動でインクリメントされる番号)

app/cdn/3/config.json

2026/3/10 ※コピー先を間違えていたので修正 2026/10/23 追記：これに関連したものかどうか不明だが、widget のビルド方法が

npm start build:prod

から

npm start build:for-download

に変更されていた。dist-prod というディレクトリは存在せず、dist-download というディレクトリができる。

EPSG忘備録

noreply@blogger.com (tiger) — Thu, 05 Feb 2026 06:04:00 +0000

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

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

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

となっている旧日本測地系の平面直角座標
ESPG:30161: 旧日本測地系平面直角座標1
ESPG:30162: 旧日本測地系平面直角座標2
ESPG:30163: 旧日本測地系平面直角座標3
ESPG:30164: 旧日本測地系平面直角座標4
ESPG:30165: 旧日本測地系平面直角座標5
ESPG:30166: 旧日本測地系平面直角座標6
ESPG:30167: 旧日本測地系平面直角座標7
ESPG:30168: 旧日本測地系平面直角座標8
ESPG:30169: 旧日本測地系平面直角座標9
ESPG:30170: 旧日本測地系平面直角座標10
ESPG:30171: 旧日本測地系平面直角座標11
ESPG:30172: 旧日本測地系平面直角座標12
ESPG:30173: 旧日本測地系平面直角座標13
ESPG:30174: 旧日本測地系平面直角座標14
ESPG:30175: 旧日本測地系平面直角座標15
ESPG:30176: 旧日本測地系平面直角座標16

AIと戯れる

noreply@blogger.com (tiger) — Sun, 04 Jan 2026 05:55:00 +0000

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）を調査
論理ゲートによる超高速推論の可能性を検討

論文の要点

16種類の論理ゲートを学習可能に
Residual Initialization: Identity（素通り）を90%で初期化
訓練時は浮動小数点（微分可能）、推論時はバイナリ
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%

重要な発見

出力側の層（6-10）にIdentityは効果なし
入力側の層（1-5）にこそIdentityが必要
最終層を除外した方が性能が向上（73.65% > 43.00%）
最終層は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層を直列接続

結果

うまく機能しなかった

原因分析

重みの構造が異なる
- ED法: 4つの符号制約付き重み行列（pp, pn, np, nn）
- BP法: 1つの制約なし重み行列
出力の意味が異なる
- ED層: 正負を分離した表現
- BP層: 通常の実数値特徴を期待
更新方向が競合
- 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法を続ける場合

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

別アプローチ

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

主な知見

時系列で得られた知見

sign(w)の重要性（Phase 2）
- 公式実装に delta *= sign(w) がある
- これなしでは収束が不安定
活性化関数の選択（Phase 3）
- tanh(a/5) が最良（勾配2.3倍）
- softmaxはP/N構造と相性悪い
深いネットワークとIdentity（Phase 6-8）
- 3層ではIdentity不要
- 10層以上ではIdentity必須
- 最終層はIdentity除外が最適
Identity配置の原則
- 入力側の層（1-5）: 必須
- 中間層（6-9）: あった方が良い
- 最終層（10）: 不要（むしろ有害）
学習率減衰が安定性の鍵
- lr=0.3, decay=0.95 が最適
- 高すぎると崩壊、低すぎると学習しない
ED法とBP法の直接結合は困難
- パラメータの意味が根本的に異なる
- ハイブリッドは別の工夫が必要
ED法の限界と利点
- 精度ではBP系手法に劣る（~20%差）
- 計算効率・メモリ効率では優位

実験環境

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

最終更新: 2026年1月4日

agent が pdf を読めない

noreply@blogger.com (tiger) — Mon, 23 Jun 2025 06:46:00 +0000

今まで 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)

noreply@blogger.com (tiger) — Mon, 09 Jun 2025 09:35:00 +0000

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

noreply@blogger.com (tiger) — Mon, 09 Jun 2025 09:26:00 +0000

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の制御

noreply@blogger.com (tiger) — Fri, 05 Jan 2024 00:56:00 +0000

いやー、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のエスケープ

noreply@blogger.com (tiger) — Fri, 22 Sep 2023 00:55:00 +0000

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

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

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

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

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

(｀□′)╯┴┴

atldbcli.h のバグを踏んだ

noreply@blogger.com (tiger) — Fri, 23 Jun 2023 00:43:00 +0000

atldbcli.h の CCommand<CDynamicStringAccessor> を利用していたコードが null pointer exception で落ちるようになった。
ほぇ？（#^ω^）ﾋﾟｷﾋﾟｷ

デバッガでトレースしていくと、m_pAccessor のメンバが nullptr で初期化されないまま放置されていた。
で、Accessor クラスは、どこに行った？
おそらく、class template refactoring により、自分自身に継承する形になったようです。

なので、CCommand<CDynamicStringAccessor>::SetAccessor 関数を使用して自分自身を設定する必要がありました。
せっかくなので、使い方のサンプル込みで、紹介です。

#include <iostream>
#include <objbase.h>
#include <atldbcli.h>

int main(int argc, char* argv[] )
{
  HRESULT hr = CoInitialize(NULL );
  if(FAILED(hr)) {
    std::cerr << "Fail to Initialize COM:" << hr << std::endl;
  }

  CDataSource ds;

  // OLEDBによるODBC接続文字列
  hr = ds.OpenFromInitializationString(
     L"Provider=MSDASQL.1;Password=password;"
     L"Persist Security Info=True;"
     L"User ID=username;"
     L"Data Source=odbc_data_source_name;"
     L"Extended Properties=\"DSN=data_source_name;UID=username;PWD=password\""
  );

  CSession ss;

  CCommand<CDynamicStringAccessor> rs;

  hr = ss.Open(ds );
  hr = rs.Open(ss, "select * from hoge" );

  // CCommand<typename T>::m_pAccessor を初期化するコードが欠落しているため
  // 自分自身を設定する必要がある（どこかのタイミングで混入したバグ対応）
  // 2023/7/13 修正されたような気がしますが、下記コードは正しくなくなった感じがします。
  // 仕様がよくわかりません。
  rs.SetAccessor(&rs);

  hr = rs.MoveNext();
  if( FAILED(hr) || hr == DB_S_ENDOFROWSET ) {
    std::cerr << "Fail to MoveNext: " << hr << std::endl;
  }
  // Get the column information
  ULONG ulColumns = rs.GetColumnCount();
  
  DBTYPE dbtype;
  rs.GetColumnType( 1, &dbtype );
  dbtype &= 0x3FFF;	// DBTYPE_BYREF を除去	
  if( 
       dbtype == DBTYPE_I4
    || dbtype == DBTYPE_UI4
    || dbtype == DBTYPE_R8
    || dbtype == DBTYPE_STR
    || dbtype == DBTYPE_WSTR
    || dbtype == DBTYPE_DECIMAL
    || dbtype == DBTYPE_VARNUMERIC
    || dbtype == DBTYPE_NUMERIC
  ) {
    // よくあるフィールド型
  } else {
    // 対応可能か検討が必要なフィールド型
    std::cerr << "Un supported dbtype: " << dbtype << std::endl;
  }

  int nMax = 10;
  while(nMax) {
    std::string strData;
    for( DBORDINAL col = 1; col <= ulColumns; col++ ) {
      DBSTATUS dStatus;
      DBLENGTH nLength;
      rs.GetStatus( col, &dStatus );
      rs.GetLength( col, &nLength );
      if( col > 1 ) {
        std::cout << ", ";
      }
      if( FAILED( dStatus ) ) {
        std::cout << "<<ERROR>>";
      } else if( dStatus == DBSTATUS_S_ISNULL ) {
        std::cout << "<<NULL>>";
      } else {
        std::cout << rs.GetString(col);
      }
    }
    std::cout << std::endl;
    hr = rs.MoveNext();
    if( FAILED(hr) || hr == DB_S_ENDOFROWSET )  break;
    --nMax;
  }

  rs.Close();
  ss.Close();
  ds.Close();
  CoUninitialize();

  return 0;
}

2023/07/13 追記: バグは修正されたのか、仕様が変わったのか、よくわからない状況になりました。

C#の Properties.Settings.Default が実際にどこに保存されるか忘備録

noreply@blogger.com (tiger) — Thu, 22 Sep 2022 00:50:00 +0000

C# の Properties.Settings.Default 言語機構として用意していただけるのは有難いのですが、ここに環境系の設定を書いておくとインストールされたマシンの環境によって設定を変えたいとか出てくるんですよ。
ところが、こいつ、一体どこのファイルの設定を見てるねん？？？（#^ω^）ﾋﾟｷﾋﾟｷ
ってキレそうになる仕様なわけです。

という事で、.Net の古いバージョンでは、下記コードで導き出される場所に初期値が書かれています。

   System.Reflection.Assembly asm =System.Reflection.Assembly.GetExecutingAssembly();
   textBox1.Text = asm.GetName().Version.ToString(); // バージョン番号を取り出す
   // config のデフォルト値が記述されたファイルの場所
   textBox2.Text =  ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath;

.Net の仕様が変わり、現在は

   // Foo.exe.config 場合によっては Foo.dll.config 
   // ここは作成したプロジェクトの実行物の名前に依存します。
   textBox2.Text =  Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "\\Foo.exe.config";

はてさて、ではコードで、これらの要素を変更した値はどこに書き込まれるのか？
いつも大変お世話になります。Stackoverflow さまによると
Where are the Properties.Settings.Default stored? によると

c:\users\USER\AppData\Local\COMPANY\APPLICATION.exe_Url_LOOKSLIKESOMEKINDOFHASH\VERSION\user.config

なんだそうで、How know LOOKSLIKESOMEKINDOFHASH? とは、ごもっともな質問。私も知りたい。
これも Stackoverflow にありました。
How to get hash value in user.config path?
(ﾉ｀□´)ﾉ⌒┻━┻

IISのResponse Header を無効化忘備録

noreply@blogger.com (tiger) — Wed, 24 Aug 2022 09:02:00 +0000

PowerShell で、IIS の Server ヘッダや、X-ASPNET-Version ヘッダを消去、TRACEメソッドの無効化がしたくて、いろいろ試してみたが、やれ、静的コンテンツではなく、Exe経由のコンテンツのヘッダが消えないとか、ひどい目にあったので忘備録。

IIS ReWrite モジュールが必要です。

管理者権限で、下記スクリプトを実行します。
スクリプトだけでは完結しないので、コメントも読んでください

#
# PowerShell は BOM付き UTF-8 のエンコーディングで保存する事
#  さもなくば、「文字列に終端記号" がありません」という
#  エラーに悩まされます。(BOMの仕様必要？)
#
#
# X-ASPNET-VERSION を無効にする送信書き換えルールを
#   指定された PSPath に追加する
#
function global:AddXASPNetVersionRule {
  param ( $PSPath )

  echo "$PSPath の X-ASPNET-VERSION ヘッダを無効にします"

  $chk = Get-WebConfigurationProperty `
    -Filter "//rewrite/outboundRules/rule[@name='REMOVE_X-ASPNET-VERSION']" `
    -PSPath $PSPath `
    -Name name 

  if( $chk -eq $null ) {
    Add-WebConfigurationProperty `
      -Filter "//rewrite/outboundRules" `
      -PSPath $PSPath `
      -Name "Collection" `
      -Value @{name="REMOVE_X-ASPNET-VERSION"}

    Set-WebConfiguration `
      -Filter "//rewrite/outboundRules/rule[@name='REMOVE_X-ASPNET-VERSION']/match" `
      -PSPath $PSPath `
      -Value @{serverVariable="RESPONSE_X-ASPNET-VERSION";pattern=".+"}

    Set-WebConfiguration `
      -Filter "//rewrite/outboundRules/rule[@name='REMOVE_X-ASPNET-VERSION']/action" `
      -PSPath $PSPath `
      -Value @{type="Rewrite"}
    echo "  ...処理完了..."
  } else {
    echo "  ...処理済み skip..."
  }
}

#
# SERVER-VERSION を無効にする送信書き換えルールを
#   指定された PSPath に追加する
#
function global:AddServerVersionRule {
  param ( $PSPath )

  echo "$PSPath の Server ヘッダを無効にします"

  $chk = Get-WebConfigurationProperty `
    -Filter "//rewrite/outboundRules/rule[@name='REMOVE_SERVER-VERSION']" `
    -PSPath $PSPath `
    -Name name

  if( $chk -eq $null ) {
    Add-WebConfigurationProperty `
      -Filter "//rewrite/outboundRules" `
      -PSPath $PSPath `
      -Name "Collection" `
      -Value @{name="REMOVE_SERVER-VERSION"}

    Set-WebConfiguration `
      -Filter "//rewrite/outboundRules/rule[@name='REMOVE_SERVER-VERSION']/match" `
      -PSPath $PSPath `
      -Value @{serverVariable="RESPONSE_SERVER";pattern=".+"}
    
    Set-WebConfiguration `
      -Filter "//rewrite/outboundRules/rule[@name='REMOVE_SERVER-VERSION']/action" `
      -PSPath $PSPath `
      -Value @{type="Rewrite"}
    echo "  ...処理完了..."
  } else {
    echo "  ...処理済み skip..."
  }
}

#
# サーバ変数 RESPONSE_X-ASPNET-VERSION を追加する
#     X-ASPNET-VERSION: ヘッダとして利用される変数
#
$asv = Get-WebConfigurationProperty `
       -filter "//rewrite/allowedServerVariables/add[@name='RESPONSE_X-ASPNET-VERSION']"`
       -name name

if ($asv -eq $null)
{
  echo "サーバ変数 RESPONSE_X-ASPNET-VERSION を追加します"
  Add-WebConfigurationProperty `
    -Filter "//rewrite/allowedServerVariables" `
    -PSPath "IIS:\" `
    -Name "Collection" `
    -Value @{name="RESPONSE_X-ASPNET-VERSION"}

}

#
# サーバ変数 RESPONSE_SERVER を追加する
#      SERVER: ヘッダとして利用される変数
#
$asv2 = Get-WebConfigurationProperty `
       -filter "//rewrite/allowedServerVariables/add[@name='RESPONSE_SERVER']"`
       -name name

if ($asv2 -eq $null)
{
  echo "サーバ変数 RESPONSE_SERVER を追加します"

  Add-WebConfigurationProperty `
    -Filter "//rewrite/allowedServerVariables" `
    -PSPath "IIS:\" `
    -Name "Collection" `
    -Value @{name="RESPONSE_SERVER"}
}

#
# X-ASPNET-VERSION ヘッダを無効にする
#

  AddXASPNetVersionRule( "IIS:\" )

  AddXASPNetVersionRule( "IIS:\sites\Default Web Site" )

  # IIS-Admin上で手動追加するとエラーにならないが、コードで
  # 実行するとエラーになる不思議仕様
  #AddXASPNetVersionRule( "IIS:\sites\Default Web Site\foo" )

  # Application で無効化するために必要？
  # 仕様が不明すぎて草
  AddXASPNetVersionRule( "MACHINE/WEBROOT/APPHOST" )

#
# SERVER-VERSION ヘッダを無効にする
#
  AddServerVersionRule( "IIS:\" )

  AddServerVersionRule( "IIS:\sites\Default Web Site" )

  # IIS-Admin上で手動追加するとエラーにならないが、コードで
  # 実行するとエラーになる不思議仕様
  #AddServerVersionRule( "IIS:\sites\Default Web Site\foo" )

  # Application で無効化するために必要？
  # 仕様が不明すぎて草
  AddServerVersionRule( "MACHINE/WEBROOT/APPHOST" )


#
# IISの Server Header を無効化します。
#   静的コンテンツだけに効果があるため気休め
#
  echo "  IIS のサーバヘッダを無効化します  "
  echo "   ※ Application に対しては効果がありません"
  Set-WebConfigurationProperty `
    -pspath 'MACHINE/WEBROOT/APPHOST' `
    -filter "system.webServer/security/requestFiltering" `
    -name "removeServerHeader" `
    -value "True"


#
# IISの TRACE を無効化します。
#   静的コンテンツだけに効果があるため気休め
#
  echo "  IIS のTRACE メソッドを無効化します  "
  echo "   ※ Application に対しては効果がありません"
  echo "   コマンドで対応できる範囲は静的コンテンツのみです"
  echo "   要求フィルター>HTTP動詞>Trace;false をIIS設定から手動で行う必要があります"
#
#  要求フィルター HTTP動詞 TRACE をfalseにする
#
# エラーで動作しなくなるので、コマンドによる、このやり方はダメ
#  Add-WebConfigurationProperty `
#    -pspath "IIS:\" `
#    -filter "/system.webServer/security/requestFiltering/verbs" `
#    -name '.' -value @{verb='TRACE';allowed='False'}
#
  $colls = Get-IISConfigSection -CommitPath 'Default Web Site' -SectionPath 'system.webServer/security/requestFiltering' 
    #echo "colls : $colls"
  $verbs = Get-IISConfigCollection -ConfigElement $colls -CollectionName 'verbs'
    #echo "verbs : $verbs"
  try {
    New-IISConfigCollectionElement -ConfigCollection $verbs -ConfigAttribute @{ 'verb'='TRACE';'allowed'=$false }
    Stop-IISCommitDelay
  } catch {
    # 取得して、値を設定するコードが動作しない。（関数の仕様がわからない）
    #  echo " set trace "
    #  $trace = Get-IISConfigCollectionElement -ConfigCollection $verbs -ConfigAttribute @{ 'verb'='TRACE' }
    #  echo "trace : $trace.allowed $trace.verb"
    #  Set-IISConfigAttributeValue -ConfigElement $trace -AttributeName 'allowed' -AttributeValue $false
  }

#
# Web設定を無効にしてもアプリケーションからのヘッダが無効になるとは言ってない
# 気休め（無い方がまし）
#
#$rule3 = Get-WebConfigurationProperty `
#          -filter "/system.webServer/httpProtocol/customHeaders/add[@name='X-Powerd-By']" `
#          -Name name
#
#if ($rule2 -eq $null)
#{
#  echo "clear X-Powered-By"
#  Clear-WebConfiguration "/system.webServer/httpProtocol/customHeaders/add[@name='X-Powered-By']"
#}

apache maven で Jni DLL を梱包・備忘録

noreply@blogger.com (tiger) — Fri, 29 Jul 2022 06:48:00 +0000

肝は、resources セクションの resource に対して、filtering=false を指定する事。
この filtering を true にすると、対象リソースをテキストファイルと見なして、文字列の置換が実行されてしまう。
dll ファイルは、バイナリで、utf-8の文字コード規則に収まらないから、false にしないとエラーになってしまう。

後は、Bundle-NativeCode に dll ファイルを resource セクションで指定したディレクトリからの相対パスで ; により列挙すればOK

  <build>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
      </resource>
      <resource>
        <directory>src/main/extlib</directory>
        <filtering>false</filtering>
      </resource>
    </resources>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>${maven.compiler.plugin.version}</version>
        <configuration>
          <source>8</source>
          <target>8</target>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <version>${maven.bundle.plugin.version}</version>
        <extensions>true</extensions>
        <configuration>
          <instructions>
            <Build-Number>${buildId}</Build-Number>
            <Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
            <Bundle-ContactAddress>${sdk.contact.address}</Bundle-ContactAddress>
            <Bundle-Version>${project.version}</Bundle-Version>
            <Bundle-NativeCode>native/myJni.dll;native/libssl-1_1-x64.dll;native/zlib1.dll</Bundle-NativeCode>
            <Export-Package/>
            <Private-Package>jp.co.foo.bar</Private-Package>
          </instructions>
        </configuration>
      </plugin>
    </plugins>
  </build>

java のコードで、loadLibraryを記述する


  private static boolean tryLoadLibrary(String libname) {
    try {
      System.loadLibrary(libname);
      return true;
    } catch(Exception err) {
      err.printStackTrace();
    }
    return false;
  }

  // Bundle-NativeCode の dll を読み込む。Platformにより拡張子が異なるため
  // Java のコードでは、.dll .so といった名称まで指定しなくても良い。
  public static void tryLoadLibraries() {
    tryLoadLibrary("native/libssl-1_1-x64");
    tryLoadLibrary("native/zlib1");
    tryLoadLibrary("native/myJni");
  }
  
  // Load JNI
  static {
    // 自動でライブラリがロードされるはずなのだが、
    // この初期化が行われるより先に、JNI の関数が呼ばれる事態が
    // 発生する事がある。よって、クリティカルな場所から重複して
    // tryLoadLibraries をコールしても大丈夫なように実装している。
    tryLoadLibraries();
  }

WIX で VCRuntime のインストール忘備録

noreply@blogger.com (tiger) — Wed, 18 May 2022 05:18:00 +0000

そろそろ VCのRUNTIMEをVisual Studio 2019に移行しとかないと、コンパイルできないライブラリが増えてきたかな？と思いまして、2015 から 2019 に引き上げました。
WIXを使ったインストーラで、2019用のVC runtime のマージモジュールを探したが見つかりません。
ほぇ？と思って検索したらマージモジュールを使用したコンポーネントの再配布に書いてありました。

Visual Studio 2019 以降、Visual C++ 再頒布可能ファイルのマージモジュールは非推奨です
Visual Studio 2019 以降、Visual C++ 再頒布可能ファイルのマージモジュールは非推奨です
Visual Studio 2019 以降、Visual C++ 再頒布可能ファイルのマージモジュールは非推奨です
ふぁ？？？
という事で、VC Runtime がインストールされているかどうかチェックが必要になりました
Wix per user installer to detect the Visual C++ 2015 Redistributableにチェック方法がありました。StackOverflowさまさまです
How to check if the Microsoft Visual C++ Runtime is installedにも詳細が記述されてましたが、こちらだとサービスパックが追加される毎に対応が必要そうで、ちょっと重たい。

という事で、

<Product ...>
  ...

vc runtime 2015 x86 のインストール状況プロパティ

  <!-- C++ 2015 -->
  <Property Id="CPPRUNTIME2015X86" Secure="yes">
    <RegistrySearch Id="mfc140x86_23026" Root="HKLM" Key="SOFTWARE\Classes\Installer\Dependencies\{74d0e5db-b326-4dae-a6b2-445b9de1836e}" Type="raw" />
    <RegistrySearch Id="mfc140x86_24215" Root="HKLM" Key="SOFTWARE\Classes\Installer\Dependencies\{e2803110-78b3-4664-a479-3611a381656a}" Type="raw" />
  </Property>

vc runtime 2017 x86 のインストール状況プロパティ

  <!-- C++ 2017 -->
  <Property Id="CPPRUNTIME2017X86" Secure="yes">
    <RegistrySearch Id="mfc1416x86" Root="HKCR" Key="Installer\Dependencies\VC,redist.x86,x86,14.16,bundle" Type="raw" />
  </Property>

vc runtime 2019 x86 のインストール状況プロパティ

  <!-- C++ 2019 -->
  <Property Id="CPPRUNTIME2019X86" Secure="yes">
    <?foreach CPPRUNTIMEVERSIONPREFIX in 21;22;23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38;39;40?>
      <RegistrySearch Id="mfc14$(var.CPPRUNTIMEVERSIONPREFIX)x86" Root="HKCR" Key="Installer\Dependencies\VC,redist.x86,x86,14.$(var.CPPRUNTIMEVERSIONPREFIX),bundle" Type="raw" />
    <?endforeach ?>
  </Property>

vc runtime 2019 x86 がインストールされていないと、インストールを中止する条件の追加

  <!-- インストール時にC++ 2019 Runtime(x86) がインストールされているかチェック -->
  <Condition Message="Microsoft Visual C++ 2019 (x86) Redistributable missing">
    <![CDATA[Installed Or CPPRUNTIME2019X86]]>
  </Condition>

vc runtime 2015 x64 のインストール状況プロパティ

  <!-- C++ 2015 -->
  <Property Id="CPPRUNTIME2015X64" Secure="yes">
    <RegistrySearch Id="mfc140x64_23026" Root="HKLM" Key="SOFTWARE\Classes\Installer\Dependencies\{e46eca4f-393b-40df-9f49-076faf788d83}" Type="raw" />
    <RegistrySearch Id="mfc140x64_24215" Root="HKLM" Key="SOFTWARE\Classes\Installer\Dependencies\{d992c12e-cab2-426f-bde3-fb8c53950b0d}" Type="raw" />
  </Property>

vc runtime 2017 x64 のインストール状況プロパティ

  <!-- C++ 2017 -->
  <Property Id="CPPRUNTIME2017X64" Secure="yes">
    <RegistrySearch Id="mfc1416x64" Root="HKCR" Key="Installer\Dependencies\VC,redist.x64,amd64,14.16,bundle" Type="raw" />
  </Property>

vc runtime 2019 x64 のインストール状況プロパティ

  <!-- C++ 2019 -->
  <Property Id="CPPRUNTIME2019X64" Secure="yes">
    <?foreach CPPRUNTIMEVERSIONPREFIX in 21;22;23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38;39;40?>
      <RegistrySearch Id="mfc14$(var.CPPRUNTIMEVERSIONPREFIX)x64" Root="HKCR" Key="Installer\Dependencies\VC,redist.x64,amd64,14.$(var.CPPRUNTIMEVERSIONPREFIX),bundle" Type="raw" />
    <?endforeach ?>
  </Property>

vc runtime 2019 x64 がインストールされていないと、インストールを中止する条件の追加

  <!-- インストール時にC++ 2019 Runtime(x64) がインストールされているかチェック -->
  <Condition Message="Microsoft Visual C++ 2019 (x64) Redistributable missing">
    <![CDATA[Installed Or CPPRUNTIME2019X64]]>
  </Condition>

vc runtime 2010 x64 のマージモジュールを追加

  <Directory Id="System64Folder">
   <!-- VC100 ATL Runtime -->
   <Merge Id="Microsoft_VC100_ATL_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_ATL_x64.msm" />
   <Merge Id="Microsoft_VC100_CRT_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_CRT_x64.msm" />
   <Merge Id="Microsoft_VC100_MFCLOC_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_MFCLOC_x64.msm" />
   <Merge Id="Microsoft_VC100_MFC_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_MFC_x64.msm" />
   <Merge Id="Microsoft_VC100_OpenMP_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_OpenMP_x64.msm" />
  </Directory>

vc runtime 2010 x86 のマージモジュールを追加

  <Directory Id="SystemFolder">
      <!-- VC100 ATL Runtime -->
      <Merge Id="Microsoft_VC100_ATL_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_ATL_x86.msm" />
      <Merge Id="Microsoft_VC100_CRT_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_CRT_x86.msm" />
      <Merge Id="Microsoft_VC100_MFCLOC_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_MFCLOC_x86.msm" />
      <Merge Id="Microsoft_VC100_MFC_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_MFC_x86.msm" />
      <Merge Id="Microsoft_VC100_OpenMP_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_OpenMP_x86.msm" />
  </Directory>

vc runtime 2010 x64 と x86 のマージモジュールを参照

  <Feature ...>
      <!-- VC10 runtime -->
      <MergeRef Id="Microsoft_VC100_ATL_x64.msm" />
      <MergeRef Id="Microsoft_VC100_CRT_x64.msm" />
      <MergeRef Id="Microsoft_VC100_MFCLOC_x64.msm" />
      <MergeRef Id="Microsoft_VC100_MFC_x64.msm" />
      <MergeRef Id="Microsoft_VC100_OpenMP_x64.msm" />
      <!-- VC10 runtime -->
      <MergeRef Id="Microsoft_VC100_ATL_x86.msm" />
      <MergeRef Id="Microsoft_VC100_CRT_x86.msm" />
      <MergeRef Id="Microsoft_VC100_MFCLOC_x86.msm" />
      <MergeRef Id="Microsoft_VC100_MFC_x86.msm" />
      <MergeRef Id="Microsoft_VC100_OpenMP_x86.msm" />
  </Feature>

  ...
</Product>

というように対応できそうです。

2025/05/20 追記： CPPRUNTIMEVERSIONPREFIX が想定した番号を超えていた。Microsoft Visual C++ 2019 (x64) Redistributable missing というメッセージが出てインストーラが動作しない。という事で、インストーラを下記のように番号を増やしたのだが、この番号、どこまで互換性があるのか…というより、チェックするのも面倒くさくなってきた。readme.md かなんかに、vc runtime が必須ですと書いて、チェックいらないんじゃね？と思った。

  <!-- C++ 2019 -->
  <Property Id="CPPRUNTIME2019X86" Secure="yes">
    <?foreach CPPRUNTIMEVERSIONPREFIX in 21;22;23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38;39;40;41;42;43;44;45;46;47;48;49;50?>
      <RegistrySearch Id="mfc14$(var.CPPRUNTIMEVERSIONPREFIX)x86" Root="HKCR" Key="Installer\Dependencies\VC,redist.x86,x86,14.$(var.CPPRUNTIMEVERSIONPREFIX),bundle" Type="raw" />
    <?endforeach ?>
  </Property>

2025/12/08 追記：
Visual Studio 2026 が出て、プラットフォームツールセット: v145 になりました。
こいつ、下位互換性は有りますが、上位互換性は有りません。下位バージョンのruntimeだと、static メンバーの初期化がうまく動作しません。
よって、バージョンを切り分ける必要がありそうです。

  <!-- C++ 2026 -->
  <Property Id="CPPRUNTIME2026X86" Secure="yes">
    <?foreach CPPRUNTIMEVERSIONPREFIX in 50;51;52;53;54;55;56;57;58;59;60?>
      <RegistrySearch Id="mfc14$(var.CPPRUNTIMEVERSIONPREFIX)x86" Root="HKCR" Key="Installer\Dependencies\VC,redist.x86,x86,14.$(var.CPPRUNTIMEVERSIONPREFIX),bundle" Type="raw" />
    <?endforeach ?>
  </Property>

Windows DLL x86とx64で異なる関数名調整の備忘録

noreply@blogger.com (tiger) — Fri, 13 May 2022 00:26:00 +0000

AESのDLLをビルドしていて、x64でビルドしたものは素直に利用できるのにx86でビルドしたものを利用しようとするとLNK2019: _aes_encrypt_key が見つからないというリンクエラーになってしまった。
test_lib.exe のソースを見ると

#ifdef  AES_MODES

    fn->fn_test_align = (g_talign*)GetProcAddress(h_dll, etad_name);
    fn->fn_mode_reset = (g_reset*)GetProcAddress(h_dll, eres_name);
    fn->fn_ecb_enc = (g_enc1*)GetProcAddress(h_dll, ecbe_name);
    fn->fn_ecb_dec = (g_dec1*)GetProcAddress(h_dll, ecbd_name);
    fn->fn_cbc_enc = (g_enc2*)GetProcAddress(h_dll, cbce_name);
    fn->fn_cbc_dec = (g_dec2*)GetProcAddress(h_dll, cbcd_name);
    fn->fn_cfb_enc = (g_enc3*)GetProcAddress(h_dll, cfbe_name);
    fn->fn_cfb_dec = (g_enc3*)GetProcAddress(h_dll, cfbd_name);
    fn->fn_ofb_cry = (g_enc3*)GetProcAddress(h_dll, ofb_name);
    fn->fn_ctr_cry = (g_enc4*)GetProcAddress(h_dll, ctr_name);

    if(   !fn->fn_mode_reset || !fn->fn_test_align
       || !fn->fn_ecb_enc || !fn->fn_ecb_dec
       || !fn->fn_cbc_enc || !fn->fn_cbc_dec
       || !fn->fn_cfb_enc || !fn->fn_cfb_dec
       || !fn->fn_ofb_cry || !fn->fn_ctr_cry )
       ok = 0;
#endif

と、DLLを LoadLibrary した後で、GetProcAddress により関数のアドレスを取得し、呼び出すという事をしていた。
で、名前の定義は aestst.h に記述されており、x86 と x64 で切り替えている。

#if defined( _WIN64 )

#define gt_name             "aes_init"
#define ek_name128          "aes_encrypt_key128"
#define ek_name192          "aes_encrypt_key192"
#define ek_name256          "aes_encrypt_key256"
#define ek_name             "aes_encrypt_key"
#define eb_name             "aes_encrypt"
#define dk_name128          "aes_decrypt_key128"
#define dk_name192          "aes_decrypt_key192"
#define dk_name256          "aes_decrypt_key256"
#define dk_name             "aes_decrypt_key"
#define db_name             "aes_decrypt"

#define etad_name           "aes_test_alignment_detection"
#define eres_name           "aes_mode_reset"
#define ecbe_name           "aes_ecb_encrypt"
#define ecbd_name           "aes_ecb_decrypt"
#define cbce_name           "aes_cbc_encrypt"
#define cbcd_name           "aes_cbc_decrypt"
#define cfbe_name           "aes_cfb_encrypt"
#define cfbd_name           "aes_cfb_decrypt"
#define ofb_name            "aes_ofb_crypt"
#define ctr_name            "aes_ctr_crypt"

#else

#define gt_name             "_aes_init@0"
#define ek_name128          "_aes_encrypt_key128@8"
#define ek_name192          "_aes_encrypt_key192@8"
#define ek_name256          "_aes_encrypt_key256@8"
#define ek_name             "_aes_encrypt_key@12"
#define eb_name             "_aes_encrypt@12"
#define dk_name128          "_aes_decrypt_key128@8"
#define dk_name192          "_aes_decrypt_key192@8"
#define dk_name256          "_aes_decrypt_key256@8"
#define dk_name             "_aes_decrypt_key@12"
#define db_name             "_aes_decrypt@12"

#define etad_name           "_aes_test_alignment_detection@4"
#define eres_name           "_aes_mode_reset@4"
#define ecbe_name           "_aes_ecb_encrypt@16"
#define ecbd_name           "_aes_ecb_decrypt@16"
#define cbce_name           "_aes_cbc_encrypt@20"
#define cbcd_name           "_aes_cbc_decrypt@20"
#define cfbe_name           "_aes_cfb_encrypt@20"
#define cfbd_name           "_aes_cfb_decrypt@20"
#define ofb_name            "_aes_ofb_crypt@20"
#define ctr_name            "_aes_ctr_crypt@24"

#endif

なるほど、だから x64 ではリンクエラーにならず、x86ではリンクエラーになったのだ。
x86 と x64 でマングリングの名前が違う事に自分も苛ついてはいました。
def ファイルに alias 指定できないの？？？と思って調べたら、ありました。
EXPORTS
alias=function_name
としてやれば良かったようです。
という事で、リンクエラーになった x86 用のビルドだけ以下のdefファイルを適用するようにしました。

LIBRARY		Aes

EXPORTS
   _aes_init=_aes_init@0
   _aes_encrypt_key128=_aes_encrypt_key128@8
   _aes_encrypt_key192=_aes_encrypt_key192@8
   _aes_encrypt_key256=_aes_encrypt_key256@8
   _aes_encrypt_key=_aes_encrypt_key@12
   _aes_encrypt=_aes_encrypt@12
   _aes_decrypt_key128=_aes_decrypt_key128@8
   _aes_decrypt_key192=_aes_decrypt_key192@8
   _aes_decrypt_key256=_aes_decrypt_key256@8
   _aes_decrypt_key=_aes_decrypt_key@12
   _aes_decrypt=_aes_decrypt@12

   _aes_test_alignment_detection=_aes_test_alignment_detection@4
   _aes_mode_reset=_aes_mode_reset@4
   _aes_ecb_encrypt=_aes_ecb_encrypt@16
   _aes_ecb_decrypt=_aes_ecb_decrypt@16
   _aes_cbc_encrypt=_aes_cbc_encrypt@20
   _aes_cbc_decrypt=_aes_cbc_decrypt@20
   _aes_cfb_encrypt=_aes_cfb_encrypt@20
   _aes_cfb_decrypt=_aes_cfb_decrypt@20
   _aes_ofb_crypt=_aes_ofb_crypt@20
   _aes_ctr_crypt=_aes_ctr_crypt@24

こうする事で、見事にLNK2019を回避する事ができました。
今まで、やり方がわからなくて、Delphi 用 DLL には序数で指定したりと、大変だったんですよね。

2022/06/29 追記:
bigtypes.h に

#ifndef RETURN_VALUES
#  define RETURN_VALUES
#  if defined( DLL_EXPORT )
#    if defined( _MSC_VER ) || defined ( __INTEL_COMPILER )
#      define VOID_RETURN    __declspec( dllexport ) void __stdcall
#      define INT_RETURN     __declspec( dllexport ) int  __stdcall
#    elif defined( __GNUC__ )
#      define VOID_RETURN    __declspec( __dllexport__ ) void
#      define INT_RETURN     __declspec( __dllexport__ ) int
#    else
#      error Use of the DLL is only available on the Microsoft, Intel and GCC compilers
#    endif
#  elif defined( DLL_IMPORT )
#    if defined( _MSC_VER ) || defined ( __INTEL_COMPILER )
#      define VOID_RETURN    __declspec( dllimport ) void __stdcall
#      define INT_RETURN     __declspec( dllimport ) int  __stdcall
#    elif defined( __GNUC__ )
#      define VOID_RETURN    __declspec( __dllimport__ ) void
#      define INT_RETURN     __declspec( __dllimport__ ) int
#    else
#      error Use of the DLL is only available on the Microsoft, Intel and GCC compilers
#    endif
#  elif defined( __WATCOMC__ )
#    define VOID_RETURN  void __cdecl
#    define INT_RETURN   int  __cdecl
#  else
#    define VOID_RETURN  void
#    define INT_RETURN   int
#  endif
#endif

と定義されていて、x64は呼び出し規約が異なるので問題なく動作するが、x86で利用する場合は利用する側で
DLL_IMPORT をプリプロセッサの定義に追加しないと、コールスタックが破壊されて、よくわからないエラーになる
尚、aes.dll を使った dll を書きたい場合は、DLL_EXPORT や DLL_IMPORT といった汎用的な定義で判別していると、定義がバッティングするので、AES_DLL_EXPORT と言った定義に変更した方が良いと思う。できれば、DLL_IMPORT は定義しなくても AES_DLL_EXPORT が定義されていなかったら、利用する側のコードだと判別できるので、このマクロの書き方は改良した方が良いかな？

もうひとつ、vsyasm の -f オプションが Win32 ではなく win32 しか認識しないので、
vsyasm.props ファイルを修正する

...
      <CommandLineTemplate Condition="'$(Platform)'=='Win32'">"$(YASM_PATH)"vsyasm.exe -Xvc -f win32 [AllOptions] [AdditionalOptions] [Inputs]</CommandLineTemplate>
      <CommandLineTemplate Condition="'$(Platform)'!='Win32'">"$(YASM_PATH)"vsyasm.exe -Xvc -f $(Platform) [AllOptions] [AdditionalOptions] [Inputs]</CommandLineTemplate>
...

oracle x64 と x86 なクライアント環境を切替え(windows)忘備録

noreply@blogger.com (tiger) — Mon, 25 Apr 2022 03:29:00 +0000

Oracle が面倒くさいのである。

請負の開発をしていると、このプロジェクトは32bitアプリで、このプロジェクトは64bitアプリで、という事は、普通にあります。
で、Oracle は２つ同時に両立しないので、両立させる環境の構築についての忘備録

x64版のOracle Clientをインストール
環境変数 ORACLE_HOME を ORACLE_HOME_X64 に変更
インストール先の名前を _x64 付きに変更
x86版のOracle Clientをx64と同じフォルダ名(_x64なし)にインストール
インストール先の名前を _x86 付きに変更
インストール先の名前に _x86 のリンクディレクトリを作成する
切替用のバッチファイルを作成

x64 用バッチのサンプル

cd %ORACLE_HOME%
cd ..
rmdir client_1
mklink /D client_1 client_1_x64

x86 用のバッチのサンプル

cd %ORACLE_HOME%
cd ..
rmdir client_1
mklink /D client_1 client_1_x86

これで、x64 と x86 を切替えできる。切り替えた後は、Windows を再起動

尚、リンクディレクトリの作成は、mklink /D により行う

datetime の曖昧なフォーマットに対応する忘備録

noreply@blogger.com (tiger) — Thu, 31 Mar 2022 05:59:00 +0000

日付のフォーマットと制約が厳しい。
わりとありそうな日付の表記ゆれをパースするグラマーを構築してみた。

#include <boost/spirit/include/qi.hpp>  // boost::spirit::qi を利用します
#include <boost/fusion/adapted/struct/adapt_struct.hpp>
#include <iostream>
#include <string>


#include <boost/date_time.hpp>

namespace pt = boost::posix_time;
namespace qi = boost::spirit::qi;


struct timeinfo {
  int16_t   year_;
  uint16_t  month_;
  uint16_t  day_;
  uint16_t  hour_;
  uint16_t  minute_;
  uint16_t  second_;
  //uint32_t  millisec_;
  std::string millisec_;
};

BOOST_FUSION_ADAPT_STRUCT(
  timeinfo,
  (int16_t,     year_)
  (uint16_t,    month_)
  (uint16_t,    day_)
  (uint16_t,    hour_)
  (uint16_t,    minute_)
  (uint16_t,    second_)
  //(uint32_t,    millisec_)
  (std::string,  millisec_)
)

template <typename Iterator, typename Skipper>
struct time_grammar : qi::grammar<Iterator, timeinfo(), Skipper> {
  qi::rule<Iterator, timeinfo(), Skipper>  start_;
  qi::int_parser<int16_t,10,4,4> int4_;
  qi::uint_parser<uint16_t,10,2,2> uint2_;
  qi::rule<Iterator, std::string(), Skipper> numeric_;

  time_grammar() : time_grammar::base_type(start_, "time_grammar") {
    numeric_ = *qi::char_('0','9');
    start_ = (
        int4_ 
        >> -(qi::lit('/') | qi::lit('-')) >> uint2_
        >> -(qi::lit('/') | qi::lit('-')) >> uint2_
        //>> (qi::lexeme[qi::lit(' ')] | qi::lit('T'))
        >> -(qi::lit('T'))
        >> uint2_
        >> -(qi::lit(':')) >> uint2_
        >> -(qi::lit(':')) >> uint2_
        >> (
          //-( (qi::lit('.') | qi::lit(',')) >> qi::uint_)
          -( (qi::lit('.') | qi::lit(',')) >> numeric_)
          | qi::attr(0)
        )
        >> -(qi::lit('Z'))
    );
  }
};



int main() {
  
  std::string input[] = {
    "20210412T123455Z",
    "20210412T123455,987654321Z",
    "20210412T123455.987654321Z",
    "2004-03-21 12:45:33",
    "2004/03/21 12:45:33",
    "23.09.2004 04:12:21",
    "2003-02-11"
  };

  time_grammar<std::string::iterator, qi::standard::space_type> myg;
  for( int i = 0; i < sizeof(input)/sizeof(input[0]); i++ ) {
    timeinfo ti;
    qi::phrase_parse( input[i].begin(), input[i].end(), myg, qi::standard::space, ti );
    std::cout << "--------------" << std::endl;
    std::cout << ti.year_ << std::endl;
    std::cout << ti.month_ << std::endl;
    std::cout << ti.day_ << std::endl;
    std::cout << ti.hour_ << std::endl;
    std::cout << ti.minute_ << std::endl;
    std::cout << ti.second_ << std::endl;
    std::cout << ti.millisec_ << std::endl;
  }
  return 0;
}

2023/06/02 追記： lexeme がうまく動作しないのでスペースを無視した。millisec が ,020Z と指定された場合 2 に変換されてしまうので std::string で扱うようにした。バグでした。

boost::log windows で /dev/null 忘備録

noreply@blogger.com (tiger) — Mon, 28 Mar 2022 02:24:00 +0000

boost::log でデバッグ用ログの埋め込みを行っていて、リリース時には取り除きたい場合の措置。
これだと、nul デバイスに対して出力する処理が入るので、負荷を取り除くという面では、よろしくないコード

ポイントは、
Windows では nul というファイルが /dev/null に相当する
nul というファイルは、どこにでも存在している扱いになるので、追加書き込みモードで開く必要がある点


#include <boost/date_time.hpp>

#include <boost/log/trivial.hpp>
#include <boost/log/utility/setup/file.hpp>
#include <boost/log/attributes.hpp>
#include <boost/log/expressions.hpp>
#include <boost/log/support/date_time.hpp>

namespace logging = boost::log;
namespace attrs = boost::log::attributes;
namespace keywords = boost::log::keywords;
namespace sinks = boost::log::sinks;
namespace expr  = boost::log::expressions;

...

//#define DEBUG_LOG_FILE  "c:/logs/%Y_%m_%d.log"

...

  boost::log::add_file_log(
#ifdef DEBUG_LOG_FILE
    keywords::file_name = DEBUG_LOG_FILE,
#else
    keywords::file_name = "nul",
    keywords::open_mode = std::ios_base::out | std::ios_base::app,
#endif
    keywords::time_based_rotation = sinks::file::rotation_at_time_point(0, 0, 0),
    keywords::format = 
    (
        expr::stream
            << expr::format_date_time< boost::posix_time::ptime >("TimeStamp", "%Y-%m-%d %H:%M:%S")
            << ": <" << logging::trivial::severity
            << "> " << expr::smessage
    ),
    keywords::auto_flush = true
  );
  BOOST_LOG_TRIVIAL(debug) << "this is a debug output.";

...

Vcpkg autolink を無効にする忘備録

noreply@blogger.com (tiger) — Mon, 24 Jan 2022 06:23:00 +0000

vcpkg で、AutoLinkが有効になっている、明後日の方向のライブラリにリンクしてしまい、不可解なエラーに悩まされます。

なので、AutoLink を無効にしたい。

*.vcxprj を開きます。
PropertyGroup を検索し、以下の設定を追加します。

  <PropertyGroup Label="Vcpkg" Condition="'$(Configuration)|$(Platform)'=='UnicodeRelease|x64'">
    <VcpkgAutoLink>false</VcpkgAutoLink>
  </PropertyGroup>
  <PropertyGroup Label="Vcpkg" Condition="'$(Configuration)|$(Platform)'=='UnicodeRelease|Win32'">
    <VcpkgAutoLink>false</VcpkgAutoLink>
  </PropertyGroup>

UnicodeRelease|x64 等は、自分のビルド構成と合わせるようにしましょう。
以上。

vcpkg BuildTool を古いバージョンに変更備忘録

noreply@blogger.com (tiger) — Mon, 24 Jan 2022 01:25:00 +0000

書いておかないと、忘れて調べ直す事になるので・・・
vcpkg でビルドをすると最新バージョンのVisual Studio が使用されるようになって、それでは困る場合があるので、その設定の仕方。

vcpkg/triplets ディレクトリ下のファイルに

arm64-windows.cmake
arm-uwp.cmake
x64-linux.cmake
x64-osx.cmake
x64-uwp.cmake
x64-windows.cmake
x64-windows-static.cmake
x86-windows.cmake

とファイルが並んでいます。
その x64-windwos.cmake と x86-windows.cmake に対して

set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)
set(VCPKG_PLATFORM_TOOLSET "v140")
set(VCPKG_DEP_INFO_OVERRIDE_VARS "v140")

というように VCPKG_PLATFORM_TOOLSET, VCPKG_DEP_INFO_OVERRIDE_VARS を追加し、TOOLSET のバージョンを指定します。
以上。

なんか、一時的にブロガーのポストができなくなって、前のポストを一旦削除して、作り直しました。

C＋＋データを１６進表記相互変換

noreply@blogger.com (tiger) — Mon, 24 Jan 2022 01:18:00 +0000

ちょくちょくデータを暗号化して16進数表記文字列に変換して保存し、保存された16進表記文字列をデータに復元する事をやるので、忘備録として記録する事に。こういう、ちょっとしたものでも、書こうと思ったら時間を取られる。

#include <string>
#include <iostream>

static int atob( int c ) {
  static const unsigned char btbl[] = {
    // 0     1     2     3     4     5     6     7     8     9     A     B     C     D     E     F
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  0
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  1
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  2
    0x00, 0x01, 0x02, 0x03, 0x04, 0x05,  0x06, 0x07,  0x08, 0x09, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  3
    0x00, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E,  0x0F, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  4
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  5
    0x00, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E,  0x0F, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  6
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  7
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  8
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  9
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  A
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  B
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  C
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  D
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  //  E
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  0x00, 0x00,  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00   //  F
  };
  return btbl[ c ];
}


//! １６進文字列から unsigned char 配列への変換
/*
  @note １６進文字列は、0-9, A-F のみを利用した表記で
    １バイトを２文字で表記しているものとする。１６進を示す 0x 等の
    接頭辞は含まれていない。
*/
void hexstr2str(
  const std::string& src,
  std::string& dst
) {
  dst.resize( (src.size() + 1) / 2 );
  for(size_t i = 0; i < src.size(); i++) {
    if( (i & 1) != 0 ) {
      dst[ i / 2 ] |= atob( src[i] );
    } else {
      dst[ i / 2 ] = atob( src[i] ) << 4;
    }
  }
}

//! unsigned char 配列から １６進文字列への変換
/*!
  @note １６進文字列は、0-9, A-F のみを利用した表記で
    １バイトを２文字で表記したものに変換される。１６進を示す 0x 等の
    接頭辞は含まない。
*/
void str2hexstr(
  const std::string&  src,
  std::string&        dst
) {
  static const char atbl[] = {
    '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F',
  };
  dst.resize( src.size() * 2 );
  for( size_t i = 0; i < src.size(); i++ ) {
    dst[i*2  ] = atbl[ ((src[i] >> 4) & 0x0F) ]; // & 0x0F しないと算術シフトでアウトでした
    dst[i*2+1] = atbl[ (src[i] & 0x0F) ];
  }
}

int main() {
  std::string src = "Hello world!";
  std::string hex, dst;
  std::cout << src << std::endl;
  str2hexstr( src, hex );
  std::cout << hex << std::endl;
  hexstr2str( hex, dst );
  std::cout << dst << std::endl;
  return 0;
}

結果

Hello world!
48656C6C6F20776F726C6421
Hello world!

2022/01/14 追記: str2hexstr のコメントに書いたバグ修正をしました

grayhole

ArcGIS Enterprise 12.1 (windows) proxy bug 忘備録

git と diff

WinMergeのほうが賢く感じるのには、明確な技術的理由があります。

1. 内部の比較アルゴリズムが違う

2. WinMergeが「賢い」と感じる3つの理由

① 行内の部分一致（ハイライト）が強力

② 空白や改行コードの柔軟な無視

③ 移動した行（ブロック）の検知

ヒント：Git の比較画面を WinMerge に変更できます

WIX で VCRuntime のインストール忘備録２

Github copilot にお願いしたいこと

結論（短く）

もう少し正確に言うと

GitHub Copilot 側で一番近い選択肢

✅ 推奨モデル

「知識があるかどうか」の正体について（重要）

GitHub Copilot で再現度を上げるコツ

正直な一言

boost::geometry::extensions が boost_1_90_0 で工事中

ArcGIS Experence Builder Deploy bug 忘備録

EPSG忘備録

AIと戯れる

EDLA (Error Diffusion Learning Algorithm) 実装履歴

概要

時系列実験ログ

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

着想

実装ファイル

課題

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

着想

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

実装

結果

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

着想

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

MNIST結果

結論

Phase 4: Logic Gate Networks論文の調査

着想

論文の要点

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

考察

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

着想

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

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

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

着想（ユーザー）

実装（edla_identity.cpp）

結果（3層、XORテスト）

結論

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

着想（ユーザー）

実装（edla_deep.cpp）

結果（MNIST、10層）

浅い vs 深い比較

Phase 8: Identity配置の最適化

着想（ユーザー）

実験: Identity配置の比較

追加実験: 最終層を除外

重要な発見

基本アルゴリズム

ED法の特徴

更新式

実験1: Identity経路の導入

背景

Identity経路の実装

結果

結論

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

比較設定

結果

結論

実験3: 学習率と安定性

問題

解決策: 学習率減衰

結果

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

IISのResponse Header を無効化忘備録

datetime の曖昧なフォーマットに対応する忘備録