Silverlight 1.1 Alpha はインストールできたのに、Refresh版がインストールできない。
なぜなのだろうとSilverlightのフォーラムで聞いてみたら、CPUがSSE(高速描画)命令セットを実装してないからだ、とのこと。
げべん。
CPU買い直しですか?
とすると、マザーボードもメモリもあわせて買わないかんとですか?
Silverlight 1.1 Alpha はインストールできたのに、Refresh版がインストールできない。
なぜなのだろうとSilverlightのフォーラムで聞いてみたら、CPUがSSE(高速描画)命令セットを実装してないからだ、とのこと。
げべん。
CPU買い直しですか?
とすると、マザーボードもメモリもあわせて買わないかんとですか?
I think rss feeds should always have language code, no matter what the Gengo setting is.
So, I made a patch.
Gengoのパーマリンク設定に関係なく、フィード(RSS)リンクには言語コードを必ず含ませたいと思い、パッチ作成。
Days before I experienced redirect loops when I tested the `tag search’ feature of SimpleTagging. I thought `Gengo should be worked something wrong.’ then I looked around Gengo’s setting pages and found that disabling `”Gengo should append language codes to permalinks automatically.’ feature could hide the problem.
Till today, I’ve killed off bugs in Gengo I’ve seen. I’ve got some knowledge of Gengo.
And finally I found `the solution’ to the issue.
open `Gengo Exclusions' page in admin panel, add "/tag" to `Exclusions' box.
Oh, yeah, the exact way is provided by the author.
ダウンロードリンクを貼り付けるのに便利な Drain Hole。
Gengo環境下でインストールすると get_currentuserinfo()関数は未定義 といったエラーが出るのでパッチ当て。
パッチファイルのダウンロード »
John Lam on Software: A first look at IronRubyを参考にIronRubyをインストール。
IronRuby-Pre-Alpha1.zipをダウンロードして適当なところに展開
IronRubyのビルドスクリプトBuild.cmdの中身を見る。
%frameworkdir%\%frameworkversion%\msbuild.exe /p:Configuration=Release /t:Rebuild IronRuby.sln
.NET Framework 2.0 Redistributableによって MSBuild.exe がどこにインストールされたか、エクスプローラで検索
見つかった場所を環境変数に設定し、ビルド
CD C:\src\IronRuby-Pre-Alpha1 SET frameworkdir=C:\WINDOWS\Microsoft.NET\Framework SET frameworkversion=v2.0.50727 build
以前、SimpleTaggingのタグ検索機能を使ったらリダイレクトループに陥ったことがあり、その時は Gengo との相性が悪いと判断して Gengo設定の「パーマリンクに言語コードを追加する」を無効にして逃げた。
今日まで Gengo のバグ取りをしてきて、ようやく回避方法を見つけられた。
なんだ、回避機能が標準で用意されてたんじゃん。
After activating SimpleTagging plugin I faced some problem. To avoid that I disabled the Gengo’s feature `Gengo should append language codes to permalinks automatically.’.
Days later I noticed a WordPress’ strange behavior.
I have pages having translations and when I clicked a link to the another language’s page then I saw a `404 Error’ page.
That’s strange.
Went further investigation I found a bad smelling code in the `locale’ filter.
One of the pair pages I faced 404 error have 3 depth hierarchy.
software/wordpress-plugins/l10n-helper.html <English> software_ja/wordpress-plugins/l10n-helper.html <Japanese>
Before modification the value of $value was set as:
wordpress-plugins/l10n-helper.html <English> wordpress-plugins/l10n-helper.html <Japanese>
$wpdb->posts.post_name only have a post name for 1 depth of hierarchy but the code got of 2 depth. And the code does not seem to care of WordPress feature that it allows to have same post name among pages while the top of ancestors of those page’s are not same.
I fixed the code to obtain the first part of uri.
It seems that Gengo cares WordPress’ cache feature a bit but not entirely.
I don’t know it comes from the fact that the cache feature is disabled by default.
Anyway there must be some bugs on it.
Past days I saw a kind of it on category listing then I gave away the category listing and replaced by SimpleTagging.
After that I noticed that there was similar thing on page listing. I couldn’t throw away this feature. I needed it.
The problem was that the page list block in the sidebar could be empty for all locales but the one visited firstly after cache feature had been enabled or cache for the page listing had expired.
I tried to fix the bug and have done.
I made a function gengo_list_pages(), which is to be replaced by wp_list_pages() in sidebar.php, in general.
<?php if (!function_exists('gengo_list_pages')) { function gengo_list_pages($args = '') { if (is_array($args)) { $r = &$args; } else { parse_str($args, $r); } $r = array_merge(array('language' => the_language(true)), $r); return wp_list_pages($r); } } ?>
There is also a related bug in the core code of WordPress 2.2.1.
SimpleTaggingプラグインとの相性の悪さから、Gengo設定の「Gengo should append language codes to permalinks automatically.」をOFFにしているが、この設定におけるGengoの不具合発覚。
l10 helperプラグインは英日2言語を用意しているが、一方のページから他方の翻訳版リンクをクリックすると404エラーが発生。おかしい。
調べてみると、localeフィルタ関数内でページ名からロケールを判定する部分に甘さがあった。
当該ページは英日ともに多階層構造になっていて、各相対リンクはこう:
software/wordpress-plugins/l10n-helper.html <英> software_ja/wordpress-plugins/l10n-helper.html <日>
上記変更前のコードで $value に代入される値はこう:
wordpress-plugins/l10n-helper.html <英> wordpress-plugins/l10n-helper.html <日>
$wpdb->posts.post_nameには1階層分しか登録されてないのに修正前は2階層取得してしまっている。さらに最初の階層(software/software_ja)さえ異なっていれば以降の階層では同一名が使えるようになっているWordPressの仕様も考慮されていない。
ということで、最初の階層部分のみを取り出すようにコードを修正した。
…あ、これはキャッシュと関係なかったか。