Wineで3Dなソフトがうまく動かないとき

普段使っているのはIntelのしょぼいグラフィックチップのPCなのだが
Windows用の3DなソフトをWineで動かしてみようとしたら

Unhandled page fault on read access

なんていうのが出た。

色々調べてみたところ、テクスチャの圧縮展開ライブラリ関係に問題があるらしい。
まあそりゃそもそもmesaドライバだしな。

libtxc-dxtn-s2tc というのを入れると改善するかも、とのこと。

sudo apt-get install libtxc-dxtn-s2tc-bin libtxc-dxtn-s2tc0

おお。魔法のようだ。

Win7でユーザのログインIDなどを変更する

Windows 7 は基本的にユーザの表示名が使われるようになっているので
表示名だけ変えれば普段は気にならないが、
リモートデスクトップなどで繋ぐ時に混乱の元になる。

リモートデスクトップで繋ぐ際に指定するユーザ名称を変更するには、
　　管理ツール→コンピューターの管理

で

　　コンピューターの管理→システムツール→ローカル ユーザーとグループ→ユーザー

を開き

　　「名前」をクリックして変更。
基本的にはこれでOK。

ただしこれだとユーザフォルダの名前が古いままで若干気持ちが悪い。

ユーザフォルダの名称を揃えるには、別な管理者アカウントでログインし、

C:\Users\の下のフォルダ名称を変更した上で、

レジストリエディタで

　　HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList

の下の
　　ProfileImagePath
の値をそれに揃えてやる事で、
次に該当ユーザでログインした際に辻褄が合う。　
この過程で、フォルダ名を変えようとして管理者アカウントでログインする時に
「ユーザの切り替え」をしてしまうと、元のユーザフォルダは使用中になっていて変更できないので
PCごと再起動する方がよい。

また、PCを再起動して別な管理者アカウントでログインしただけなのに
既に使用中になっていることもある。
自分の場合、Windows Media Playerのサービスがアクセスしていた。
　管理ツール→サービス
を開き、
　Windows Media Player Network Sharing Service
を「停止」させたところ、フォルダ名の変更ができた。

フォルダ操作をしようとしたときに「使用中です」となってしまう場合、
Unlocker を使うと何のプログラムがロックしているのか分かって便利。

ubuntuにapache-google-apps-ssoをインストール

https://github.com/epotocko/apache-google-apps-sso
ApacheのレイヤーでGoogle Apps認証かけちゃうというもの。
mod_auth_memcookieというモジュールとphpを使ってる。

まずapt関係で必要なものをゲット。

apt-get install memcached php5-memcache
apt-get install apache2-prefork-dev libmemcache-dev

次に、mod_auth_memcookieをビルド。
http://sourceforge.net/projects/authmemcookie/files/
からソースをDLし展開。

tar zf mod_authmemcookie_v1.0.2.tar.gz
cd mod_authmemcookie_v1.0.2

ubuntuの場合apxs2のインストールパスが違うので、Makefileを修正。

MY_APXS=/usr/sbin/apxs2
        ↓
MY_APXS=/usr/bin/apxs2

ビルド＆インストール。

make
sudo make install

apacheのロードスクリプトを書く。
/etc/apache2/mods-available/auth_memcookie.load

#一行で書く
LoadModule mod_auth_memcookie_module /usr/lib/apache2/modules/mod_auth_memcookie.so

有効化。

sudo a2enmod auth_memcookie

引き続き、phpなどの設定。

/var/www/auth ディレクトリを認証モジュール用に使い、
その他サイト全体を認証の対象とすることにする。

https://github.com/epotocko/apache-google-apps-sso
の中のsrc/public直下のphpファイルと、src/GAppsディレクトリ自体を
/var/www/auth/下にコピー。

git clone https://github.com/epotocko/apache-google-apps-sso.git
cd apache-google-apps-sso/src
sudo mkdir /var/www/auth
sudo cp -rf GApps /var/www/auth/
sudo cp -rf public/* /var/www/auth/.

次にphp-openid。
12.04ならばaptで入れたものでもOKだった。

apt-get install php-openid

10.04だとバージョンが古くてうまく動かなかったので、公式から落としてきて
その中のAuthディレクトリを/var/www/auth/以下にコピーする。

git clone https://github.com/openid/php-openid.git
cp -rf php-openid/Auth /var/www/auth/

ここから下は https://github.com/epotocko/apache-google-apps-sso の
公式の情報と基本的に同じ。

/var/www/auth/settings.phpファイルを更新。
コメントアウトされていない二行を編集。

GApps_Session::$BASE_URL = 'http://【ホスト名】/auth/'; //動かすホスト名
GApps_Session::$DOMAIN_NAME = '【Google Appsドメイン名】';

apacheの設定を書き足す。
default編集するなり、別ファイル作ってVirtualHostに入れるなり。

<IfModule mod_auth_memcookie.c>
    <Location />
        Auth_memCookie_CookieName GOOG_SESSIONID
        Auth_memCookie_Memcached_AddrPort 127.0.0.1:11211
        ErrorDocument 401 "/auth/login.php"
        Auth_memCookie_Authoritative on
        AuthType Cookie
        AuthName "GApps Login"
    </Location>
</IfModule>

<LocationMatch "^/(?!auth)">
    Require valid-user
</LocationMatch>

apache再起動。

sudo /etc/init.d/apache restart

gitで名前やメールアドレスを置換する

毎回調べてしまうので自分用メモ。

git filter-branch --commit-filter '
if [ "$GIT_COMMITTER_NAME" = "【修正前の名前】" ]; then
    GIT_AUTHOR_NAME="【修正後のAUTHORの名前】"
    GIT_AUTHOR_EMAIL="【修正後のAUTHORのメールアドレス】"
    GIT_COMMITTER_NAME="【修正後のCOMMITTERの名前】"
    GIT_COMMITTER_EMAIL="【修正後のCOMMITTERのメールアドレス】"
fi
git commit-tree "$@"
' HEAD

DjangoのURL namespacesのところを和訳した

https://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces
何回流し読みしてもよく分からないので、和訳した。

---

URL namespaces
URL ネームスペース

Namespaced URLs are specified using the : operator. For example, the main index page of the admin application is referenced using admin:index. This indicates a namespace of admin, and a named URL of index.

ネームスペースに関連付けられたURLは、：演算子を使い表現されます。例えば、adminアプリケーションのメイントップページは admin:index で参照されます。これはadminネームスペースのindexと名付けられたURLを示します。

Namespaces can also be nested. The named URL foo:bar:whiz would look for a pattern named whiz in the namespace bar that is itself defined within the top-level namespace foo.

ネームスペースは入れ子にできます。 foo:bar:whiz というURL名は、それ自身がfooというトップレベルのネームスペース内に定義されているbarというネームスペース内のwhizと名付けられたパターンを指します。

When given a namespaced URL (e.g. myapp:index) to resolve, Django splits the fully qualified name into parts, and then tries the following lookup:

与えられたネームスペースに関連付けられたURL（例…myapp:index）を解読する場合、Djangoは完全記述された名称を要素単位に分割し、以下の検索を試みます。

1. First, Django looks for a matching application namespace (in this example, myapp). This will yield a list of instances of that application.

まず、Djangoは一致するアプリケーションネームスペースを探します（この例の場合myapp）。該当するインスタンスのリストが抽出されます。

2. If there is a current application defined, Django finds and returns the URL resolver for that instance. The current application can be specified as an attribute on the template context - applications that expect to have multiple deployments should set the current_app attribute on any Context or RequestContext that is used to render a template.

もしカレントアプリケーションが定義されていれば、Djangoはそのインスタンスに対するURLリゾルバを探して返します。カレントアプリケーションはテンプレートコンテキストの属性として特定されます。複数デプロイされる事が想定されているアプリケーションは、テンプレートをレンダリングする時に使われるContextおよびRequestContextにcurrent_app属性がセットされるべきです。

3. The current application can also be specified manually as an argument to the reverse() function.

カレントアプリケーションはreverse()関数の引数として明示的に指定も出来ます。

4. If there is no current application. Django looks for a default application instance. The default application instance is the instance that has an instance namespace matching the application namespace (in this example, an instance of the myapp called myapp).

もしカレントアプリケーションが指定されない場合、Djangoはデフォルトアプリケーションインスタンスを探します。デフォルトアプリケーションインスタンスとは、アプリケーションネームスペースと一致するインスタンスネームスペースを持つインスタンスです（この例の場合myapp、と呼ばれているmyappのインスタンス（訳注：namespace="myapp",app_name="myapp"という事ですかね））

5. If there is no default application instance, Django will pick the last deployed instance of the application, whatever its instance name may be.

もしデフォルトアプリケーションインスタンスが無い場合、Djangoは最後にデプロイされたアプリケーションのインスタンスを取り上げます。そのインスタンス名（訳注：インスタンスネームスペース名？）が何であれ。

If the provided namespace doesn't match an application namespace in step 1, Django will attempt a direct lookup of the namespace as an instance namespace.

もし与えられたネームスペースがステップ１のアプリケーションネームスペースにマッチしない場合、Djangoはインスタンスネームスペースであるとして直接検索を試みます。

If there are nested namespaces, these steps are repeated for each part of the namespace until only the view name is unresolved. The view name will then be resolved into a URL in the namespace that has been found.

もしネームスペースが入れ子になっている場合、ビュー名が解決されるまでネームスペースの各要素ごとにこれらのステップが繰り返されます。ビュー名は見つかったネームスペース内のURLとして解決されます（訳注：ここ適当。ここに限らないけど）。

To show this resolution strategy in action, consider an example of two instances of myapp: one called foo, and one called bar. myapp has a main index page with a URL named index. Using this setup, the following lookups are possible:

この解決手順を順を追ってお見せするため、例として２つのmyappのインスタンスを考えます。片方はfoo、もう片方はbarです。myappのトップページのURLにはindexという名前がついています。この設定に基づき、以下の検索が可能です。

・If one of the instances is current - say, if we were rendering a utility page in the instance bar - myapp:index will resolve to the index page of the instance bar.

もしどちらかのインスタンスがカレントならば…すなわち、barインスタンスのユーティリティページをレンダリングしていた場合、myapp:indexはbarインスタンスのトップページとして解決されます。

・If there is no current instance - say, if we were rendering a page somewhere else on the site - myapp:index will resolve to the last registered instance of myapp. Since there is no default instance, the last instance of myapp that is registered will be used. This could be foo or bar, depending on the order they are introduced into the urlpatterns of the project.

もしカレントインスタンスが無い場合…すなわちサイト内の何か別なページをレンダリングしていた場合…myapp:indexはmyappのうち最後に登録されたインスタンスに対して解決されます。デフォルトインスタンスが無いので、登録されたmyappの内最後のインスタンスが使われます。fooでもbarでも、プロジェクトのurlpatternsに登録された順に依存します。

・foo:index will always resolve to the index page of the instance foo.

foo:index は常にfooインスタンスのトップページとして解決されます。

If there was also a default instance - i.e., an instance named myapp - the following would happen:

もしデフォルトインスタンスもあった（インスタンス名がmyappとなっていた）場合、以下のようになります。

・If one of the instances is current - say, if we were rendering a utility page in the instance bar - myapp:index will resolve to the index page of the instance bar.

もしどちらかのインスタンスがカレントならば…すなわち、barインスタンスのユーティリティページをレンダリングしていた場合、myapp:indexはbarインスタンスのトップページとして解決されます。

・If there is no current instance - say, if we were rendering a page somewhere else on the site - myapp:index will resolve to the index page of the default instance.

もしカレントインスタンスが無い場合…すなわちサイト内の何か別なページをレンダリングしていた場合…myapp:indexは、デフォルトインスタンスのトップページとして解決されます。

・foo:index will again resolve to the index page of the instance foo.

foo:index はこの場合もfooインスタンスのトップページとして解決されます。

---

和訳したけど正直なところイマイチピンとこない。
とりあえずインスタンスネームスペースの方がアプリケーションネームスペースより粒度が小さい…という解釈でいいのだろうか。

Glipperがエラーで落ちまくるのを直す

Ubuntu 12.04 preciseにしてからなぜかGlipperがエラーで落ちまくっていた。

単に再インストールしたら直った。

sudo apt-get remove glipper
sudo apt-get autoremove
sudo apt-get install glipper

あるディレクトリ以下のファイルの拡張子の一覧を取得するワンライナー

find -type f | sed -e 's/^.*\([\.|\/].*\)$/\1/' | sort | uniq

拡張子無しの場合はファイル名を出す。ような動きになるはず。

こういうの書くときsedよりperl使うようにしようかなー。
perlの正規表現の方がメジャーだし。
いい思い出ないけど。