InfoPath入門

 

何故か、ふと前のブログ消そうと思い立ちました。

どーせ誰も見てないし、結局大したこと書いてないし・・・。
んでもよく見たら１ページだけ異様なアクセス数のページがあったんです。
他のページのなんと80倍ｗ
（まともな記事がそれ一つで終わってたっていう理由もありますが）

ってことで、そのページだけこっちにコピーです。

 

ここから ----------

実は今お仕事で使用している議事録がとーっても見づらくて、
なんとか使いやすくできないものか、できれば他と連携とれないものか、
なんて思ってたんです。

そこで見つけたのがInfoPath。

・・・Word等はよく使うのに、今まで存在すら気付きませんでした。

とりあえずてきとーに触ってみてー・・・
なんて思ってたらちょっとややこしそうだったので、
調べてみたんです。

そしたら、
InfoPath – トレーニング
MicroSoftがトレーニング用のページを用意してたんですね。

これも初めて知りました・・・。

こんな便利そうなツールが存在してたんですね。
私が無知すぎるだけかぁ？？

便利そうといっても、あんましよく分かってないので、
一先ず利点を他人に説明できるくらいまで頑張らないと！

ここまで ----------

 

2009-06-13の記事です。

半年くらい経ちました。
何にも進んでません（汗）

あああああああ orz

Kernelブートイメージファイルの名前と意味 その２

 

その１でブートイメージファイルを沢山書きましたが、
宿題が結構残っていましたので消化しました。

 

まずはxipImage

xipImage
XIP(eXecute in Place)形式というやつで、
RAMへ展開せずに、極力そのまま使えるようにしたものらしいです。
NORフラッシュ等に余裕があるなら使えそうな形ですね。
今度試してみよう。

menuconfigで設定する人は、
”Boot options –> Kernel Execute-In-Place from ROM”にチェックを入れて、
”Boot options –> XIP Kernel Physical Location”にアドレスをいれる。

.config直接いぢる人は、
”CONFIG_XIP_KERNEL”をyにして、
”CONFIG_XIP_PHYS_ADDR”にアドレスを入れる。

んで、お仕事でも使用しているボードでコッソリと試して・・・

試し・・・て・・・・

動かないorz

どうやら、NORがByteアクセス出来ない為に、ちゃんと動かんのです。
まさか実験の為だけにH/W何とかしろなんて言えないので断念です。

 

お次はrImage

rImage
ramcopy形式とMakefileには書いてありました。
無圧縮の形で、とにかく仮想空間への展開だけしてるのでしょうか？
じつはちょっと動きが分からないので、宿題デス。
# 実際ブートローダからjumpしたら動かなかｔｔ

menuconfigで設定する人は、
”Boot options –> Kernel Uncompressed, RAMCOPY”にチェックを入れて、
”Boot options –> RAMCOPY Kernel source address”にアドレスをいれる。

.config直接いぢる人は、
”CONFIG_RAMCOPY_KERNEL”をyにして、
”CONFIG_RAMCOPY_SOURCE_ADDR”にアドレスを入れる。

こっちは動きました。
ほんとにそのまんま、コピーしてジャンプして動くシンプルな形です。

前回は、一先ずDRAMにイメージを展開して、それをLoadしてた為に、
CONFIG_RAMCOPY_SOURCE_ADDRと展開元アドレスが違ってたから、
うまく動かなかったってところですね。

シンプルなので起動速度は結構早いです。
uImageと比べると300msくらいは早くなった気がします。

 

・・・・msかよ！
って思われるかもしれませんが、今時の組み込みLinuxの起動時間は、
ms単位で縮めなきゃいけない状況なのですよ。

uncompressedなんでもちろん容量は大きくなりますが、
所詮はkernelなんで数Mの範囲ですしいいかな。

うん、起動時間とは逆にNORの容量がどんどん増えてきてるので、
kernelを極限まで小さく！なんてことはしなくても大丈夫になりましたねぇ。

 

ってなわけで、宿題消化！

autocmd

 

色々あって、久々の更新。

おかげでOpenSUSE11.2リリースした瞬間にインストールしたのに、
すっかり下記損ねてしまいました。

後で書くつもりです・・・。

 

さて、前回の宿題です。

autocmdは、”ファイルを開いた”とか”バッファから読み込んだ”とか
イベントに応じて自動実行されるコマンドです。

vim usersが好んで好んでやまない機能なようで、
検索すると色々と便利なコマンドが紹介されています。

バイナリデータを16進数表記する方法は、この記事に載っています。
# 使わせてもらいまーす、感謝です。

詳細な使用方法は、このドキュメントに載っています。

 

・・・・けど、個人的にはあまり必要ないなぁと思ってます。
# vim usersには申し訳ないが

私がviを使用する理由は、
・お手軽に使える
・動作が軽い
・Linuxなら必ず使用できる
てな感じなんです。

ちょこっとした用事や、急いでサクっと作業する際に使うので、
自分でカスタム出来るように勉強しても利点が少ないかなぁ・・・。

ここは少し甘えて、先人たちのリソースをありがたく使わせてもらおうと思います。
よさそーなコマンドがあったら紹介しますネ。

CUIのバイナリエディタ

 

Linuxで私の願いを叶えてくれるバイナリエディタを見つけたのでメモです。

 

Linuxにだって沢山のバイナリエディタが存在します。
KDEならKHexEdit、GNOMEならghexなどなど。

でも、私が知っていたのは全部GUIなんですよね。

組み込み開発なんかしてると、Debug用のUARTくらいしか、
Outputできるものが無いことが多いんです。

だから、viのbinary版みたいなものを探していたんですわ。

vimなら”vi –b”で開けばbinaryモードで開ける！！
なんてhelpには書いてありましたが、開いても化け化けで、
16進数表記じゃないんですもの・・・。

とはいえ、odやhexdumpじゃ見てるだけだし、
bviやhiといったフリーソフトはあるようですが、
できれば基本ソフトでなんとかしたい・・・と思ってたんです。

 

で、調べてみたら・・・

「vimならバイナリデータを16進数表記に変換できます」
ΩΩΩ < ナ、ナンダッテー！？

やり方は、”vi -b”(バイナリモード)で開いた後に、
:%!xxd
と打ち込めば変換できます。

元に戻す場合は、
:%!xxd –r
と打ち込めば戻ります。

xxdは16進数変換をしてくれるLinuxのコマンドです。

:%!は、バッファ全体を次に記述されたコマンドに渡し、
結果を反映させて表示しなおす機能のようです。

つまり、バッファ全体をxxdで変換して反映させるという動きなんですね。
表示方法が変わるのではなく、実際に書き換えちゃってます。

ってことでこのまま保存すると困ったことになりそうですから、
必ず元に戻す必要がありますね！

 

色々な方々が記事にしてましたので、ググってみると幸せになれます。

ちなみに、autocmd使えば楽になるよーっていう書き込みを見たのですが、
それほどvimを使いこなしてない私にとってはautocmd自体も？？？です。

ということで、後でautocmdなるものも調べなきゃですね。

 

記事書く度に宿題が増えてる気がするのは気のせいだろうか。

Kernelブートイメージファイルの名前と意味 その１

 

Kernelをbuildすると、最終的にvmlinuxというファイルができますよね。

これはもちろん、kernelをコンパイルしてLinkした結果で、
普通はELF(Executable and Linking Format)形式の、
デバッグシンボル等が付いてる形で出力されます。

これを各アーキテクチャで起動するように変換したものを、
ブートイメージファイルって呼んでます。

zImageとかbzImageなんて名前のファイルですね。

基本的には、実際に動作するプログラム部分だけ抜き出したbinaryに、
それを読み込んだり展開したりするプログラムをくっ付けた形のものです。

 

折角手元にARMアーキテクチャの開発環境がありますので、
Makefileなどを参考にブートイメージファイルの名前と意味を調べてみました。

・・・けど、いくつか分からない部分も出てきちゃいました。

宿題が残ってしまったので、今回はその１なんです。

 

 

zImage

gz圧縮されたイメージファイル。

解凍プログラム→解凍・展開→Kernel起動の順に動作し、
よく組み込みシステムで使われる。

 

bzImage

bzipで圧縮されてる以外はzImageと同じ。（はず）
i386用はこれが多いらしい？

でもopenSUSEって/boot/vmlinuzを読んでるよね・・・。

 

xipImage

XIP(eXecute in Place)形式というやつで、
RAMへ展開せずに、極力そのまま使えるようにしたものらしいです。

NORフラッシュ等に余裕があるなら使えそうな形ですね。

今度試してみよう。

 

rImage

ramcopy形式とMakefileには書いてありました。

無圧縮の形で、とにかく仮想空間への展開だけしてるのでしょうか？
じつはちょっと動きが分からないので、宿題デス。
# 実際ブートローダからjumpしたら動かなかｔｔ

 

uImage

u-boot用のHeaderが付いたイメージファイルですね。
bootmコマンド等で起動する際にはこのイメージを使用します。

ARMやPowerPCなどではお世話になる形式ですね。

 

xipuImage

xipImageのu-bootバージョンです。
これも一緒に試してみなければ・・・。

 

bootpImage

initrdを含む形のブートイメージファイルのようですね。

kernel2.6からはinitrdからinitramfsになったので、
古いシステムで使用できるように対応してあるの・・・かな？（汗）

正直使ったことないので、今度試すかな。

 

 

調べたのは以上！

残りや宿題はまた今度ー。

beagleを停止してみる

 

先日、aRtsが暴走していた時に、一緒にCPUを占有していた人がいます。
その名もbeagled。

beagleはmonoプラットフォームで動くデスクトップ検索で、
最近のLinuxは大抵はデフォルトで有効になってると思います。

googleデスクトップみたいなもんです。
# そー解釈してますｗ

idle時などにファイルやディレクトリのインデックスを付ける為、
一所懸命動き出すわけなんですが、マシンスペックによっては
結構重たく感じると思います。

VMwareで使用している方のOpenSUSEは、
基本デスクトップ検索なんて使わないというか・・・
grepで十分！なので止めてしまいました。

GNOMEであればコントロールセンターから検索設定を選んで、
チェックを全て外せば止まるはずです。

KDEでも同じような項目があるでしょう。(きっと)
# うちのノートに入ってるOpenSUSEはKDEだけど重くないし気にしてなーい
# 帰ったら見てみるか・・・

 

KDE4.1以上を使っていて、NEPOMUKを有効にしている人は、
beagleではなくてNEPOMUKを無効にすればそれで良いと思いますが、
わざわざ使用してる人のに分からないなんて嘆く人はいませんねｗ

NEOPMUK(Networked Environment for Personalized, Ontology-based Management of Unified Knowledge)
に関しては、セマンティックデスクトップの導入を図るNepomukとKDEを参照してください。

何故ここに書かないかって、私もデスクトップ検索機能以外よく知ｒ

熟読しよう・・・。

aRtsの暴走

 

VMware上でOpenSUSE11.1を動かしていると、
徐々に動作が重くなっていって、しまいにゃ止まってしまうことがあります。

なーんでかなぁ？と思って調べてみると、
artsdのCPU使用率が99%をキープしていました。

とりあえずkillするとカクカク状態から脱出できたので、
原因はartsdなんですが、なんで暴走して・・・・
あれ、なんで起動してるんでしょうね？

artsdはaRts (analog Real time synthesizer) のデーモンです。

こいつはKDEの標準サウンドサーバなのですが・・・
わたしゃVMware上のやつはGNOMEで動かしてます。
# だってGNOMEのが軽いんだもの
# Xfce? ナニソレ?

ということでESD (Enlightened Sound Daemon) が動いてて欲しいわけで、
aRtsが起動してる理由がサッパリ分かりませぬ。

一先ず、コントロールセンターのサウンドで、
・自動検出→ESD
・警告音と効果音→チェック無し
に、変更して様子見です。

 

ググってみると、同じ症状で困ってる人がそれなりにいそうなので、
もー少しつっこんで 調べれば分かりそうなものだけれど、
ゆっくり時間が取れたらみてみようかな。

VMware上のOpenSUSEなんて仕事でしか使わないしねぇ。
・・・なんて言ってると忘れそう（汗）

 

 

久々の更新。

嗚呼、udev調べないと中途半端だぁ。
忘れかけてたヨ。