2025年2月12日水曜日
FreeBSD-14でVJE Deltaが動かなくて苦労した件
いまでもVJE DeltaをFreeBSDで使っている。
12.3-RELEASEで使えていたので簡単だろうと思い、14.2-RELEASEへ
移行しようとしたら苦労した。
結論としては、12.3-RELEASEの
/usr/lib32/libthr.so.3
を使えば良かった。
そのままだと14.2-RELEASEのものが使われるが、
sysconf(_SC_NPROCESSORS_CONF)
がエラーになりIMEのvjeが起動できない。
X11と関係ない部分(vjedなど)は使えるが。
gitになって,慣れていないためだろうが、
思うように履歴を追えずに苦労したのだが、
上記コードは14-RELEASEあたりから加えられたらしい。
エラーの原因はわからないのだが、VJEが使えなくなるのは悲しいので、不具合で修正されるのを望む。
libxcbがスレッドを使っているので、それ以前ならとも思ったが、
必要な物を4.11-RELEASEから取り込んでみたところ、
can't open display (null)
みたいなエラーになってしまいダメだった。
2023年2月6日月曜日
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わかりません。
2022年12月19日月曜日
FreeBSDでWake on LAN
ずいぶん前から、使いたいけどうまくできていなかったWake on LANができるよになった。
packageのwolではなく、/usr/sbin/wakeを使えばよかったようだ。
ifconfigのオプションは、wolだとだめで、wol_magicを使っている。wolだと、何もしなくても電源ONになってしまうようだ。
最近は多くのイーサカードでWOLが使える模様。 ifconfigの-mオプションで確認できる。capabilitiesにWOL_MAGIC等が出ていればサポートしているので、利用できるはず。
2019年8月9日金曜日
Windows10の余計なサービスを止める
Windows10を1903にアップデートしたら、ちょいちょいCPU100%に張り付くようになったので、以前にも設定した内容を再確認した。
- cortana無効(無効になっていた)
- sysmain(旧superfetch)停止・無効(1903アップデートで有効化された模様)
- windows search停止・無効(1903アップデートで有効化された模様)
- peer name関連停止・無効(IPv6用なので)(止まっていた)
- IPv6停止(今回新規)
- WinSATはタスクスケジューラで無効化(無効になっていた模様)
- MicrosoftStore更新オフ、ビデオの自動再生オフ(今回新規)
2019年2月10日日曜日
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して復活できそうだったのだが。残念。。。
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して復活できそうだったのだが。残念。。。
2018年10月9日火曜日
WindowsのBATファイルでワイルドカード展開されずに困った件
Windows10からFreeBSDへ、定期的にファイルを移動する必要があった。
開発者モードならsshサーバが動くので、FreeBSD側からBATファイルを叩けばと思ったら、どうも外からはつながらないのであきらめた(ファイアウォールは開いているのだが)。
ふとsshクライアントも提供されているのに気がついて、じゃぁWindows側でBATファイルを起動すれば、これまでよりは楽になる。と思ったら、BATファイルでワイルドカードが展開されなくて困った。
そういえば、MS-DOSの頃から、ワイルドカードは起動されたコマンド側で展開するのだったねぇ。
提供されているsshクライアントは、そういったWindows事情の反映などされていないようで、余計な変更してないのは好意的に受け取るけど、BATからだとすごく使いにくいことがわかった。
開発者モードならsshサーバが動くので、FreeBSD側からBATファイルを叩けばと思ったら、どうも外からはつながらないのであきらめた(ファイアウォールは開いているのだが)。
ふとsshクライアントも提供されているのに気がついて、じゃぁWindows側でBATファイルを起動すれば、これまでよりは楽になる。と思ったら、BATファイルでワイルドカードが展開されなくて困った。
そういえば、MS-DOSの頃から、ワイルドカードは起動されたコマンド側で展開するのだったねぇ。
提供されているsshクライアントは、そういったWindows事情の反映などされていないようで、余計な変更してないのは好意的に受け取るけど、BATからだとすごく使いにくいことがわかった。
2018年8月2日木曜日
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のバックテストで大きなマイナスを出している。
一般に実運用(≒フォワード)はバックテストより悪くなるのだが、
逆にバックテストの方が悪くなるケースに出会ったので書いておく。
結論を先に書いておくと、急激なレート変動に対して、
実運用ではスプレッドが開くため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のバックテストで大きなマイナスを出している。
登録:
投稿 (Atom)