鯖移行後tdiaryが絶不調
挙動を監視すると、
とりあえず、tdiaryを安定板から開発版に差し変えてみたけど状況は変わらず。
tdiaryのスタイルを自作のにしているせいかとも思ったが、デバッグ出力をしてみた所、そこは問題ではないようだ。
問題を切り分けた所、特定の日付の日記を画面に描画しようとすると再現するようだ。
とりあえず、過去ログを退避。
今自宅で使ってるサーバーはまる三年ほど使っています。
いろいろガタがきてきたので、再セットアップしました。
今度はFreeBSD 8.0です。
差し当って入れたパッケージは以下の通り。
移動し忘れとかで消えてるページとかあったら教えてください。
家の家電を制御するのが(IKeJIの近くで)大流行中らしいので、俺も俺もという事で、
RD-H1を制御すべくデバイスを作った。
後は宅鯖のFreeBSDから制御するだけ。
とりあえず差してみる。
> dmesg (中略) uhid0: ikejima.org SendIr, rev 1.10/1.00, addr 2, iclass 3/0
認識はされてそう。
> usbdevs addr 1: UHCI root hub, Intel addr 1: UHCI root hub, Intel addr 1: UHCI root hub, Intel addr 2: SendIr, ikejima.org
こっちも。
いろいろ調べてみると、各USB-HIDデバイスは "/dev/uhid[n]"に置かれるっぽい。
今回自分が作ったHIDデバイスは送りたい機器コードとボタンコードを送るだけ。
Rubyを使ってこんなかんじ
> sudo ruby -e 'open("/dev/uhid0","r+"){|w| w.write [0x45,0xbc,0x12,0,0,0,0,0].pack("C*");}'
これでとりあえず、コンソールからUSB機器を操作できました。
しかし、/dev/hid0のパーミッションがrootでないと操作できなくなっているため、devfsの設定を変えます。
パーミッションをむやみに開けるのは危険。
この場合、自宅内にある全てのリモコンで操作可能な機器が乗っ取られる可能性がある。
まず、設定ファイルを作る
[localrules=10] add path 'uhid*' mode 0666
次にこのファイルを有効にする設定を書き足す
devfs_system_ruleset="localrules"
で、再読み込み。
> sudo /etc/rc.d/devfs restart
これで誰でも使える。
hidデバイスが増えると、/dev/uhid0じゃなくなるかもしれない。
usbdevsコマンドでデバイス名がわかりそうなので、これを使えるようにする。
> usbdevs -d -o addr 1: UHCI root hub, Intel, device uhub0 addr 1: UHCI root hub, Intel, device uhub1 addr 1: UHCI root hub, Intel, device uhub2 addr 2: SendIr, ikejima.org, device uhid0
Linuxで、これをどうやるか知りたい。
HHK Lite2がショートし故障した件について。
先週、秋月のLCDをATTiny2313で制御したんだけど、
これに問題があった。
これは ElmさんのソフトウエアUSART を使って制御してたんだけど、
これだと画面リフレッシュ中にデータを受信しても表示できない。
割り込み使うように書き変えれば動くんだろうけど、
シリアルまわりを書き変えるなら、ハードウエアシリアルを使うよ、
っていう訳で書き変えはじめた。
シリアルを使う(ちゃんとした)ソースはやねうらおさんの所にあったのを流用。
送信受信で分けて使えるのがいい。
受信しか必要ないのと、もうちょいバッファーがあった方がいいかと思って、
バッファサイズを倍にした。これでメモリがギリギリ。
で、一週間ぐらいはまってた。
症状は、なんかデータが化ける。
送信をしたタイミングで化けたデータが届くので、配線ミスじゃなさそう。
また、毎回同じように化けるので、ノイズ系でもなさそう。
レートが間違い？と思っていろいろ試してみるも駄目。
結論から言うと、シリアルの極性が間違ってた。
前回試したElmさんのソフトウエアシリアルだと、PCに繋ぐと仮定して、
極性を設定していたみたい。
AVRの方は正極性で出てた。
ネットで調べると、MAX232系を繋ぐのが一般的だけど、
そんなの手元にあるかい!って感じだったのと、
極性を反転させるだけなら、トランジスタだけで良くね？
と思っていたら、CDC-2313のページに接続例が乗っていました。
http://www.recursion.jp/avrcdc/cdc-232.html#schematic
これを試してみると、ビンゴ!
これで高速に入力しても取りこぼしなしで行けました。
ソースはこの辺に置いておきます。
http://dev.ikejima.org/src/svn/avr/monitor-lcd/
公式サイトで使っていたTracのsqliteデータベースから、データを取り出してみました。
コピペで。
http://ikejima.org/wiki/pragger/
とりあえず、もっとドキュメントを追加しようと思って、項目名だけ作った。後は知らない。
秋葉原に行って、LCDを買ってきた。
これ -> http://akizukidenshi.com/catalog/g/gP-02919/
どう見てもかっこいい。バックライト付きなのに800円で買える。
とりあえず、ATTiny2313をつけて表示させてみた。
2313は100円で買えるのでじゃんじゃか使えていい。
時間がかかった点は
とりあえず"BABEL"と連続で書かれるようにしてみた。
シリアルで送った文字列を画面に書けるようにするつもり。
USBシリアルを実現するためのUSBプロファイルであるCDCはある程度の容量を持つチップを要求する。
でも、できれば安いチップですませたい。
探すとむりやりやっている人がいるみたい。
ただ、やっぱりCDCを直接できなくて、フィルタドライバをインストールしてる。
http://www.recursion.jp/avrcdc/cdc-232.html
CDCを使えるようにドライバを入れるとなると本末転倒な気がする。
そこで、インストールが面倒という点を回避するためにHIDクラスでデータを送って、
それをシリアルで出力するという方法はどうだろうか？
既存のCOMを開くタイプのアプリケーションでは使えないが、
PC側のアプリケーションを自作している場合は簡単な変更で使えるし、
DLLフックとかで何とかできそうな気もする。
Gainerとかを使っている方を見ると、どのCOMポートにGainerが接続されているかわからなくて困っているように見える。
Gainer x processingだと、1から順番に試すみたい
その問題もWindwosのHIDAPIだとプロダクトIDがわかるので解決できる気がする。
やりかたがわからなかったのでメモ。
PraggerではSubversionを使っていました。
レポジトリのバックアップは手元にあります。
旧サーバーでは、プロジェクトごとに別れたレポジトリを持っています。
新しいサーバーでは、一つのプロジェクトに各コンポーネントのディレクトリを掘って、そこに置いています。
http://dev.ikejima.org/src/svn/
ここにPraggerというディレクトリを作って、ここにPraggerを置こうと思いました。
すぐに思いつく単純な方法は旧レポジトリからファイルを取り出し、新レポジトリにアップロードする事です。
ただし、この方法ではファイルの変更履歴が移動できません。
svn mergeを使って、一つ一つコピーする方法もある。
svn merge -c 0 <oldrepos> svn ci -m "hogehoge" svn merge -c 1 <oldrepos> svn ci -m "fugafuga"
これもメンドイ
これが正解っぽい。今回のような場合、--parent-dirを使うのが良いようです。
svnadmin dump <oldrepos> > dumpfile svnadmin load <newrepos> --parent-dir <project name> < dumpfile
これでPraggerのレポジトリが復活しました。
http://dev.ikejima.org/src/svn/pragger/
また、praggerのサイトが落ちたままだという報告がされている日記を発見してしまいました。
さくらインターネットに yapra をいれたよ
そろそろ何とかしたいところ、データというかSubversionのレポジトリはディスクからサルベージュ済み。
そろそろ復活させたいんですが、プロジェクト管理ソフトは何にすべきか悩んでいます。
http://trac.edgewall.org/
落ちる前のPraggerのページはTracで動いていました。
そもままTracを設置するというのもあり。
ただ、Pythonが嫌いなままなのに、Tracを使っていていいのかという問題が残ります。
良い点
Railsのものよりサクサク動く気がします
ユーザー数が多い、プラグインが多い
悪い点
プロジェクトごとに一つインストールする形になる
http://www.redmine.org/
Rails製のものに乗り替えるなら、Redmineが一番有名っぽいです。
良い点
Railsなのでカスタマイズできるかも
悪い点
デザインが社内向けっぽい
http://retrospectiva.org/
Redmineと人気を二分するRetrospectiva。
これもRails製
Blog機能が特徴なのか？
アクセス制限が弱い気がします。特定のプロジェクトだけログインしないとソース非公開とかできないような。
良い点
名前がかっこいい
Railsなのでカスタマイズできるかも
悪い点
開発者が少ない？
管理は楽だよね。
どうしよう？
2,3日しかさわってないですが、ハマった所を書いてみます。
Cygwin版のGit+svnを使っているとglob.dllのエラーで起動しない事がありました。
C:\cygwin\lib\perl5\5.10\i686-cygwin\auto\File\Glob\Glob.dll to same address as parent(0x8C0000) != 0x950000
下のページから引用。だってもう出ないんだもん。
次のページによると、他のCygwinプロセスを終了後ash rebaseallを実行すればいいらしいです。
http://hylom.net/develop/090120-cygperl-rebase.html
自分の場合、perl.exeが生き残っていてはまりました。
> cd C:\cygwin\bin > ash rebaseall
Subversionより1レベル多いので混乱します。
Subversionでは、変更してコミットしますが、Gitでは、変更してステージングしてコミットします。
それぞれ元に戻すのに別なコマンドがあります。
Git statusコマンドを実行すると、どうすればいいか出る物もあります。
Gitコマンドまとめページにまとめます。
今まで、自分関連の開発にはSubversion + svkを使っていたのですが、
svkは 開発終了が宣言されてしまいました。
変わりを探していたのですが、まわりの人が話題にしているgitのSubversionサポートが結構充実しているらしいので、
これを試してみる事にしました。
また、gitを使う事で、svkに対する不満が解消できないかな、と思ったので、これも試してみました。
ubuntuで試したので、git、git-svnパッケージをインストールしただけ。
まずはSubversionのサーバーからクライアントにチェックアウトします。
Svkとは違い、クライアントを作るのも一緒にやってくれます。
% git svn clone --prefix=svn/ -s http://dev.ikejima.org/src/svn/pakiwiki Initialized empty Git repository in /home/ikeji/git/pakiwiki/.git/ Using higher level of URL: http://dev.ikejima.org/src/svn/pakiwiki => http://dev.ikejima.org/src/svn r43 = 5285ee0469c452815ced70b9bc03d7d5b68d3e9b (svn/trunk) W: +empty_dir: pakiwiki/trunk/pakiwiki (中略) r263 = 7025f68b6a841a811dce1a19beed780a497a3c16 (svn/trunk) Checked out HEAD: http://dev.ikejima.org/src/svn/pakiwiki/trunk r263
まず、適当にファイルを変更する。
コミットはまずローカルにする。
% git add diff.rb % git commit Created commit 5ec07a4: Fix test: rename duplicated test name. 1 files changed, 1 insertions(+), 1 deletions(-)
addしてからcommitするのがポイントらしい。
addは新しいファイルでなくても必要。次にcommitをした時にコミットする予定のファイルリスト(ステージというらしい)に入れる。
ここはSubversionと違うので注意。
% git svn rebase
Current branch master is up to date.
% git svn dcommit
Committing to http://dev.ikejima.org/src/svn/pakiwiki/trunk ...
M pakiwiki/plugin/diff.rb
Committed r264
M pakiwiki/plugin/diff.rb
r264 = 3d65af54244ce374ae634fa08b0d6021bb85278e (svn/trunk)
No changes between current HEAD and refs/remotes/svn/trunk
Resetting to the latest refs/remotes/svn/trunk
rebaseでサーバー側でされた変更をローカルに取り込む。
この時点で変更がローカルに反映される。
gitの重要な機能を全然使いこなせてない気がするけど、とりあえずsvkのかわりにはななってる気がする。
さて、svkで主な不満の一つであった衝突解決だけど、gitでは一応の解決がされている。
同じファイルをローカルで2回、サーバーで1回編集した場合、
svkでは、2回マージしなくてはならない。
gitでは、1回目のマージ結果を見て、2回目のマージはより自動的にやってくれるっぽい。
これだけでもsvkを捨ててgitを使う意味がある気がする。
gitにはbisectというコマンドがある。
これは、あるバグがいつ発生したかを特定するコマンドだ。
明白にある部分からバグが発生したかわかれば良いのだけど、わからない場合も多い。
bisectは二分探索をして自動的にバグがどのコミットで生じたかを判別する。
すげー
昨日imeemの事を書いていて、そういえば、imeemについて調べてどこかにメモを残した気がするな、
と思ったんですが、そういえば、昔P2PWikiというのをやっていました。
検索した所、公開は2005年7月1日のようです。
はてブ無印吉澤さんの日記yomoyomoさんの日記
P2PWikiは卒論を書くべく色々調べていた頃、せっかくなので調べた結果をまとめるサイトがあればいいなと思い作りました。
嘘です。今考えました。
他の技術系Wikiは国内では、osdev-jがあり、かなりの情報がまとまっていました。
残念ながら今現在は動いてないようです。 http://wiki.osdev.info/
しかし、osdev-jはその名の通り、OSを自作しようぜ、という事をベースに集められている情報なので、
どちらかというと足周りの情報が多い気がしました。
せっかくなので、ネットワーク技術についてのWikiサイトがあればいいな、というのがP2PWikiをはじめた理由だと思います。
osdev-jとおなじく、P2PWikiも、ikejisoft.comのディスクエラーの後、そのまま放置したままでした、
せっかくなので、思い出しついでにディスクからサルベージュしてみました。
http://p2p.ikejima.org
元はPukiWikiを使っていましたので、PukiWikiからPakiWikiへの変換をするスクリプトも作ってみました、
と言っても、ファイル名と文字コードを変換しているだけですが、、、
さて、探していたimeemに関する情報ですが、実はほとんど書いてなかったのを発見しました。p2p:imeem。残念。
_ 斎藤ただし [> どうしよう 一番気が向いて、楽そうなのでおk。]
_ donbulinux [ただのメモのような記事を拾ってもらった上に、復旧をせかしたような形になってスミマセン(´д｀；) が、なにはともあれ..]