NEST

ホームディレクトリのパス

ターミナルというかコンソールというか。
unixファミリーのOSだと、
cd ~

とか、
ls ~
ってやると、

ホームディレクトリになんかかんか出来るのだと思う。

まあ、linuxとOS Xしかお知り合いじゃないんだけど。

cocoaなことをしているときに

これを応用出来ないかと思った。

要するに

NSString* home = [@"~" stringByExpandingTildeInPath];

みたいな。

久しぶりに書いたと思えばなんと短い。

ファイルのサイズ

あるディレクトリの奥の奥の奥にある。

そんなファイルをロードしたい。

初夏の夜。

ファイルサイズを取得して、

そのぶんだけメモリを確保。

んで、そこにむいてファイルから、

リードリードリード。

オーバーフロー！！

ん？なんでだろ。

処理を極限まで減らす。

ファイルから読み込みを無くした時点で、

エラーは出なくなる。

読み込みがやっぱ悪い。

んー。ファイルサイズで取得した分しか、

ファイルのサイズはないわけなんで、

教えてもらったファイルサイズだけメモリを確保すればいいはず。

ちなみにファイルサイズを知る方法。

NSDictionary *result = [manager attributesOfItemAtPath:path error:&error];

で得たDictionaryにはfileSizeってイベントを送ってもいいらしいんですな。

unsigned long long resultSize = [result fileSize];

さて。エラーのおこるやつ。

ファイルサイズなんぼじゃ。

/Users/dev/Documents/backup/dmGet/build/Debug/dmGet.app/Contents/Plugins/ITunesCommunication.plugin/Contents/Resources/lib/python2.6/site.py

こんなおくのおくのおくにあるファイル。
枠からはみ出ているだろうが気にしない。

サイズは13。

そんなばかな。

site.py書いたの私だけど、13文字で書いた覚えは無い。

Finderで調べると、3042。

おっとー？

ファイルサイズの別の求め方として、

cの標準関数が使えるのならば。

前にlinuxでなんかを書いたとき、

statとかを使った気がする。

struct stat buf; /* ファイル情報の格納領域 */

size_t debug = 0;

if ((stat([path UTF8String], &buf)) == 0) {

debug = buf.st_size;

}

まあ、ちょいとこんな感じで。

で、どうなったかというと、

＊attributesOfItemAtPath:error:の結果＊

2010-06-12 23:12:57.672 crepe[44602:903] image:14df5b30 size:13 pt+n:14df5c30 name:/Users/dev/Documents/backup/dmGet/build/Debug/dmGet.app/Contents/Plugins/ITunesCommunication.plugin/Contents/Resources/lib/python2.6/site.py

Current language: auto; currently objective-c

“result”の説明を出力中：

{

NSFileCreationDate = "2010-05-01 21:15:52 +0900";

NSFileExtensionHidden = 0;

NSFileGroupOwnerAccountID = 20;

NSFileGroupOwnerAccountName = staff;

NSFileHFSCreatorCode = 1919443312;

NSFileHFSTypeCode = 1936485995;

NSFileModificationDate = "2010-05-01 21:15:52 +0900";

NSFileOwnerAccountID = 503;

NSFileOwnerAccountName = dev;

NSFilePosixPermissions = 493;

NSFileReferenceCount = 1;

NSFileSize = 13;←＊＊＊ここ＊＊＊

NSFileSystemFileNumber = 2854447;

NSFileSystemNumber = 234881026;

NSFileType = NSFileTypeSymbolicLink;

}

うそつき。

＊statの結果＊

デバッガで見た。

debugの値は3042。

正解。そのとおり。

なんなんかなぁ。

わたし、なんかしたっけかなぁ。

とりあえず、statで問題をよけるぞ。

stringWithCString

すでになにか別の処理で、

テキストファイルからテキストをメモリに読み取ってあるのなら、

stringWithCString:encodingを使えば、

そのメモリ領域にあるデータからNSStringを作成できると思った。

私の場合、encodingについては既に割れているので、

それを引数にstringWithCString:encodingを使う。

らくちんぽん。とおもいきや。

UTF-16でどうもうまくいかない。

ん？こいつどうやってUTF-16の終端を判断してるんだ？

とおもった。

長さを渡していないので、

終端を表す何かが必要なはず。

UTF-16でASCII文字を使うと、１バイト分データの空きが出る。

そう。そこはヌル文字。

なので、ほかの文字列と同じようには

UTF-16ではヌル文字で終端を表せない。

２バイト連続ヌル文字を使えばいいのだろうけど、

そんな話は聞いたこと無い。

ちなみにやってみたけど駄目。

unicharの配列だと可能だろうけど、

stringWithCStringはふつうにcharの配列を受け取るから。

もし、stringWithCString:encoding内部で、

ヌル文字を終端として扱っているなら、

このメソッドではUTF-16は扱えないように思えた。

そんななかにもかすかな光が。

stringWithCString:length:は長さが指定できる。

そして、試したところBOM無しのリトルエンディアンUTF-16も

同様にBOM無しのビッグエンディアンUTF-16もちゃんと読み込めた。

ん？Deprecated in Mac OS X v10.4？

あ。自分、英語読めませんのですいませんが。

なんか光が消えた。

そんななかにもかすかな光が。

stringWithCharacters:length:というメソッドがある。

引数にconst unichar *と長さが渡せる。

もう。いかにもいけそうな予感。

結論から言うといける。

ビッグエンディアンなら。

リトルエンディアンのときはBOMをつけてもだめ。

んもー。またぐちゃぐちゃ。

あー。なんならスワップしますけど、します？

またもや、そんななかにもかすかな光が。

initWithBytes:length:encoding:というメソッドがあった。

長さもエンコードも指定できる。

ええんよ、ええんよ。

どっちもわかってるから。

ちゃんと動いてくれれば。

．．．

動いた！

えっと。クラスメソッド版は無いんですね．．．

allocしなきゃだめですか。

そうですか。

rangeOfString:options

ある意味で、ある文章から特定の文字列を

抜き出さなければならないという仕事は、

いつだってある仕事なのだと思う。

従って、「ある意味で」という言葉を文書から検索し、

その位置を導きだすこというサンプルは、

ある意味、非常に有益だと思う。

管さんはある意味でを使い過ぎらしい。

ある意味で。

これまで、なんか重い話題が続いたので、

ある意味ちょっと息抜きで。

レッツrangeOfString:options。

第一引数で検索したい文字列を指定。

私の場合、@"ある意味で"。

第二引数はオプション。

実際はunsigned int。

オプションは適宜指定で。

まずは無しで検索してみたいの私は0で。

戻り値のNSRangeはlocationとlengthを持つ構造体。

NSLog(@"location : %d length : %d", range.location, range.length);

とかやれば値が見れる。

locationは先頭の文字を0として、

多バイト文字でも文字数で何文字目か出してくれる。

lengthも文字数。

私の場合、「ある意味で」が２回登場するので、

もう一回やる必要がある。

ふつう２回出る、なんて知らないので、

do whileで回す必要がある。

そんなとき、rangeOfString:options:range:。

第三引数で、残りの部分を指定してやればいい。

range= NSMakeRange(0, 0);

result = NSMakeRange(0, 0);

{

range.location = result.location+result.length;

range.length = [base length] - (result.location+result.length);

result = [base rangeOfString:@"ある意味で" options:0 range:range];

if(result.location != NSNotFound)

NSLog(@"location : %d length : %d", result.location, result.length);

}while(result.location != NSNotFound);

オプションについてはunsigned intなんで、

cのノリで

NSCaseInsensitiveSearch | NSLiteralSearch

とかしちゃえばOK。

例えばこんなオプションがありんす。

NSCaseInsensitiveSearch

大文字小文字を区別しない。

NSLiteralSearch

これを指定した場合、byteをみて比較する。

例えば、UCS2で3071,306F,309Aとした場合、

それは"ぱぱ"となる。

3071が"ぱ"。

306Fが"は"。

309Aが"゜"

"ぱは゜"ではなく、だいたいちゃんと"ぱぱ"と表示される。

このオプションを指定すると、

3071の"ぱ"で検索した場合、

306F,309Aの"ぱ"で引っかからなくなる。

NSBackwardsSearch

終わりから検索。

エディタの"前を検索"を実装するときに使うんだろうなと。

NSAnchoredSearch

先頭しか検知しない。

（NSBackwardsSearchのときは最後）

NSNumericSearch

文字列に含まれる数値で比較。

たぶん、compare:optionsとか使うときに使う。

NSDiacriticInsensitiveSearch

発音区別符号無視。

無視すると、'ö’は‘o'で検索に引っかかる。

試してないけど。

NSWidthInsensitiveSearch

全角ａが半角aとマッチするようになる。

半角aもまた全角ａとマッチするようになる。

NSForcedOrderingSearch

compare:optionsとかで使えるんだと思う。

こいつは言ってることがよくわかんなかった。

NSCaseInsensitiveSearch指定で"aaa"<"AAA"らしい。

NSCaseInsensitiveSearchとNSLiteralSearchが大事なんだと思う。

retain

キューを作って、実際使ってみた。

なんかデータを入れようということで、

NSDateとintを持つクラスを作り、

そのオブジェクトをキューに放り込んでみた。

で、取り出す。

放り込む人が５スレッド。

取り出す人が３スレッド。

ばらばらばらばら。

ログが入り乱れる。

放り込んだときと、

取り出したときにNSDateとintの内容を表示する。

で、取り出したとき、280個目あたりで落ちる。

どうも、NSDateの内容が無効になっているみたいだった。

気づくのにだいぶ時間がかかってしまった。

[NSDate date]で

かえってきたインスタンスをそのまま使っていたのが

まずかったんだと思う。

retainしてなかったんだな。

retainは大事だと思った。

何も考えず、とりあえず、ざっと作ったキュー。

頼りない感じだけど、

こんな感じでいんじゃね。

と、おもわれ。

できたてほやほや。

もうちょっと試さないといかんね。

ロック

ロックをしたいとき、

どんな方法がとれるのか調べてみたけど、

以下の３つからどれにしようかといったところ。

・@synchronized

・POSIX mutex

・spin lock

なにも考えずにやりたい場合、

普通は@synchronizedでやればいいんだと思う。

POSIXのmutexも特になんも考えなくていいと思う。

spin lockはなんか、もっと低レベルの仕組みなんだと思う。

ドライバ書いたりする人はこんなの使うんでしょ。

ちょいと調べる限り、

ロックで待ってる間はビジーループで回るとかなんか書いてあるけど、

最近の実装じゃ、もっとうまいことやるでしょ。

きっと。

ほかのスレッドにCPU渡したり。

spin lockは実際に使わないと思うけど、

実験だし使ってみる。

計測計測。

ロックかけて

インクリメント

ロック外す

を10000回まわしてみる。

インクリメントすらスレッドセーフではない世の中。

何を信じればいいのか。

阿弥陀様を信じればいいと思うよ。

さて。計測計測。

一応すべての方法で、ロックがうまいこといくのは確認。

ロックなし

大体 0.035ms

@synchronized

大体1.84ms

POSIX mutex

大体0.65ms

spin lock

大体0.29ms

10000回連続でロックとアンロックをやってるので、

なんとかテクノロジ的なもので、

２回目以降は速くなるのかもしれないけど。

一回あたりのロックは

@synchronizedでも計測する意味が無いレベルだと思う。

とりあえず、

普通に使う分ではどれでも問題ない気はした。

すくなし、

@synchronizedなんて遅くて使えないよー。

なんてことは、いわないと思う。

@synchronized

クリティカルセクションを作る、

っていうときに、

@synchronizedはとても便利だと思う。

@synchronized(self)

{

for(int m=1 ; m<=5 ; m++)

{

NSLog(@"ID:%d SPEAK %d", threadID, m);

}

なんていう例は、

どこでだって見れるけども、

@synchronized(self)っていった場合、

そのメソッドがいくつかのスレッドから、

呼び出されることを想定しているんだと思う。

まあ、スレッドをつかってごにゃごにゃと、

この間からやってわけなんですが。

私のやつは、

スレッドごとにオブジェクトを一つ作成し、

そのオブジェクトに対してメッセージを送ることによって、

スレッド上の処理を動かす。

っていう感じになっているんだけども。

こんな動き方はすごいと思った。

あるスレッドで作ったオブジェクトは、

ほんとにそのスレッドに乗っかってるんだもの。

NSConnection経由でメッセージが送れる。

で、そんな感じのつくりだと、

@synchronized(self)

なんて無意味であることがわかる。

実際無意味だったし。

私のNSObjectを継承するクラスからうまれた、

かわいいインスタンスオブジェクトは

@synchronizedを意識した実装などしていないので、

この鍵はNSObjectがもっているはず。

なので、スレッドのファクトリで、

NSObject *lockObject

をもっておいて、

スレッドを作る際に渡しておく。

で、鍵をかけたいところで、

@synchronized(lockObject)

する。

2010-05-31 15:11:39.522 lockTest[4411:1d03] ID:0 SPEAK 1

2010-05-31 15:11:39.531 lockTest[4411:1d03] ID:0 SPEAK 2

2010-05-31 15:11:39.532 lockTest[4411:1d03] ID:0 SPEAK 3

2010-05-31 15:11:39.533 lockTest[4411:1d03] ID:0 SPEAK 4

2010-05-31 15:11:39.533 lockTest[4411:1d03] ID:0 SPEAK 5

2010-05-31 15:11:39.535 lockTest[4411:3603] ID:1 SPEAK 1

2010-05-31 15:11:39.535 lockTest[4411:3603] ID:1 SPEAK 2

2010-05-31 15:11:39.540 lockTest[4411:3603] ID:1 SPEAK 3

2010-05-31 15:11:39.540 lockTest[4411:3603] ID:1 SPEAK 4

2010-05-31 15:11:39.541 lockTest[4411:3603] ID:1 SPEAK 5

2010-05-31 15:11:39.544 lockTest[4411:3e03] ID:2 SPEAK 1

2010-05-31 15:11:39.545 lockTest[4411:3e03] ID:2 SPEAK 2

2010-05-31 15:11:39.545 lockTest[4411:3e03] ID:2 SPEAK 3

2010-05-31 15:11:39.546 lockTest[4411:3e03] ID:2 SPEAK 4

2010-05-31 15:11:39.546 lockTest[4411:3e03] ID:2 SPEAK 5

うん。めいめいのスレッドでちゃんと最後まで用を足す。

途中でママは呼ばない。

@synchronized。

こいつは勘なんだけども、

中の人はmutexのような気がする。

もし、頻繁にロック、アンロックするならば。

キューに構造体のポインタを押し込むような処理ならば、

処理自体よりロックの方が時間がかかるかもしれない。

と思った。

それも、たくさんの件数のデータを

押し込み、取り出しするんなら、

わりと馬鹿にならない時間がかかるかもしれない。

まだ試してみるべきことはある。

入り乱れる３つのスレッド

ある処理をするスレッドを３つ作り、

それを実行させていくといったとき。

で、その一連の処理は一つのセットで、

その処理を始めたら処理を走りきらないと、

ほかのスレッドで処理を始めたくないときとか。

たとえば、

あるデータの集合。

たくさんあるデータの処理を２つや４つのスレッドで分担すると、

CPUの複数のコアがちゃんとつかえてお得かも。

と考えたときなんか。

キューから読み込み、読み込んだものを消す。

で、処理する。

その前には当然キューに書き込むわけだけど。

キューに押し込むデータをまとめて、

キューに書き込んで、なんてしてるとき、

スレッドが切り替わったりなんてして見なさいな。

あーもう。

ってなるから。

Cocoaでスレッドセーフなキューがあれば、

私はちょっと幸せになれたんだと思う。

MutableArrayを使えば、キューなんて簡単に実装できるけど、

MutableArrayはスレッドセーフじゃないんですな。

MutableArrayを保護しながら使わないといけない。

キューにアクセスできるのは一つのスレッドだけで、

ほかのスレッドは終わるまで外で待っていないといけない。

トイレの個室には同時に一人までしか入ってはいけないんです。

ある例外を除いて。

トイレに入ったらロックしましょう。

少し話はそれるんだけども、

スレッドを３つ立てて、

その３つのスレッドで５回ログをはく。

なんて処理は、結局こんな結果になる。

2010-05-31 14:28:54.933 lockTest[4067:3603] ID:1 SPEAK 1

2010-05-31 14:28:54.934 lockTest[4067:3e03] ID:2 SPEAK 1

2010-05-31 14:28:54.930 lockTest[4067:1d03] ID:0 SPEAK 1

2010-05-31 14:28:54.935 lockTest[4067:3603] ID:1 SPEAK 2

2010-05-31 14:28:54.935 lockTest[4067:3e03] ID:2 SPEAK 2

2010-05-31 14:28:54.935 lockTest[4067:1d03] ID:0 SPEAK 2

2010-05-31 14:28:54.936 lockTest[4067:3603] ID:1 SPEAK 3

2010-05-31 14:28:54.936 lockTest[4067:3e03] ID:2 SPEAK 3

2010-05-31 14:28:54.936 lockTest[4067:1d03] ID:0 SPEAK 3

2010-05-31 14:28:54.938 lockTest[4067:3603] ID:1 SPEAK 4

2010-05-31 14:28:54.938 lockTest[4067:3e03] ID:2 SPEAK 4

2010-05-31 14:28:54.938 lockTest[4067:1d03] ID:0 SPEAK 4

2010-05-31 14:28:54.940 lockTest[4067:3603] ID:1 SPEAK 5

2010-05-31 14:28:54.940 lockTest[4067:3e03] ID:2 SPEAK 5

2010-05-31 14:28:54.941 lockTest[4067:1d03] ID:0 SPEAK 5

ログはき一回ずつ、仲良く交代している。

あえてトイレでは例えない。

ログを５回はききるまで、

スレッドが切り替わるのはいや。

っていったとき、

ログをはくfor文に入る前と、

出た後に、

ロックをかける処理と、

ロックを外す処理が必要になる。

さてさて。

ISO-2022-JP

いわゆるJISなんですが。

ルール１

漢字や半角カタカナとかの前にあるコードをおくこと。

そのコードは0x1B（いわゆるエスケープ文字）から始まる。

ルール２

漢字や半角カタカナを使い終わったら、あるコードをおき、

行の終わりまでにJIS X 0201-1976のラテン文字集合か

ASCIIに戻すこと。

っていうことがあるみたいなんで、

そんなコード。

例えば、

1B 24 42

とか、

1B 28 42

が入っていれば

JISと思えばいいんすよ。

ただ、これはUCS2に含まれているようなコードで、

すなわちそれはUTF-16で書かれている以下のような文字列、

☛⑂あかさたなはまやらわ✛⡂

なんかはJISっぽく見えるんだと思う。

まあ、こんな文字列はね。

見かける可能性なんてないと思うけど。

あるわけないよこんなの。

だから、

☛⑂⡂やっほー。元気ー？こないだの品物は1200㌛⡂⑂☚

っていうUTF-16の文章は悪意があるんだよ。

うっさい。具合悪いわ！みたいな。

円で換算してから請求しろ！！みたいな。

Windowsのブラウザでちゃんと出るのか不安だ。

1B 2?はバリのほうの言葉が割り当てられてるんで、

バリのほうの文書はJISっぽいんだと思った。

ちなみに、

☛ 26 1B　右さしてる手の形。しかも黒い

⑂ 24 42　さすまたみたいな記号。

✛ 27 1B　十字な記号。

⡂ 28 42　クリリンのおでこにあるようなやつ。

㌛ 33 1B　クローネを一文字で。

だわさ。

クリリンのおでこは、

ハードウェアな人が使いそうな予感。

Windowsのブラウザでちゃんと出るのか激しく不安だ。

ここらあたりは文字化け御免で。

そんなこんなで、ちょっと怖いよね。

だもんで、UTF-16チェックをした後に

JISチェックをするようにしようと思った、

今日という肌寒い日。

どっか雹がふってたらしいよ。

4000->4DBF

ああ。ねむい。

酒飲みながらステップ実行ぽちぽちぽち。

で、すっかり忘れてたんだけども、

UTF-16はNULL文字が平気で出てくるわけで。

改行やタブのこともすっかり忘れてたし。

NULL文字が平気で出るので、

fgetsとかstrlenとかやると痛い思いをする。

うん。痛かったよ。わりと。

もはやバイナリを読む気でかからないと。

っていうかcでファイルポインタからファイル読み込むなんて。

何年ぶりですか。ほんと。

最近はね。まあ、いろいろ便利になったからね。

freadをつかってね。と。

で、微妙な漢字ばかりの4000->4DBF。

日本がどうたら書かれてるんで、

もしかしたら、なじみのやつが含まれているかも。

漢字の拡張文字らしい。

これもやはり含めた方が無難か。と思った。

なので4E00->9FFFを

4000->9FFFに変更してみる。

もう少しのんだら寝よう。