と、タイトルのまんまなんですが、R-3.4.0.pkgを普通にダウンロードしてインストールすると、最後の最後で、「失敗しました」と残念なメッセージ。
でも、アプリケーションフォルダを見るとR.appはあって、起動もできる。何を失敗したのかと思ったら、コマンドラインからRと打っても、なにも起動しない・・・。ちょっと探しましたが、同じ事で困っている人が見付からないので、私だけ?と思いつつ、手作業で以下のリンクを作成。 /usr/local/bin$ sudo ln -s /Library/Frameworks/R.framework/Versions/Current/Resources/bin/R . なんでこんなことしないといけないんだ?という感じですが、コマンドラインから動くようになったので、よしとしましょう。 Jupyter notebookから使えるように設定するのは、jnobuyukiのブログを参考にさせていただきました。 |
Kerasを使いたいだけだったんですが、backendのTensorFlowが、glibc-2.14以上を要求します。theano使えば?という話もありますが、なんかGoogleのTensorFlowの方が凄そうということで、ちょっと頑張って見ることに。
適当に新しいglibcを持ってきて展開し、LD_LIBRARY_PATHに設定すると、ログイン出来なくなります。ここは冷静に環境変数を戻して事なきを得ましたが、Pythonが起動する時だけ、新しいglibcを使うようにするには、どうしたらいいか探していたら、良い記事が。 RHEL6 の環境で TensorFlow を起動させる 言われたとおりに設定すると、import tensorflowがエラー無く通るようになります。やったーと思ったのも束の間、kerasでAutoencoderを実行すると、いきなりエラーが。 2017-06-15 18:02:30.046684: E tensorflow/stream_executor/cuda/cuda_blas.cc:365] failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED 少ししらべると、CUDAがきちんと設定されていない、古典的なエラーのようです。なぜ?CUDA入ってるのにと思ったら、glibcに7用のものを使っているので、CentOS6用のCUDAを使っていてはダメなことに気が付き、CentOS7用のCUDAを持ってきて、インストールすると、動くようになってくれました。 ちなみに、作ったaliasはこんな感じ。 alias tf_python='/home/tsuji/local_lib/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/cuda-8.0_cent7/lib64:/home/tsuji/local_lib/lib64:/home/tsuji/local_lib/usr/lib64/ /home/tsuji/anaconda/bin/python' |
すごい久しぶりの更新。
Google App Engineが、Google Cloud Platformサービスの一環になって、GUIで便利に使えるGoogleAppEngineLauncherが、どうも置いて行かれている雰囲気を薄々感付いてはいたのですが、重い腰を上げ、Google Cloud SDKを使って見ることにしたので、メモしておきます。 まずは、ダウンロードしてインストール。 https://cloud.google.com/sdk/docs/quickstart-mac-os-x あたりから、とってきます。解凍した場所がそのままファイルの置き場所になるので、~/Downlodsとかにならないように注意しましょう。 そもそも、Python3で動かないあたりもちょっと不満なんですが、install.shを起動するまえに、環境変数を整備します。 export CLOUDSDK_PYTHON="/usr/bin/python2.7" パスは適当に変更してください。 $ ./install.sh でインストール出来ます。.bash_profileを書き換えるので、シェルの再起動か、sourceコマンドで読み込み直します。 いろいろごちゃごちゃ言われるかも知れませんが、App Engineの設定だけなら以下で。 $ gcloud components install app-engine-python まずは初期化。 $ gcloud init すでにGAEのプロジェクトをいくつか持っているとその一覧が表示されるので、番号で選びます。Launcherと違って、ちょっと面倒。 ちなみに、プロジェクトを変更したいときは、 $ gcloud config set project プロジェクト名 いまどのプロジェクトにいるのかは、以下で分かります。 $ gcloud config list さあこれで開発ができると思ったら大間違い。ローカルで開発用のサーバを動かすためのPythonスクリプトが、2専用。Googleは、Pythonから離れようとしているんじゃないか?と疑わせる、3のサポートの悪さです。 仕方無いので、condaで2の環境作ります。 $ conda create -n py27 python=2.7 設定が終わったら、2の環境を起動。 $ source activate py27 ちなみに、一覧を見るには、 $ conda info --envs これで、やっと、ローカルの開発用サーバが動きます。Launtherのが数倍楽・・・。 動かすアプリのapp.yamlがあるディレクトリで、 $ dev_appserver.py . アプリを作って、デプロイするときは、以下のコマンドで。 $ gcloud app deploy サーバのページを開きたいときは、これが使えます。 $ gcloud app browse ちなみに、Googleのサーバ上で始めてしまったプロジェクトを、gitでcloneするのは、以下。 $ gcloud source repos clone python-gae-quickstart --project=プロジェクト名 ファイルをローカルで変更した後、もちろん、コミットしてもいいんでしょうが、deployすると、そのまま上がります。 Cloud Platformになって、進化している部分もあるようで、StaticなWebをホストする方法が以前より、簡単になっているようです。(これはまだ試してませんが) https://cloud.google.com/appengine/docs/python/getting-started/hosting-a-static-website ちなみに、古いプロジェクトを、そのままデプロイしようとすると嵌まります。正しいのかどうか分かりませんが、app.yamlから、以下の2行を削除すると、動くようです。 #application: プロジェクト名 #version: 1 ちゃんとした移行ドキュメントがそのうち出るという噂を、どっかで見ましたが、早く出て欲しいものです。 |
20年ほど前、学部の卒業論文を書くために初めてつかってTeXですが、こんなおっさんになっても、世話になっているなんて、当時は想像も出来ませんでした。
まあ、それはいいとして、TeXはちょっとコンパイルが面倒なので、MAKEファイルを作るのがいいです。 ただ、Pythonとか他の環境から、TeXをコンパイルしたいなーと思うこともあるかも知れません。通常TeXはエラーがあると、OSシェルからインタラクティブにユーザーに対して対応方法を聞いてきますが、Pythonからコンパイルしている時は、面倒なので、成功か失敗かを教えてくれると便利です。 そんな時使えるのが、-halt-on-errorオプション。コンパイル中にエラーが起こると、そこで処理を中断します。Pythonから使うイメージは、こんな感じでしょうか?
異常終了だと、retが0ではない数字になるので、その後の処理を分岐できます。 向こう5年で、3人くらいの人にしか役に立たなそうな記事だし、そのうちの1人は、忘れて、検索して、自分のブログに辿り着く私な気もしますが、ネットに書いておくとあとで探せるので便利です。 |