emacs-28.1でXIMがroot styleになる件

FreeBSDでパッケージが更新されて、emacs-28.1になってから、XIMがroot styleになって困っていた。 思い立って調べてみたら、emacsのsrc/xfns.cのbest_xim_style()でroot styleに固定されているようだった。 return XIMPreeditNothing | XIMStatusNothing となっており、これだとroot style固定。とりあえず return XIMPreeditPosition | XIMStatusNothing に書き換えたらover the spotが使えるようになった。 return XIMPreeditPosition | XIMStatusArea の方が一般的なのか? X11わかりません。

FreeBSDでWake on LAN

ずいぶん前から、使いたいけどうまくできていなかったWake on LANができるよになった。 packageのwolではなく、/usr/sbin/wakeを使えばよかったようだ。 ifconfigのオプションは、wolだとだめで、wol_magicを使っている。wolだと、何もしなくても電源ONになってしまうようだ。 最近は多くのイーサカードでWOLが使える模様。 ifconfigの-mオプションで確認できる。capabilitiesにWOL_MAGIC等が出ていればサポートしているので、利用できるはず。

Windows10の余計なサービスを止める

Windows10を1903にアップデートしたら、ちょいちょいCPU100%に張り付くようになったので、以前にも設定した内容を再確認した。

• cortana無効(無効になっていた)
•  sysmain(旧superfetch)停止・無効(1903アップデートで有効化された模様)
•  windows search停止・無効(1903アップデートで有効化された模様)
• peer name関連停止・無効(IPv6用なので)(止まっていた)
• IPv6停止(今回新規)
• WinSATはタスクスケジューラで無効化(無効になっていた模様)
• MicrosoftStore更新オフ、ビデオの自動再生オフ(今回新規)

FreeBSD-11.2で消してしまったファイルを復元できなかった件

FreeBSD-11.2で、誤ってrmしてしまったファイルを復元できなかった。

rmしてしまって以降、該当ファイルシステムには変更を加えていないので、たぶん復元できるはずといろいろ試したが、どうも最近はファイルを削除するとiノードをクリアするようで、データブロックが行方不明になってしまい復元不可能のようだ。

最初はパッケージのffs2recovを試したのだが、レギュラーファイルの一覧を出す-aが想定どうりに機能せず断念。ディレクトリ一覧を表示する-dはそれらしく動いたのだが。

次にfsdb。該当ファイルシステムをread onlyでマウントして、ファイルがあったディレクトリのiノード番号を確認。ディレクトリを16進ダンプすると、消してしまったファイルのiノード番号が確認できた。

fsdbでブロックデバイスを開いて、消してしまったファイルのiノードを選択するとUnallocatedとなるが、chtype fileとするとiノード情報が見えるようになる。サイズが0になっているのでblocksしてもデータブロック番号が見えない。さらにchlen <適当なサイズ>(このコマンドはmanに記載が無い)すると見えるようになるが、ブロック番号は0が並んでいるという結末だった。

iノードがクリアされていなければ、fsdbからディレクトリにlnして復活できそうだったのだが。残念。。。

WindowsのBATファイルでワイルドカード展開されずに困った件

Windows10からFreeBSDへ、定期的にファイルを移動する必要があった。
開発者モードならsshサーバが動くので、FreeBSD側からBATファイルを叩けばと思ったら、どうも外からはつながらないのであきらめた(ファイアウォールは開いているのだが)。
ふとsshクライアントも提供されているのに気がついて、じゃぁWindows側でBATファイルを起動すれば、これまでよりは楽になる。と思ったら、BATファイルでワイルドカードが展開されなくて困った。
そういえば、MS-DOSの頃から、ワイルドカードは起動されたコマンド側で展開するのだったねぇ。
提供されているsshクライアントは、そういったWindows事情の反映などされていないようで、余計な変更してないのは好意的に受け取るけど、BATからだとすごく使いにくいことがわかった。

MT4のEAのファワードがバックテストより良くなるケース

MT4のEAでポートフォリオを検討している。
一般に実運用(≒フォワード)はバックテストより悪くなるのだが、
逆にバックテストの方が悪くなるケースに出会ったので書いておく。

結論を先に書いておくと、急激なレート変動に対して、
実運用ではスプレッドが開くためEAはエントリーしないが、
バックテストではそれが無いためエントリーしてロスカットになることがあるため、
バックテストの方が悪くなる場合があるということだと考える。
但し、フォワードはデモ口座のものなので、本当にスプレッドが広がっていたかには
疑問の余地が残る。

2016年7月29日、日本時間の朝7時頃と12時過ぎに、USDJPYが大きく動いた
(後者は日銀の追加金融緩和策発表によるもの)。
どちらも5分足1本で2.5-3円幅の値動きで、とあるEAのバックテストで、
この値動きに対して複数回のエントリーがあり、盛大なロスカットになっていた。

同EAは同日のフォワードテストも公開されており、そちらを見ると12時過ぎの
方で1回のみエントリーしてストップロスとなっただけで、バックテストで
240pips損失のところ、フォワードでは80pipsの損失のみとなっていた。

フォワード、つまりデモ口座で1回だけのエントリーとなった原因がスプレッドかどうか、
確認のしようがないのだが、バックテスト結果もたまには精査が必要なのだと
知らされたのであった。

2018/8/11追記:
2016/1/29の日本時間11時過ぎにも、日銀金融政策決定会合がらみで大きな値動きがあって、同EAのバックテストで大きなマイナスを出している。

5周133分。ゆっくり走ったが4周目後半から歩き混じりで遅くなった。