Hatena::ブログ(Diary)

DebugIto’s diary このページをアンテナに追加 RSSフィード

2016-06-05

慢性上咽頭炎の近況(4)


前回の近況からまた2ヶ月がたったので、これまであったことを記す。

Bスポットの終了


2016年4月5日にいつも通り耳鼻科でBスポット療法を受けた。この日でだいたいBスポットを始めてから半年が経過したことになる。症状はだいぶ改善してきているし、ここでいったん定期的なBスポット療法をやめ、様子を見ることになった。

耳鼻科の先生が言うには、「何ヶ月かしてまた戻ってくる人もいれば、こない人もいる。ともかく鼻呼吸を心がけよ」とのことだった。

それからここ2ヶ月の間は以下のような症状があった。

  • 後鼻漏。
  • 頭がぼうっとする感覚。目まいほどではないが、午前中に間食すると起こりやすかった。
  • 光がまぶしい感覚。特に午後3時から4時あたりで西日が強い時によく感じた。
  • 軽い吐き気。頻度は高くなかったが、液晶モニタでずっと文書を読んでいる時などに感じた。

こういった症状はコーヒーを飲んだり涼しい場所に移動することでやわらげることができた。

いずれにせよ、これらの症状は次第に弱くなってきており、今ではほとんど感じない程度になっている。

その他の措置


鼻うがいは朝夕に1日2回、引き続き行っている。特に寝ている間に鼻の奥に鼻水がたまることがあるので、朝に鼻うがいをすると気分がスッキリする。

さすがに鼻うがいには慣れてきたようで、水を押し込むタイプでも吸い込むタイプでもほぼ百発百中で鼻からノドに流せるようになってきた。不慣れなうちは、特に押し込むタイプではノドに抜けなかったことがあったが、ノドに抜ける感覚をイメージしながらゆっくり水を押し流すとうまくいくように思う。

腕と頭へのお灸は、最近は頻度を少し減らしてみている。結局効果があったのかどうか、よく分からない。鍼灸院で買ったもぐさがまだだいぶ余っているので、それを使い切るまでは続けようかと思っている。

2016-06-03

.cabalファイルのghc-optionsに何を書くべきか


ふと、Haskellパッケージの.cabalファイルのghc-optionsフィールドに何を書いておくとよいか不安になったので、少し調べた。

なお、cabalが実際にどのようなオプションghcに与えているかは--verboseオプションで確認できる。

$ cabal build --verbose

stackを使う場合、--verboseオプションはstack自身の、--cabal-verboseオプションはcabalのverbosityを制御する。

$ stack build --verbose --cabal-verbose

参考:

-Wall -fno-warn-unused-imports


これらは書くようにしている。

"-Wall"はご存知コンパイラの警告を全て表示するオプションである。

"-fno-warn-unused-imports"は不必要なモジュールやシンボルのimportに対する警告を無効化するものである。古いバージョンのghcでは必要だったimportが新しいバージョンのghcでは必要無くなることがあるのだが、このオプションがないとそんな場合にも警告が出てうっとうしいからだ。

-O[n]


最適化オプション。個人的には、これは書かなくてよいと思っている。

cabalはデフォルトで-Oオプションghcに渡してコンパイルするらしい(cabal-install-1.24.0.0時点)。この挙動はconfigure時に設定できる。

$ cabal configure -O2

デフォルトでレベル1の最適化をするので、まあ特に設定しなくていいかなと思っている。他人のパッケージの.cabalをいくつか見てみたが、-O2と書いているものもあれば、何も書いてないものもあり、まちまちなようだ。

他のオプションでもそうだが、最終的にはユーザーがビルドする際に上書き設定すればよいだろう。

-X[LANGUAGE_EXTENSION]


ghc拡張機能スイッチ。これは書くべきではない。.cabalではdefault-extensionsフィールドとother-extensionsフィールドが使える(Cabal-1.10から。それより前ならextensionsフィールドが使える)ので、こっちを使うべきである。

なお、default-extensionsフィールドに書いた拡張機能はパッケージ内の全モジュールで有効になる。other-extensionsフィールドはパッケージが使う拡張機能宣言するだけのものであり、各モジュールはLANGUAGEプラグマを使って必要な拡張機能のみを有効にする。

-threaded


OSスレッドを使用する。リンカオプションなのでlibraryセクションでは(多分)不要。他は個別の事情に合わせて、といったところだろう。

プログラムの作りによっては-threadedオプションがないと動かなかったり、逆にあると動かなかったりするので注意を要する。

以前、同じテストプログラムを-threadedのあるバージョンとないバージョンで2通りテストしたいことがあったが、結局test-suiteセクションをコピーして2つ並べてしまったことがある。何かよい方法はないだろうか。

-rtsopts


コマンドラインやGHCRTS環境変数からのRTSオプションを全て受け付ける。リンカオプションである。入れたほうがexecutableを使う立場としては便利だが、セキュリティ上のリスクがあるのかもしれない。

なお、デフォルト(-rtsopts=some)ではごくごく一部のRTSオプションしか受け付けないらしい。

"-with-rtsopts=-N[n]"


"-with-rtsopts"はRTSオプションをリンク時に指定する。-Nオプションはn個のOSスレッドの同時使用を許可する。n省略時はCPUコア数に応じたよしなな値が使われる。-threadedをつけるならセットでつけておいた方がなにかと便利だろう。

なお、-with-rtsoptsによる設定は-rtsoptsがなくても有効になる。-rtsoptsはあくまでプログラム実行時にRTSオプションを設定できるかどうかを制御するものである。

また、-with-rtsoptsではスペース区切りで複数のRTSオプションを並べることができるが、これを.cabalに書くには上に示したように-with-rtsopts=...全体をダブルクォートするべしとのこと( https://github.com/haskell/cabal/pull/1346 )。

"-with-rtsopts=-M512m"


"-M"オプションは最大ヒープサイズを制限する。自分の書いたプログラムバグによってメモリが無限に食いつぶされるのが怖いので、自分はtest-suiteにはこれをいれるようにした。(参考: http://qiita.com/debug-ito/items/87fa50d5324e20936d7e )

2016-05-05

Stackageに自分のパッケージを上げる


最近はもうstackとstackageには頼りっきりで、使いたいパッケージがstackageに入っていないとちょっとイラッとくるくらいになってきたが、そういえば自分もいくつかのパッケージをhackageに上げている。大したものではないとはいえ、それらをstackageに載せないのはスジが通らないなと思い、stackageに上げることにした。

さて、自分のパッケージをstackageに上げるにはどうすればいいか。必要なことは以下のページに書いてある。

手順としては、stackageレポジトリをforkして、build-constraints.yamlに自分の名前とパッケージのリストを追加して、pull requestを送るだけだ。

ただし、stackageに入れるパッケージは以下の3点を満たす必要がある(あるいは、満たす「べき」である?)

  1. All packages are buildable and testable from Hackage.
  2. All packages are compatible with the newest versions of all dependencies.
  3. All packages in a snapshot are compatible with the versions of libraries that ship with the GHC used in the snapshot


travisスクリプトビルドエラー対応


第1の条件はこれまで通りきちんとパッケージングしてhackageに上げれば満たされる。

テストに関しては.travis.ymlが提供されているのでこれをサクっと利用するのがいいだろう。

GHC + cabalおよびstackを用いたビルドパターンをいくつかのバージョンでやっている。なかなか良さそうだ。

なお、stackageに上げたパッケージがビルドに失敗する場合、「1週間以内を目安に解決しろ」とのこと。


依存パッケージのバージョン上限問題


第2の条件は、stackageに上げるパッケージが依存するパッケージのバージョン上限に関係する。

例えば、.cabalファイルに以下のようなbuild-dependsがある場合、

  build-depends: foo-bar >=0.3.0.1 && <0.5

foo-bar-0.5がリリースされると第2の条件が満たされなくなる。この場合、foo-barに依存しているパッケージの作者が(1週間以内を目安に)解決しなければいけない。foo-barの変化が小さければ新バージョンでのビルドとテストを確認してbuild-dependsを変更するだけでよい。そうでない場合はちょっと厄介なことになるだろう。

ここで問題となるのは、依存パッケージが他人のものである場合、それがいつメジャーバージョンアップされるか分からないということだ。この問題に対処するために、以下のサービスが公開されている。

このサービスは検索したパッケージの依存パッケージのバージョン上限を調べ、それが現在の最新版をカバーしているかチェックしてくれる。パッケージ検索ではauthorフィールドも検索対象になるので、例えば筆者の場合は

ウォッチすればいい。RSSフィードも吐いてくれるので、こいつをフィードリーダーに突っ込んでおけば速やかに依存パッケージのメジャーバージョンアップに対処できる、はずだ。

なお、PVPには反してしまうが、依存パッケージにバージョン上限を記載しないという考え方もある。この件についてMichael Snoyman氏がブログに書いている。

stackage的にはバージョン上限はあってもなくても構わない、ということだろうか。また、stack sdistとstack uploadには--pvp-boundsというオプションがあり、build-dependsのバージョン下限・上限をいい感じに書き加えてくれるらしい。

個人的には、今のところbuild-dependsのバージョンは自分で管理すればいいと思っている。いろいろ規模が大きくなると破綻しそうな気もするが。


依存パッケージのバージョン下限問題


第3の条件は依存パッケージのバージョン下限に関係する。要は、「GHCバンドルされるパッケージバージョンがカバーされるくらいには下限を広く取れ」ということである。

このことの理由は以下で詳細に説明されている。

"lenient"とは"not as strict as expected"という意味らしい。

例えばあるGHCバージョンにパッケージfoo-bar-0.2がバンドルされており、自分のパッケージのbuild-dependsがfoo-bar >=0.3だとする。すると、バンドルされたfoo-bar-0.2とユーザスペースにインストールされたfoo-bar-0.3が混在する状況になりうる。これが結構ややこしいコンパイルエラーを引き起こし、運が悪い場合は詰む。

さらに言うと、Haskell Platformで提供されるパッケージバージョンをカバーしておくといいようだ。これらは以下のページで確認できる。

ぶっちゃけそれほど多くないので、現状では人力でチェックすればいいと思う。

2016-04-30

Gtk-Uguiss-2.00をリリースした


Gtk2/Gtk3/xfwm4テーマであるGtk-Uguissの新バージョンを作った。

f:id:debug-ito:20160430115553p:image:w600

バージョン1.xx系列はXubuntu 14.04 (Trusty)が、バージョン2.xx系列はXubuntu 16.04 (Xenial)がターゲットである。いろいろ試行錯誤して目に着いたバグは潰したのでリリースした。

なお、そもそもなんでGtkのテーマなぞ作っているかはGtk2/Gtk3/xfwm4テーマを作った - DebugIto’s diaryを参照。

バージョン2.00の主な変更点は以下の2点である。

  • Xfce4.12の新ウィンドウスイッチャへの対応。
  • Gtk3の怒濤の変化への対応。

Xfce tabwin


TrutyのXfceは4.10だったが、Xenialでは4.12になっている。Xfce4.12では、ウィンドウスイッチャ(通称"tabwin")が新しくなり、ウィンドウサムネイルの表示やマウスでのウィンドウ選択が可能になった。

ということで、このtabwin向けの色設定を追加した。

Gtk3の互換性問題


Gtk3は、Trusyではバージョン3.10, Xenialでは3.18になっている。この間、互換性を破壊するものを含む様々な変更が加えられたようで、その対応に追われた。新しく追加されたウィジェットやエフェクトに正常にスタイルが当たらないならともかく、checkboxやspinnerといったごく基本的なウィジェットへのスタイル設定がぶっ壊れているのを見た時には開いた口が塞がらなかった。

Gtk3の連中は後方互換性を維持するつもりがあるのだろうか。あまり好き勝手なことをやっているとユーザ(ここではテーマ開発者)から愛想をつかされ、コミュニティは衰退し、結局自分たちしか使えない何かになり下がりはしないか。実際、Xubuntu 16.04のリリースブログ記事にはこんな文言がある。

Albatross, Bluebird and Orion GTK+ themes have been dropped since they do not support newer GTK3 versions


16.04になってデフォルトのテーマ設定の選択肢が非常に狭まったと感じたが、Gtk3のせいなのだろう。

もちろん、新機能を追加したり既存の問題を解決したりするためには後方互換性を破壊する変更がしばしば必要になるので、なかなか難しいところではある。Gtk3の開発ロードマップがどうなっているのか知らないが、どこかの時点でメンテナンスモードになって、非互換な開発はGtk4で進むようになることを願う。

Gtk3のテーマ開発


Gtk3のテーマ設定は大部分がCSSで書かれているが、自分は以下のような手順で修正を行っている。

  1. gtk3-demo、gtk3-widget-factory、その他のGtk3アプリを使って問題のある箇所を見つける。
  2. その箇所に設定されていそうなCSSクラス名を推測し、テーマファイル(ほとんどの場合はgtk-widgets.css)内を探す。
  3. 修正すべき箇所を同定するため、CSSファイルを書き換えて「マーカースタイル」を設定する。例えば、background-color: redとかborder: solid 3px redとかpadding: 50pxとか、とにかく変化が目立つもの。
  4. マーカースタイルが狙い通りの場所に現れていればそこが修正すべき場所なので、適宜修正する。マーカースタイルが表れていなければ、別の場所を試す。

このように、いわばprintfデバッグCSS版のようなことをやっている。実に効率が悪い。

Web開発であればCSSを修正する作業はもう少し楽なはずだ。ドキュメントの構造はHTMLを見れば分かるし、最近のWebブラウザには超優秀なインスペクタがデフォルトで積んであるので、どこに書かれたスタイルがどう効いているのか一目瞭然である。ブラウザ上でリアルタイムに修正することすらできる。

Gtkにそういうものはないのか?

と思って調べたら、まさにGtkInspectorというものがあるそうだ。

Gtk3.14から利用可能とのこと。gtkparasiteというツールが土台となっているらしい。なるほど、これは具合が良さそうだ。今度なにかあったら試してみよう。もっと早く調べるべきだった。

XfceとGtk3


tabwinのスタイル設定をして気付いたのだが、tabwinを含むXfce4.12のアプリはいまだ大部分がGtk2を使っている。テーマ開発者としては安定しているGtk2を使ってくれる方が助かるが、いつまでもGtk2を使っていていいのかという不安もある。

と思っていたら、開発者のブログにちょうどそういった記事が上がっていた。

どうやらXfce4.14の目標は、大部分のアプリをGtk3にポートすることらしい。ほっとしたような気もするし、余計なことを・・ ともちょっと思う。

まあXfceならそんなにキレッキレのGtk3機能は使わず、無難なウィジェットにおさまることだろう。

2016-04-23

鼻詰まり時の鼻うがい


前回の慢性上咽頭炎の近況で書き忘れていたが、花粉症などで鼻が詰まっている時の鼻うがいについて記す。

当然だが、鼻の通りが悪い状態では鼻うがいもやりづらいし、鼻が完全に詰まっている状態では鼻うがいはほぼ不可能だ。

そのような時にも鼻うがいをやるテクニックとして鍼灸師さんから教えてもらったのが「スクワットをする」ことである。スクワットをすることで一時的に鼻が通るようになるので、その隙に鼻うがいをするのだとか。花粉症で鼻が詰まっている時に実際にやってみたが、確かに心持ち鼻が通る気がした。

他にも、「ペットボトルか何かで脇の下を圧迫すると、その逆側の鼻が通るようになる」というのをためしてガッテンでやっていた。ただしこれは長時間やり過ぎると腕の血流が悪くなるので要注意である。

また、個人的な経験では、朝、冷水で顔を洗ったり髪を濡らしたりした後に鼻が通りやすくなったと思う。逆に、うがいをすると鼻が詰まった。理由はよく分からない。

ただ、本当に花粉症が厳しい時は何をどうしても完全に鼻を通すのは不可能である。完全に鼻が詰まっている時は無理せず鼻うがいをしない方がいい。一応通るが通りが悪いときも、くれぐれも慎重にするべきである。無理に鼻の中に水を押し込むと、予想外の場所に水圧がかかって(多分)危険だと思う。