if (“0″) {
echo “真”;
} else {
echo “偽”;
}

これは「偽」と表示される。

$a = 'Test';
$b = $a;
$a = 'Change';
echo "b: $b"; // b: Test

参照渡し。

$a = 'Test';
$b = &$a;
$a = 'Change';
echo "b: $b"; // b: Change

function foo() {
    global $color;
    $fruit = 'SUIKA';

    include 'test2.php';
    echo "A $color $fruit\n";
}

for ($i=0; $i<100; $i++) {
    foo();
    echo memory_get_usage() . "\n\n";
}

test2.php

$color = 'green';
$fruit = 'apple';

test1.php を実行したとき、メモリが増加する。

メモリ増加の原因は、ダブルクォーテーション内の変数展開であった。関数内のincludeはメモリを増やさない事がわかった。

AddHandler application/x-httpd-phpcgi .php

とするのだが、CGI版のPHPを動かすということである。
しかし、CGIのPHPでも問題がある。

HTTPのレスポンスヘッダーが常に Content-Type: text/html としてしまう。

CGIのPHPでFireFoxを使って管理画面が崩れてしまうのは、このせいである。
この回避策として、load-styles.phpのみをモジュール版に戻すという手段もあるが、他の手段としてphp.ini を各ディレクトリに設置するということをする。記述は下記の通り。


cgi.nph = 1
default_mimetype =
default_charset =

しかし、次の条件の時はまだ足らない、

• セーフモード：オフでないとならない場合。かつ、
• レスポンスヘッダーがPHPで設定したContent-Typeでならないとき。かつ
• レスポンスヘッダーがStatus:304でならないとき。

このとき、なにが足らないかというとStatusが常に200となってしまう。
一応回避策はあって、

• 先頭行に、#!/usr/local/bin/php -q とする。
• アクセス権を755とする。
• .htaaccess でなどで該当ファイルを
  AddHandler cgi-script .php　とする。

でも、この方法は面倒だなぁ。

python 2.5インストール
http://blog.wiredeffect.com/archives/1198

python 本店
http://www.python.org/download/releases/2.6.4/
python 日本語
http://www.python.jp/Zope/download/pythoncore

trac日本語
http://www.i-act.co.jp/project/products/products.html

Mysql-Python
http://blog.srengine.com/2008/02/python-mysql-python.html

参考
さくらでtrac
http://weekbuild.sakura.ne.jp/trac/wiki/TracDoc/SakuraInternet

• 最新の投稿
• 固定ページ (以下を選択)
  • フロントページ:
  • 投稿ページ:

とあるが、まず、「最新の投稿」は読んだまま。
問題の固定ページを選んだ場合は、「フロントページ」「投稿ページ」は同じページは指定できない。

違うページを指定した場合、「フロントページ」はトップページを表示する。内容はPAGEで入力したコンテンツ。「投稿ページ」はPAGEで入力したコンテンツは無視される。投稿で入力した最新の記事たちが表示される。テンプレートはhome.phpを優先的に使用する。なければ、index.php。page.phpは使用されない。

photo credit: m.eckelberg

expected format ’3′ of repository found format ’5′

というエラーが出る。なぜだ〜？昨日まではでなかったのに。
まあ、原因究明ができなかったが、対処はできた。

エラーの内容は、formatつまり、バージョンが違うことらしい。
CoreServerは標準で、1.2のsvnが入ってる。そこに、ユーザーホームに1.6をインストールし、使用している。突然、1.6の使用が断たれたようだ。
.bashrc に svnへのパスを記述すれば良いとあちらこちらに書いてあるが、もちろん、そうなっている。以前から変更もしていない。

アクセスは「svn+ssh」を用いていて、sshがsvnserveを稼働させるようにしてある。
そこで、authorized_keyに

command=”/path/to/svnserve -t” シェルアクセスとは別の公開鍵の記述

を追加し、ホームディレクトリに設置してあるsvnserve 1.6 で稼働することを明示した。

クライアントはMacOSXである。クライアント側の.bashrcに $SVN_SSH 環境変数を下記のようにセットした

export SVN_SSH=”ssh -i /path/to/svn_rsa”

svn_rsa はssh-keygenで作成した秘密鍵のファイルである。シェルのアクセスと同じ鍵にすると、シェルアクセスがsvnserveを稼働させてしまいコントロールできなくなる。なので、別の鍵のセットを作成する必要があった。

あと、確実に秘密鍵を参照しにいくように、~/user_name/.ssh/configというファイルを作成し、そこに下記のように記述した。

IdentitiesOnly yes

この記述がないと、ssh-agentがサーバーに対し、１つの鍵を保持し、それを使いまわすようだ。シェルとsvnserveで鍵を使い分けができなくなり、不便な状態が続いてしまう。

これで、シェルによる、svnserveへのアクセスは可能になった。しかし、svnXというアプリケーションはこれでもformatのエラーをはく。.bashrcを認識しない模様。

そこで、~./subversion/configの[tunnel]のセクションに下記のように追加した。
ssh = $SVN_SSH ssh -i /path/to/svn_rsa -q
これで、svnXも使える様になった。最後の-qは「Killed by signal 15.」の非表示のための対処である。

次世代ブラウザ Firefox – 高速・安全・カスタマイズ自在な無料ブラウザ

Macだけではなく、OpenOfficeの日本語環境を強化する情報はこちらから。
Documentation/オープンオフィス3始める人のページ – OpenOffice.org_Document_Project_Wiki