2016年12月10日

cygwinの依存関係を調べよう

パッケージ削ると動かなくなるとかヒドすぎる。
インストーラが依存関係解析してるんじゃないのか。

などという愚痴が出た準備室で新しいお仕事である。
「なんかcygwinのインストーラがチェックする依存関係、かなり怪しい」という考えの下、提供されているツールからある程度依存関係を調べられないかということを相談していた。

で、cygcheckとlddという二つのコマンドで対処することにした。
1: exeとdllをディレクトリから漁り、どのパッケージ由来かをcygcheckで調べる
2: パッケージに現れるexeとdllをlddにかけて、依存するライブラリを調べる。そのライブラリが所属するパッケージへの依存関係が発生する。

まあ出来ないものじゃないし、とPerlでスクリプトを書いてやってみたのだが、cygcheckがやばいくらい遅い。
どうもcygcheckはパッケージ一覧とファイル一覧を持っていて、パッケージ由来は逆引きをやっているっぽいのだ。
多分ボトルネックになってるのは、HDDだからか、ファイルがバカみたいに増えて単に逆引き自体が遅いか(フルインストールなので60GBを越えている)、のどちらかだろう。
まあどちらにせよ解消しないといけない問題なので、別の方法で解決しようと考え中。

パッケージ一覧から作れば逆引きできるよねえ、Perlなんだし。
posted by chiguri at 00:15| Comment(0) | PC

2016年07月19日

Android Studioを共有環境に入れよう!

ここでいう共有環境とは、以下のような特徴を持つ七面倒くさい環境を言う。
  • ユーザ個人の情報は Z ドライブにネットワークマウント( SMB で)される。数 GBくらいまで入る。
  • マシンのユーザプロファイル領域は高々数十 MB まででリミットがかかる。
  • ネットワークがプロキシ経由のみ。
  • 誰が何するか分かったものじゃない。
  • 通常利用時は、再起動すると C ドライブがロールバックする。もちろんインストール作業をする場合などはその機能を切れる。
  • ロールバックするので、ユーザプロファイルも消える。

ここまで書くとどこのことか分かるかもしれないが、まあ分かったところでさほど問題がないので気にしないことにする。
誰かが同じような環境にいないとも限らないわけで。


普通に使うと割と便利な Android Studio も、こんな環境では割と地獄になる。


普通に使おうとすると発生する問題


問題は致命的なものがいくつか発生する。一つずつ見ていこう。
  1. Android Studio の設定ファイルが C ドライブのユーザプロファイル以下に作られる(環境変数の有無にかかわらず)。何かのキャッシュが入っているためかそこそこ大きく、プロファイル領域を圧迫(というか平然とキャパオーバー)し、さらに再起動で消える。
  2. 設定しないとインストール時にユーザプロファイル以下に Android SDK を置こうとする。数百 MB である。以下同文。
  3. 起動後に始まるダイアログが、インストール時にどこに置いたかなど全く見ないで、ユーザプロファイル以下に Android SDK があるかを調べ、なかったらこちらが指定するか、さもなくばインストールするぞといってくる。入れたら以下略。しかも、ネットワークにつながっていると最新のファイルをダウンロードしてきて更新しようとする。
  4. ビルドに使う Gradle がユーザプロファイル以下に .gradle というフォルダを作り、そこに設定やらキャッシュやらを貯め込む。他に比べれば大きくないが、ほとんど何もしないプロジェクトでも20MB程度使い、残念ながらこちらの環境ではキャパオーバーする。
  5. プロキシの設定が自動でされないため、ビルド時に Gradle が依存するライブラリを取りに行く際に止まる。拒否されるのではなくタイムアウト待ちになるので、ビルドがちっとも終わらない。当然、長く待った挙げ句にエラーになる。さらに、ネットワークにつながっていると環境をアップデートしようとする。再起動すると戻るのに。
  6. プロジェクトを作るデフォルトの位置が C ドライブのユーザプロファイル以下に AndroidStudioProjects というフォルダになっている。間違ってここに作ると再起動時に消える。そもそもファイルサイズが以下略。

もうインストールやめてもいいだろうか・・・?
いやいや、問題を片付ければ使えるかもしれないじゃないか。続けよう。


問題回避


では一つずつ解消しよう。

  1. Android Studio の設定ファイルの位置は Android Studio をインストールしたフォルダの bin の下にある idea.properties を編集すれば良いようだ。あまり直接はいじらないらしいが、全体としてそうしたいので何も思わない。個々で設定は変えたいので、 Z ドライブ以下に作るようにした。
  2. インストール時には Android SDK を C ドライブの皆が見える位置にインストールする。インストール時に指定するだけなので簡単。
  3. 起動時の Android SDK に関するダイアログについてはスキップするようにした。 idea.properties に disable.android.first.run=true と入れるとスキップできる。どこに書いてあるんだそんなこと。
  4. GRADLE_USER_HOME という環境変数に位置を指定すれば Gradle の設定の位置を変えられるらしいので環境変数を追加した。
  5. Gradleの設定に Offline work というものがあった。これを指定すればネットワーク待ちは回避できる。指定させるのは面倒なのだが、現状設定方法が分からない。
  6. プロジェクトの位置は一度作れば設定ファイルにその場所を格納するので、一度目に口酸っぱく Z ドライブに作るよう言うしかない。これもデフォルト指定ができれば良いのだが、方法が分からない。

さて解決したか・・・と思いきや、まだ問題が発生する。


問題回避による問題


回避策によって起こった問題は以下のもの。
  1. 上の 3 のダイアログスキップの影響で、最初に Android SDK の位置を別途指定する必要が出てきた。
  2. 上の 5 の Offline mode の影響で、依存性解決が出来ない。プロジェクトが最初に作るユニットテスト用の junit も見つからない。
  3. 上の 6 のプロジェクトがネットワークドライブ( SMB )上にあることで、ビルドが極端に遅い。ローカル HDD と比較して 60 倍くらい(秒→分で良い感じ)。どうもファイル一覧の取得が必要になって死ぬほど遅くなってるらしい。

そろそろめげてきただろうか。
しかし回避しなければならない。
  1. 仕方ないので Android SDK のパスを指定させることに。幸い SDK の位置なしにはプロジェクトを作れないので、そうそう問題は起こるまい。
  2. 依存性解決のために、 jar を配置したフォルダを指定する Gradle のスクリプトを配置することにした。 Android Studio をインストールしたフォルダの gradle\gradle-2.10\init.d というフォルダに置かれたスクリプトが必ず実行されるらしいので、そこに allprojects { repositories { flatDir { dirs 'ほげほげ' } } } という記述を入れたファイルを置いた。
  3. 遅いのはビルドの時だけだったので、ビルドディレクトリの指定をした。先ほどの gradle のフォルダに置いたファイルに gradle.projectsLoaded { rootProject.allprojects { buildDir = "C:/Users/${System.env.USERNAME}/AppData/Local/Temp/${rootProject.name}/${project.name}" } } と指定。幸いテンポラリフォルダはプロファイル領域から除外されていたので動く。

次にいこう。まだ終わらない。
  1. 上の 2 の jar の無理矢理な指定のせいで、ユニットテストが動かない。本来はプロジェクトフォルダの app\libs に入れるはずなので、ここに必要なものを持ってこないといけない。
  2. 上の 3 のビルドディレクトリ指定により、再起動時に消えることになる。それを試すと、起動時にあらゆるシンボルの解決に失敗する。なお、ビルドはできる。
  3. ビルドディレクトリの問題か、 Android Studio がある生成物である jar ファイルのロックをかけたまま離してくれない。(フルパスを途中からだけ書くと、 appcompat-v7\23.3.0\jars\classes.jar という名前)

これは解決できるのかって?結果を見てみよう。そろそろ年貢の納め時らしい。
  1. 残念ながら現状回避策なし。試しに必要とおぼしき jar ファイルをいくつか libs の中に入れてみたが、なにやらエラーが出た。もう体力がないので今回は断念。つまりユニットテストをするな、と。(投げやり)
  2. ビルドメニューから Make Project をして、 Fileメニューにある "Invalidate Caches / Restart..." から、 Invalidate and Restart を選ぶ。 Android Studio が再起動するが、環境に問題がなければ、再起動後に indexing が行われてシンボルが解決できるようになる。
  3. 未だに回避策不明。 instant go のせいという Stackoverflowの回答もあったが、どうやらそれではない様子。ロックを強制的に解除するプログラムを使う手も説明されていた。ちょっと怖い。(これ実行に管理者権限いらない?)

というわけで、問題が残ってしまった。


現状


割とどうでも良い制限は以下。
  1. 初回に Android SDK の位置を指定する必要がある。
  2. Gradle の Offline mode を指定する必要がある。
  3. 初回に C ドライブにプロジェクトを作らないようにしないといけない。

そして致命的な問題が以下のもの。
  1. Gradle が jar を消せずに失敗する。回避策不明。 Gradle のメニューから別途ビルドすれば出来なくはないが・・・
  2. ユニットテストができない。もう勘弁してほしい。

現状は以上の通り。解決すれば書き換えたりするかも。続きを読む
posted by chiguri at 20:00| Comment(0) | PC

2016年05月11日

Werckerのboxの作り方(変更に巻き込まれた話)

Werckerというのは、非常に荒っぽくいうと、githubやbitbucketのリポジトリにpushした際に、ある特定の環境でビルドできるか確かめたりテストしたり、ということができるサービスの一つである。
他にも似たようなものはあるが、Werckerの良いところは、無料、bitbucketに対応、プライベートリポジトリにも対応、自分でboxが作れる、という点だろうか。

で、一昨日からboxを作ったりしたのだが(OCamlが入ってる環境が見つからなかったので作っただけ。実際はOCaml入れてCoqをビルドしたりするboxもあるので入ってはいるはずなのだが。)、そのときは検索をかけて見つかる情報通りに作って正しく作れた。
しかし、昨日Prologのboxがないことに気づいて作り始めたところ、何度やっても失敗してしまうようになった。

そもそも、一昨日作ったapplicationと昨日作ったapplicationで、表示されるオプションが全然違う。
ビルドに成功しないから展開(deploy)もできない。
ひたすら環境構築の部分でNo wercker.yml exists!とエラーを出し、ビルドに失敗した旨のメールを自分に送り続ける時間。
一体なんなんだこれは!と家で叫んだりした。

そして今日、一昨日付のこんな記事を見つけた。なんか新しい機能の紹介らしい。
多分、これが昨日自分のアカウントでも有効になったのだろう。
で、この記事の中に、ちょっとだけ「(stepの)deployとかするのはcreate stepでやってね」と出てきた。

みんな(werckerの公開してる有志の?資料でも)「Applicationを作ってビルドしたら成功するよね。じゃあ・・・」と書いてるのに。
記事にちょっとだけ「Step作ってね。」である。
ちゃんと書け。

それに気づいてcreateで選ぶものをApplicationからStepにしたところ、問題もなくbuild、deployできた。
とりあえず、という程度ではあるが、SWI-Prolog用のboxができた形である。
気が向いたら使ってみてほしい。(まだテストもしていない)
posted by chiguri at 13:52| Comment(0) | PC

2016年03月25日

LinuxホストのVirtualBoxのフォルダ共有でこけた

タイトルが長いのは気にしない。
その内容の通り、LinuxをホストにしたVirtualBoxでWindows 7をゲストにしたら困ったという話。

実のところ、別にLinuxがホストだろうとインストールはスムーズにいき、(環境が32bitのせいで)メモリに苦労するものの動いてはいた。
しかし、いざ共有フォルダをつくったらまずいことが起こった。
explorerからファイルをコピーしようとするとエラーが起こるのだ。
具体的には「エラー0x80070057: パラメーターが間違っています。」だ。
ちなみにメモ帳で開こうとしてもほぼ同じエラーが出る。なんだこれは。
しかもコマンドプロンプトで適当にリダイレクトするとファイルが作れるのだ。
さらに、copyコマンドも正常に働く。
移動、削除はexplorerからも可能。
一体何が起こっているのだ。

検索しても検索しても「バックアップで失敗する」話ばかりで何も分からなかったのだが、一つ気になるものがあった。
"Code 0x80070057 The parameter is incorrect" error when you try to display a user's "effective access" to a file
これだ。
effective accessと言われてもさっぱり分からないが、しかしエラーとユーザーのアクセスという点で一致する。
中を読むと大まかにはこういうことが書いてある。

SMBを使った共有フォルダについて、\\host\dirみたいな書き方をしたやつでアクセスする場合を考える。ここで相手のSMB提供プログラムがMSのじゃない場合、ファイルのオーナーをパラメータとして要求してくる。しかし、explorerはオーナーを書こうとしないからエラーが返ってくる。これがそのままユーザーに渡される。実は、SMBの仕様上はオーナーの部分は必須ではないのだが、これを必須とするシステムもある。

今回のにぴったりな状況だ。SMBを提供しているのはVirtualBox、アクセス先は\\vboxsrv\hoge、「パラメーターが間違っている」というエラーメッセージ。
さて、この文書は解決策としてパッチの存在が書いてある。
ただし、Windows8.1以降。

8.1以降。

今入れたの、7なんだが。
え、パッチないの?
まじで?え??

・・・Linuxの方にSamba入れてホストオンリーアダプタで対処することにしよう・・・
posted by chiguri at 00:36| Comment(0) | PC

2015年09月27日

EmacsでPrologの設定

今いるところ、時々研究でSWI-Prologを使う。
良いと思う、推論などが関わるとやはり論理型言語のフィット感は素晴らしい。
ただ、エディタがTeraPadなのは許せない。
許せない。
大事なことなのでもう一回。
許せない。

という話は、ここにあるのだけれども、今回はEmacsを導入しよう、となった話。
SWIの公式ページには、FAQの中にEmacsの設定の話がある。
――のだが、これがいくら何でも古くて何が何だか分からない。

Emacs22まではおそらく説明通りで良いのだが、23以降だとこのような手順になる。
  1. Emacsを導入する。

  2. SWI Prologをインストールする。

  3. Emacsを起動し、M-x customize-groupを実行し、prologを選ぶ。

  4. Prolog systemがswiになっていることを確かめる。(デフォルトでそうなっているはずだが、なっていなければ変更してSave for future sessionsで保存する。Emacs22以前だとこの時点で項目がないはずなので公式ページを参考にprolog.elを導入すること。)

  5. 下部のリンクでProlog Inferiorに飛び、Prolog Program Nameにプログラムのパスを入れる。ここで入れるのはswipl.exeのパスであり、plcon.exeなんて現存しないので注意。また、パスのフォルダをバックスラッシュ一つで区切るとおかしなことになるので、バックスラッシュ二つかスラッシュに変更すること。

ページでおかしいのは、prolog.elが23以降まともなものが同梱されたこと、Prolog Program Nameに入れるプログラム名が変わっていること。そのくらいは変更してほしいところだ。
posted by chiguri at 02:04| Comment(0) | PC