Emacs on Win32を25.1.1に更新
Emacs24.1でM-x grep-findを実行すると、not matches foundとメッセージが出てgrepできない。
Windowsが内部エンコーディングがShift-JISだから動作しないのだろうと踏んで、emacsのエンコードをShift-JISに設定したのだけど、うまく動作しない。
どうやらシェルの設定をbashにして、cygwinのbinのパスを通せば動作するらしいということで、init.elに以下を追加してみた。
(setenv "PATH" "C:/cygwin/bin")
(setq shell-file-name "C:/cygwin/bin/bash.exe")
するとgrep-findは動作してgrepした文字列は取得できるようにはなったけど、今度は
といった警告メッセージも出るようになった。
grep: warning: GREP_OPTIONS is deprecated
この警告メッセージはgrep2.21から出力されるようになったらしいけど、emacs上で出力されているのはバグっぽい.
My Future Sight for Past: Solution of grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
1176547 – emacs grep warns "GREP_OPTIONS is deprecated"
公式サイトを確認すると25.1がリリースされていたので、更新するとgrepの警告メッセージが出力されなくなってあっさりと解決した..
ただし、init.elには
を設定しておかないとうまく動作しなかった.
(setenv "PATH" "C:/cygwin/bin")
TimeMachineのファイル backuppdbの削除方法
既出事案らしいのですが、知らずにTime Machineのファイルであるbackuppdbを削除したらゴミ箱を空にできなくなったという話。TimeMachineを無効にしたので、バックアップファイルいらないから削除!とかやった自分が全て悪いわけですが。
しかしrootでrm -rfでも消えないし、さらにSSDをフォーマットしてOSを再インストールしたあとゴミ箱を覗くとbackuppdbが残ってる..不死身か。
途方に暮れて調査していると以下の記事を発見。
Time Machineのファイルを直接削除 - Qiita
いざという時のために、Time Machineの権限を持った状態で他のコマンドを起動するコマンドが用意されているようです。実行したいコマンドを引数にrootから実行してやればOK。
Time Machineのファイルを直接削除
脱法コマンドだと..?
ターミナルから以下を叩く.
$ sudo /System/Library/Extensions/TMSafetyNet.kext/Contents/Helpers/bypass > rm -rf /Volumes/<Volume Name>/.Trashes/Backups.backupdb
き、消えたー!
ただ以下のような指摘もあって、bypassコマンドは危ないからtmutil使えって書いてあります。
最初から知ってればこれ使って消してましたが...ゴミ箱に放り込んだら意味なしですよね.
macos - How can I delete Time Machine files using the commandline - Super User
というわけでTimeMachineのバックアップファイルを迂闊にゴミ箱に放り込まないように気をつけよう。
android SDKアップグレードによるappcompat-v7のエラー対処
android SDKのバージョンをAndroid6.0(API 23)にアップグレードして、プロジェクトを読み込むと以下の箇所でエラーになり、ビルドできません。
import android.support.v7.app.ActionBarActivity;
以下のエントリによると、どうやら新たにappcompatを設定しないといけないようです。
https://akira-watson.com/android/lollipop-api-21.html
android - Private Librariesが消えてしまいました｡ - スタック・オーバーフロー
当方もandroid studioにまだ移行できてないので、非常に助かりました..
AppCompat
そもそもAppCompatってなんぞと思ったので調べてみました。
AppCompat（別名 ActionBarCompat）は Android 4.0 の ActionBar API を Gingerbread 搭載デバイスに対応させるためのバックポートとしてはじまり、バックポートとフレームワーク共通の API レイヤーを提供していました。
https://googledevjp.blogspot.jp/2014/11/appcompat-v21-lollipop.html
つまり上位のAPILevelの機能を下位のAPILevelで動作させるための仕組みと理解しました。
原因
上記のStackOverflowでも議論されていますが、どうやら新しいSDKにアップグレードしたことで、AppCompatを参照できなくなったようです。
なので、新しいAppCompatをインポートして、古いAppCompatを参照している設定を削除し、新しいAppCompatへの参照を設定することで解決できる模様。
Eclipseの場合、ActionBarActivityを使うには同じワークスペースのプロジェクトに、v7 support libraryが必要です。<中略>
android - Private Librariesが消えてしまいました｡ - スタック・オーバーフロー
ADTの以前のバージョンでは新規プロジェクトを作る度に、自動で最新版をインポートして新規プロジェクトと紐付けていたのですが、現在は手動でインポートしてビルドパスの解決を行う必要があるみたいですね。
現状確認
- プロジェクトを選択して右クリック[プロパティ]
- [Andorid]-[ライブラリー]のappcompatがエラーになっていることを確認
対策1:android-support-v7-appcompatのインストール
上記エントリにも書いてありますが、appcompat-v7の設定手順をメモとして残しておきます。
- [ファイル]->[インポート]->[Android]->[Existing Android Code Into Workspace]を選択
- [ルート・ディレクトリー]に
/extras/android/support/v7/appcompat/を参照するように設定 - パッケージエクスプローラにandroid-support-v7-appcompatのプロジェクトがインポートされる
- libs内のandroid-support-v7-appcompat.jarを選択して右クリック->[ビルド・パス]->[ビルドパスに追加]
- libs内のandroid-support-v7-appcompat.jarを選択して右クリック->[ビルド・パス]->[ビルドパスの構成]を選択
- プロジェクトのプロパティが開くので、[順序およびエクスポート]タブにandroid-support-v7-appcompat.jarが設定されていることを確認
- 同タブ内の[Android Dependencies]のチェックを外す
- 作成しているアプリケーションのプロジェクトを右クリック->プロパティ->[Android]->[ライブラリ]を開く
- 新しいappcompat-v7があることを確認したら古いappcompat-7を除去して新しいappcompat-v7を追加
上記エントリによればminSdkVersionを13以下に設定するとappcompat-v7が自動的に生成されてしまうようですので、14以上にすることで回避できるそうです。
<uses-sdk android:minSdkVersion="14" android:targetSdkVersion="21" />
ビルド
これで動くかと思いきや、ビルドすると今度は以下のようなエラー。
You need to use a Theme.AppCompat theme (or descendant) with this activity.ActivityでTheme.AppCompatを使えや!と怒られました。
対策2:style.xmlのThemeを修正
本件の対策については、以下に詳しく書かれていました。
Proguard有効でビルドを行ったアプリを起動するとIllegalStateException: You need to use a Theme.AppCompat theme... - Qiita
対策として以下を行いました。
- res/values-v11/style.xmlで定義されているTheme.LightをTheme.AppCompat.Lightに変更
- res/values-v14/style.xmlで定義されているTheme.Light.DarkActionBarをTheme.AppCompat.Light.DarkActionBarに変更
- proguard-project.txtに以下を追加
-keep class com.google.android.gms.** { *; }
-keep public class com.google.android.gms.**
-dontwarn com.google.android.gms.**
-keep class android.support.v7.** { *; }
-keep interface android.support.v7.** { *; }
- project.propatiesに記述されている以下のコメントを外す
proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
というわけで、無事に動作しました。
libeventのメモリリークを追う
デバッグしていると,libeventで盛大なメモリリークを確認しました。
スタックトレースで追っていくと、どうやらevthread_use_windows_threads()でリークしている模様。非同期処理するためには、この関数で有効化する必要があるんですけど、ここでリークしているとは...
調査してみると、コミュニティでは議論されている模様。
[Libevent-users] evthread_use_windows_threads() cause memory leak?
とりあえず終了時にlibevent_global_shutdown()を呼べばOK!みたいなことが書かれていたので、該当するAPIを探してみるものの存在しない。どうやら2.0.x系では無いみたいです。
というわけで、2.1.x系にアップデートしてlibevent_global_shutdown()を呼んだらリークは解消しました。
きっとevthread_use_windows_threads()で内部的に確保したリソースを開放し忘れていているんでしょうけど..
あとでソースを読んでみることにします。
