link もっと前
   2008年 2月 6日 -
      2008年 1月 28日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

related プラグインの謎

Pukiwiki 1.4.7 に関連するページへのリンクを表示する related というプラグインがあります。リンクには二種類あって、
対象となるページにあるリンク(以降、順リンク)
対象となるページをリンクしたページへのリンク(以降、逆リンク)
が表示されるようになっています。

PukiWiki の編集時にブロック型プラグイン形式 #related か、index.php?plugin=related&page=PageName のように(便宜的に直起動と呼ぶ)して plugin を呼び出すことで上記の機能が発動します。

どちらの起動方法でも機能は同じ……そんなふうに考えていた時期が俺にもありました。
バキネタはさておき、related プラグインってば直で起動するとブロック型とは別の処理が走ってしまいます。そのせいで順リンクが出ません。なんだこれ。

Pukiwiki なんてそこら中で使われてるし、related の妙な動きにも誰か気づいていそうなもんですが…、そもそもどちらの動きが正しいんでしょう?それによっては以下のエントリが丸々無駄になる可能性があったりなかったり。

backlinks プラグイン

PukiWiki で「ひらメソッド」をやってみると、ある関数が誰を呼ぶか?という一覧の他に、ある関数が誰から呼ばれ得るか?ってのも知りたくなりませんか?

その手の情報は手動で管理すると死ねるので、逆リンクの一覧をページに埋め込むってのが欲しかったわけです。しかしながら #related では、先述したように順リンクが混ざってうまくないです。

related を直すとあちこちに影響が出そうなので、今のところは、以下の図のような対象ページの逆リンクだけをすっぱ抜いてくる backlinks プラグインを追加して凌いでいます。

backlinks.inc.php

<?php
// PukiWiki - Yet another WikiWikiWeb clone
// Backlinks plugin: Show backlinks for the page

function plugin_backlinks_convert()
{
	global $vars;

	return make_backlinks($vars['page'], 'p');
}

function make_backlinks($page, $tag = '')
{
	global $script, $vars, $rule_related_str, $related_str;
	global $_ul_left_margin, $_ul_margin, $_list_pad_str;

	$links = links_get_related_db($vars['page']);

	if ($tag) {
		ksort($links);
	} else {
		arsort($links);
	}

	$_links = array();
	foreach ($links as $page=>$lastmod) {
		if (check_non_list($page)) continue;

		$r_page   = rawurlencode($page);
		$s_page   = htmlspecialchars($page);
		$passage  = get_passage($lastmod);
		$_links[] = $tag ?
			'<a href="' . $script . '?' . $r_page . '" title="' .
			$s_page . ' ' . $passage . '">' . $s_page . '</a>' :
			'<a href="' . $script . '?' . $r_page . '">' .
			$s_page . '</a>' . $passage;
	}
	if (empty($_links)) return ''; // Nothing

	if ($tag == 'p') { // From the line-head
		$margin = $_ul_left_margin + $_ul_margin;
		$style  = sprintf($_list_pad_str, 1, $margin, $margin);
		$retval =  "\n" . '<ul' . $style . '>' . "\n" .
			'<li>' . join($rule_related_str, $_links) . '</li>' . "\n" .
			'</ul>' . "\n";
	} else if ($tag) {
		$retval = join($rule_related_str, $_links);
	} else {
		$retval = join($related_str, $_links);
	}

	return $retval;
}
?>

PukiWiki の plugin ディレクトリに backlinks.inc.php という名前で置いて、PukiWiki でページ編集するときに #backlinks と書けば動作するはずです。

PukiWiki のコード(make_related 関数)をそのままパクッてるんで、ライセンスは GPL です。こんなんで良ければご自由にどうぞ。

[編集者: すずき]
[更新: 2008年 2月 8日 19:09]
link 編集する

コメント一覧

  • IKeJI 
    related は他にもバグがあるんですが、Pukiwikiは死んでるんですかね?
    http://pukiwiki.sourceforge.jp/dev/?BugTrack%2F735 
    (2008年02月08日 10:58:57)
  • すずき 
    >IKeJI さん
    PukiWiki は最近バージョンアップしてないようですし、開発が停滞しているのかも知れないですねえ。
    >他のバグ
    ありゃーこれはかなりだめな挙動ですね。直さないのかな。

    #backlinks は大丈夫かな…?ダメだったら直すのメンドクサイなあ。 
    (2008年02月08日 18:22:31)
open/close この記事にコメントする



link permalink

最近のほっかいろ

会社の挨拶運動に参加しました。寒空の下 30分間、会社の入り口で「おはようございまーす」を連呼しました。

寒さを考慮してほっかいろを配ってくれたので早速使ってみたのですが、最近の製品は発熱量が少ないみたいです。かいろが暖かくなるどころか逆に寒さに負けて冷たくなってくる始末。低温火傷に配慮したのかなあ?それにしてはやりすぎだよなあ?

[編集者: すずき]
[更新: 2008年 2月 8日 03:01]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

キング・オブ・クソゲー

ちょっと前にニコニコ動画で大流行していた「チーターマン」という伝説級のクソゲーがあるんですが、これを越える超絶クソゲーがあります。

「未来神話ジャーヴァス」というファミコンのゲームなのですが、アクション RPG にも関わらず、説明なくゲームが始まって当然、てな作り方です。ターゲット層と思われる小学生に理解させる気ゼロです。

バッテリーバックアップカセット、クエストシステム、城攻めなどの斬新な要素(当時)も見られます。しかし基本が即死というバランスの悪さ、説明不足すぎて理解不能なクエストなどマイナス点が多すぎです。これは常人にはクリア不可能だと思われます。

ニコニコにクリアムービー(かなり省略されてます)が載ってたので、暇で仕方ない人は探してみてください。見ていても何してるのか全然わからんのが難点だけど…。

[編集者: すずき]
[更新: 2008年 2月 8日 02:55]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

らららープレイステーション

今日は飲み物を買いに行ったりしたくらいなので、昨日の晩〜深夜にかけて、友達とゲームしてた話でも。

PS3 のありあまるパワーを生かして、ハイビジョン画質(1080p 出力)をでかい画面(50インチのプラズマ)に繋いで、ガンダム無双やってました。ポリゴンのアラが見えてしまうくらい、綺麗だなあ。

Wiiiiiii!!!!!!!!

Wii でパワプロもやりました。リモコンを振って投げる/打つってのが楽しいです。最初はシンプルすぎる操作を見て、プレイヤーを馬鹿にしてると思ったんですが、やってみると逆にシンプルさが楽しいです。

ただ、PS3 やった後に Wii の絵をみると、ぼやけているというかなんというか…。やるなら逆の順番にしたほうが良さそう。

[編集者: すずき]
[更新: 2008年 2月 8日 02:43]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

スーキヤーキ

友人の誘いに乗って、京都の三嶋亭にすき焼きを食べに行きました。店の雰囲気に対して、ジーパン+トレーナーという僕らの服装が激しく場違いでした。あやうく周囲の視線で針のむしろになるところでした。個室で良かったと思います。

一食で一ヶ月の食費の半分くらいが吹っ飛びました。しかし…、うまかった…!

ジンジャー

食事を食べた後は京都の町をぶらぶら。京都のコンビニはみんな地味な色にしていて面白いです。街並みとの調和ってやつでしょうか。

近くの八坂神社にお参りしました。門の修復工事が終わっていたので、写真を撮りました。柱の朱が鮮やかです。今はまだ直したてで綺麗すぎるきらいがありますけどしばらくしたら良い味が出るでしょう。


八坂神社の正門前

神社にお参りしてお土産買った後は、パフェを食いました。男五人でな…、なんか最近こんなのばっかりだw

[編集者: すずき]
[更新: 2008年 2月 8日 02:34]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

そりゃないぜ

会社からの帰り道、電車の到着時刻を知らせる電光掲示板を見るとなんかおかしい。先に来るはずの 8分が、16分の電車の下に表示されています。普通は到着時刻順に並ぶはずです。


時刻順と逆に表示されている

そのまましばらく電光掲示板を見ていると、JR 西日本恒例の赤い文字(電車の遅れ時間を示す)が。またですか、もう勘弁してください。


どんどん遅れが増えていく

ああ、これはだめだって思ってたら「8分の普通電車は 16分より後になる」ってアナウンスが入りました。電光掲示板の順番が入れ替わってる=先行(8分の電車)は来ませんよ、って予告なんですねっ…て、わかりづらいよ。

最終的には 10分遅れになって、時間順で正しい順番になりました。結局ホームで 20分も待っちゃったYO!遅れの原因は、小動物を跳ね飛ばしたせいらしいです。へぇー。

[編集者: すずき]
[更新: 2008年 2月 8日 02:23]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

long long の罠

突然 printf の動きがおかしくなって、引数で与えた数値を表示したりしなかったりするようになりました。

で、調べてみるとこーんなプログラムになってたわけです。


#include <stdio.h>

int main(int argc, char *argv[])
{
  long long int a;
  int b, c;

  a = 0x1234567887654321LL;
  b = 200;
  c = 300;
  printf("a:%d, %s, b:%d, c:%d \n", a, "strings", b, c);

  return 0;
}

実行してみると

$ gcc a.c
$ ./a.out
Segmentation fault

見事に落ちました。

このプログラムのまずいところは変数 a は 8バイト(long long int 型)あるのに、printf には %d 書式(signed int 型の指定)と指示しているため、printf 側が 4バイトしか見ない、ってところです。残った 4バイトは次の %s 指令のデータと見なされて、その結果変なアドレスを見に行ってプロセスが死にます。

なので、この場合は %d じゃなくて %lld と書いて long long signed int 型であることを指定すべきです。正しく動いたときの結果はこんな感じ。

$ ./a.out
a:1311768467139281697, strings, b:200, c:300

整数だからといってなんでもかんでも %d にしちゃだめですよ、って教訓ですな。

$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -Wall a.c
a.c: In function 'main':
a.c:12: warning: format '%d' expects type 'int', but argument 2 has type 'long long int'

ちなみに gcc なら -Wall オプションを指定すれば、printf の書式指定が間違っていたときに教えてくれます。

the Typedef Hell!!

もちろん好きこのんでこんな状態を作ったわけではありませんので、お間違いなく…。

この問題に出会うきっかけとなったプログラムは、言うなれば「typedef 地獄」でしょうか。ぱっと見ても、整数なのか浮動小数なのか、はたまた構造体なのか…型が全くわかりません。何よりひどいのは typedef が連鎖しまくっていることでしょうか。

例えば A ライブラリの A_Type が B ライブラリの B_Type のエイリアスだったとして、その B_Type がさらに C ライブラリの C_Type のエイリアスで、それがさらに D の…というように、ひねりのない typedef が延々と続きます。

そのくせ最後まで辿ってみると無条件で typedef int X_Type;(単なる int)とかいうオチが多いので、ウザいことこの上ない。

やがて調べるのが面倒くさくなって、どうせ long か int だろって思ってなめてたら、long long int のエイリアスがいくつか混ざっていて、警告オプション -Wall もご丁寧に抹消されており、上記の問題にはまったわけです。

C 言語において、ダメなマクロの話は良く聞きますが、ダメな typedef の使い方はそうそうないと思う。

[編集者: すずき]
[更新: 2008年 1月 31日 23:42]
link 編集する

コメント一覧

  • hdk 
    型って難しいですね。昔は 16 ビットをこえる整数を扱うのに long int を使っていましたが、今は環境によっては 64 ビットになってしまいます。typedef を使うと、あとから変えるのは簡単になりますが、それはそれで読みづらい。printf みたいな変な関数が存在する C の仕様が古すぎるんでしょうか。(C++ の cout ならこの手のトラブルは起きないのかも...)
    # ちなみに x86 の 64 ビット環境なら上のプログラムはちゃんと動いてしまいますw 
    (2008年02月02日 01:02:39)
  • すずき 
    >hdkさん
    C のうまくないところは
    ・環境により int の大きさが変わる
    ・printf のような可変引数を取る関数がある
    ってところでしょうか。
    >typedef
    3連鎖以内に抑えていただければ幸せだったなー、と…(泣
    >64ビット環境
    64ビットなら問題ないっす。32ビットを想定ってのを書き忘れました。
    # そしてまた 64 -> 128 ビットの交代時に C 言語(きっと生き残っている)は同じ問題を起こすわけか…。 
    (2008年02月02日 03:17:56)
open/close この記事にコメントする



link permalink

食べるな、と来たか

大好きな蒟蒻畑をダイエーで 3袋くらい買ってきてもさもさ食ってたら、一瞬でなくなりました。しかも食べ過ぎて具合悪くなってきたし…。

それはさておき、蒟蒻畑の袋に「高齢者と子供は食べないで」というイラストが入っていることに気づきました。以前は裏側に「気をつけて食べて」とか「スプーンで食べて」という注意書きがあっただけだった気がします。


蒟蒻畑の袋

袋の表にしっかり描いてありますね。右下のマークの部分を拡大すると、以下のような具合です。


蒟蒻畑の袋、拡大図

食べるな、とはっきり描いてあります。喉に詰まらせる事故が起きる度にこの手の警告は厳しくなりますが、ついに注意や警告ではなくて禁止になってしまったようです。事故が起きまくる交差点が一時停止 -> 信号 -> 歩車分離へと進化する(?)のと似たような物か…。

[編集者: すずき]
[更新: 2008年 1月 31日 00:08]
link 編集する

コメント一覧

  • mama 
    歩車分離の次は・・・
    通行止め・・ってことはないですよね。www 
    (2008年02月01日 09:55:55)
  • すずき 
    最近の食品問題を見ると、不祥事を起こして販売取りやめってパターンも珍しくないです。起きて欲しくはないですが、次は「通行止め」ではなく「廃線」でしょうね。
    マンナンライフにはこれからも良い蒟蒻畑を作ってもらいたいです。いっぱい買うぜー。 
    (2008年02月02日 03:36:30)
open/close この記事にコメントする



link permalink

3倍速い

Java でプログラムしていたら妙な現象に気づきました。

  • Component.createImage か Component.createVolatileImage で大きめのバッファ(少なくとも 800x600 くらい?)を作ります。
  • バッファに何か(ここでは fillRect)描きます。
  • バッファの内容を Component に drawImage してコピーします。
  • 特定の待ち時間(11ms 〜 19ms)を指定した Thread.sleep を呼び出します。

以上の処理を行うループを回していると、PC の時計が 3倍くらいの速さでどんどん進んでしまいます。バッファに何も描かずに drawImage するであるとか、20ms 以上の時間を sleep に指定した場合には、問題ないようです。

バッファに描いて drawImage して sleep を呼んで待つ、というパターンはゲームでありがちな処理だけに困ってしまいます。何が悪いのかさっぱりわからない。Java とその内部に詳しい人が居たら、何が起きてるのか教えて欲しいところです。

それともなんだ、地球のために CPU パワーを食う Blit ではなく Flip にしなさいっておぼしめしなのか…?

検証コード

検証に使ったコードは以下の通りです。

TestClockSkew.java

import java.applet.*;
import java.awt.*;

public class TestClockSkew extends Applet implements Runnable {
    Image i;

    public void init() {
        i = this.createImage(800, 600);
        
        Thread t = new Thread(this);
        t.start();
    }
    
    public void run() {
        while (true) {
            Graphics g = i.getGraphics();
            g.setColor(new Color(0, 0, 0));
            g.fillRect(0, 0, 500, 500);
            g.dispose();
            
            this.getGraphics().drawImage(i, 0, 0, null);
            
            try {
                Thread.sleep(11);
            } catch (InterruptedException e) {
            }
        }
    }
}

当初は実際に動作するアプレットを貼りつける予定でした。しかし実行したところで、黒い画面が出るだけで何も面白くないうえに、もし皆さんのマシンの時計が狂ったりしたら大迷惑なのでやめました。

[編集者: すずき]
[更新: 2008年 2月 15日 01:07]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

遅くたって枯れたって馬鹿にはできない

どこの会社もそうだと思いますが、情報漏洩対策で USB メモリだの CD-R だのといった記録媒体を会社内に持ち込むことは原則禁止されています。

普段はそんなこと気にならないのですが、PC の再セットアップの際にイーサネットカードのドライバが見あたらないとき、非常に困ります。別のマシンから持ってこようにも、移す手段がありません。

今日まさにその状態にはまってしまって困ったんですが…。窮地を救ったのはシリアルポートでした。

Windows にはハイパーターミナルという素敵ソフトが大抵入っていて、そいつを使うとシリアルポート経由でファイルを転送可能です。Linux などの UNIX 系 OS でもシリアルポート経由でファイルを送る手段はあるはずです。

速度はせいぜい 115.2kbps(14.4KB/s)で、けして速いものではありませんが、シリアルポートさえあれば必ず使えるので助かります。おおよそどの OS にもドライバがある、というのは枯れきったデバイスたるシリアルポートの利点でしょうねえ。

しかし最近のノート PC などはシリアルポートが無いものも多いし、この手段も廃れつつあるのかな…。

[編集者: すずき]
[更新: 2008年 1月 28日 22:40]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2008年 2月 6日 -
      2008年 1月 28日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 11/14 02:08

カレンダー

<2008>
<<<02>>>
-----12
3456789
10111213141516
17181920212223
242526272829-

最近のコメント 5件

  • link 18年10月12日
    すずき 「なるほど!\n京急、京成はヤバそうですね...」
    (更新:10/15 23:02)
  • link 18年10月12日
    ちかふみ 「閉会式直後の出国ラッシュ対策のためだそう...」
    (更新:10/15 20:43)
  • link 18年10月12日
    すずき 「あー、なるほど!閉会式の次にくっつけたん...」
    (更新:10/14 15:44)
  • link 18年10月12日
    hdk 「2020年の東京オリンピックが8月9日ま...」
    (更新:10/14 10:45)
  • link 18年09月07日
    すずき 「ありがとう!\nこちらこそ、楽しみにして...」
    (更新:09/11 19:30)

最近の記事 3件

link もっとみる
  • link 18年11月13日
    すずき 「[お気に入りのマンガ] Kindle Fire HD は大量の本を...」
    (更新:11/14 02:08)
  • link 18年11月10日
    すずき 「[ROCK64 の I2S が動かない] 先日(2018年 7月 ...」
    (更新:11/14 01:53)
  • link 18年11月11日
    すずき 「[linux-next で動かない ROCK64 の I2S] 昨...」
    (更新:11/14 01:52)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報