2012年8月18日土曜日

Xcode 4.4.1とMoutainLion V10.8.1のバグ

MacOSがMountainLionになってXcodeもV4.4.1が出た。

が、いつものごとく幾つものバグがあった。

(1)Finderからのドロップでプロジェクトにファイルを追加すると、コンパイル対象にならない

ファイルはあるはずなのにリンクが通らないという謎の現象が発生し、調査の結果がこれ。

プロジェクトのところでマウス右クリックのAdd File Toを使った場合はこうはならない。
ファイルがあるのにリンクが通らないとエラーが出る場合はこれが原因。
一旦Delete→Remove ReferenceしてからAdd File Toをやり直せばよい。

コンパイル対象でないファイルの追加にはドロップも使える(画像とか)。


(2)エディタで「Open in eparate Assistant Editor」で分割表示しているとき、
右側(Assistant Editor側)で単語補完候補がすぐ消えてしまう

入力がかなり面倒になる。
入力を続けていると、一時的に治ることもある。


(3)リアルタイムエラー検出で使うソースを間違える
例えば
proj-+--a.m,a.h
       +-lib--a.m,a.h
と同じファイル名のソース(.m/.h)が2箇所にあり、proj直下のファイルをプロジェクトにAddしていて、libはフォルダごと登録しているが、この2つのファイルは登録してないとする。
この時、本来lib下のファイルは無視されなければならないが、これがエラー検出に使われる。ソースを見ても絶対にあってるのに警告が出るときは、同一ファイルが複数箇所にないか確認したほうがいい。
これで一体どれだけ無駄なデバッグさせられたか。

同じファイル名のソースが複数出来てしまうのもバグ(に近い仕様)で、プロジェクトにAddするときコピーを作ってしまうとか、グループ間移動をした時ときに発生すると考えられる。


(4)iOS4.x用シミュレーターがないのはバグに近い仕様だと思う。
Device Debugging SupportはiOS3/4用ともまだあるが、シミュレーターは消えている。

まだあるじゃろうiOS4機。それとももう無視していいというお達しなのか?

仕方ないので、うちではVMware Fusion上にLionを構築してXcode4.3.2を復旧させた。
まさかこういう使い出があるとは。->だめ。一旦プロジェクトをXcode4.4用にしてしまうと4.3.2ではエラーが出てしまう。4.3.3にしたら通った。


(5)同名のグループが複数作れてしまう
多分、New Groupで作成したものとドラッグでフォルダごと入れた場合に出来るのだと思う。

(6)IBでClassを変更しても内部的に更新されないことがある。
サブクラスを作ってそれに変更したのに、正しく動作しない。
Cleanかけてもだめ。
結局そのViewを一旦削除して再度貼り付けたら直った。
参照するファイルを間違えるのと同じ原因ではないかと推察中。

(7)ソースコードを修正してもそれをコンパイラが認識しないことがある
発生させる一例。
1.あるメソッドの引数を変更する
2.それを使っている部分で警告が出るようになる
3.その部分を引数付きに書き換える。ただし、エラーが出るようする(間違えておく)
4.メソッドの引数を元に戻す
5.エラーが出ている行も引数を削除し、エラーが出ないようにする
としても、エラーが消えない。コンパイルしなおしてもダメ。
Cleanをかけたら消えた。
別の条件で発生したときはCleanをかけてもダメで、プロジェクトを一旦閉じて再度開いて、更に再ビルドでようやく直った。

幾つかの現象から、どうも、4.4.1にはソースの修正を正しく認識できないバグがいる模様。どうしてもおかしいと思ったら、Cleanをかけてみるか、プロジェクトを一旦閉じて再度読み直すか、IBなら一旦削除して貼り付け直しするのが吉。

(8)Settings.bundle内を編集し続けているとハングアップすることがある
2回発生したから確実かと。

(9)日本語名ファイルがGitで通らない
コミット時にエラーが出る。
コンソールからgitのコマンドを発行するとちゃんといけるので、
Xcode内のgit処理のバグだと思われる。ずっと前のバージョンから治ってない。

(10)gitの管理下にあるファイルで、編集していないのに「M」マークが付くことがある。
しかも、しばらくすると勝手に消えるという謎付き。
実害はない。

・・・

V4.3台で存在した「実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けする」バグは「ほぼ」修正された模様。一度に大量に表示させると、まだときおり/???というUnicode形式で表示されることがある。




アップルは、毎度のことながらデバッグが全く足りてない。
この分だと、もうすぐ出てくるiOS6もすぐには対応作業しないほうが吉かも。
どうせバグだらけだろうから。
「アップルのソフトはバージョンアップがあってから入れるのが正解」。
・・・

ついでに、MountainLion(v10.8/10.8.1)のバグも少々。

・省エネルギー設定でコンピューターのスリープを「しない」にしっていしても
勝手にスリープしてしまう。スリープと言うより、アプリを終了してスタンバイ状態に
入ろうとする。

2時間くらいで落ちる気がする。
このため、一晩中処理を走らせ続けたいと思っても出来ない。
(スタンバイになる前にアプリの終了を確認しており、ここで処理が停止してしまうから。)
->これは、「使用しない状態が?分間続いたらログアウト」の設定によると判明。「セキュリティーとプライバシー」〜「一般」〜「詳細」の内にあり。


・画面共有で接続されているとき、ホスト側からスリープに入るよう操作してもスリープしない
要するに遠隔からスリープさせられないということ。だめじゃん。
10.8.1では治っていた。
やっぱり治ってない。
ログイン画面のスリープを押してもスリープしない。
その後ログインしてスリープをかけてもスリープしない。
どうも、ログイン画面でスリープを押すとおなしくなる様子。

・ネット先のドライブが応答しない時、リセットがかかってしまう
 エラーも出ずに急に再起動した。

・USBディスプレイドライバのDIsplayLinkDriver V1.8を入れているとスリープできなくなる=スリープ時にシステムが落ちてしまう

→調査の結果、メーカーサイトの中の http://www.displaylink.com/support/ticket.php?id=331 に情報を発見。
要約すると「スリープ中にBluetoothデバイスの電源を切ると落ちる」らしい。
うちの場合、マウスがそれに相当している(手動で電源を切るだけでなく、デバイスが自動的に電源を切る場合も同様)。
これはOS X v10.8のバグで、10.8.1で修正される予定らしい。

「DisplayLinkを入れると露呈する」とある。
ということで、暫く待つしかなさそう。
→10.8.1では治っていることを確認。

・共有にしているフォルダの内容が更新されないことがある
ファイル削除したらそうなる感じなので、ファイル削除後のディレクトリエントリ作成周りにバグがいると思われる。

・Windows(7)とのファイル共有ができなくなった

今のところ、Win←Macはできているが、逆はできない。
画面共有はLion時はできなくなっていたが、MountainLionでは出来るようになったのに、
更に利用頻度が高いファイル共有ができなくなってどうするよ。
→出来る機体と出来ない機体が存在する。ということで、何かの設定だと思うのだけど、原因は不明。Mac間のファイル共有は出来てる。
→ようやく原因が判明。セキュリティとプライバシー」の設定で「ファイヤーウォール」〜「ファイヤーウォールオプション」〜「smbd」〜「外部からの接続をブロック」を「許可」に直したら治った。
こんなところいじった覚えはないので、10.8.1で勝手に設定されたと思う。

・スリープ明けにEthernetでつないでいるネットワークが切れてしまうことがある
省エネ設定の時間を過ぎて自動スリープに入った時に発生する。
ケーブルの抜き差しでは復旧せず、再起動するしかない。かなり致命的なバグ。
V10.8.3では発生頻度がかなり下がったが、まだ出る。

手動でスリープに入れたときは発生しにくいが、長時間スリープした後だと別症状で発生する。ただし、再度手動スリープして再起動すると治ったこともある。
V10.8.2で直った模様。まだ2回だけでの結果なので、もう少し様子見。
V10.8.2でも発生。IPv6では接続できているがV4では接続できない。
うちのプロバイダはv6を通さないのでインターネット接続ができなくなる。
WiFiでは発生しない。



・DVDプレイヤーで、話の切り替わり目で数秒〜数分が飛んでしまうことがある。
 例えば1話目が終わり、2話目が始まるとき、2話目の最初しばらくが飛ぶ。
 すべてのディスクではないが、かなり高い確率で発生する。
 SnowLeopard/Lionでは発生していなかったので、MoutainLion版のみのバグ。
 10.8.1で確認しているが、10.8.0がどうだったかは不明。
 ちなみに、Mac go社のMac Bru-ray Playerでは発生しない。
 (それはそれで他の問題が多すぎて常用しづらいのだけど。)
10.8.3では発生していないような気がする。

・フリーウエアのMacFaceが動かない
 対応版は出そうにない。まあ、必須ソフトではないけど。

・同muCommander v0.9.0が「ファイルが壊れてる」と出て実行できない(Lionでは動く)
10.8.1でも変わらず。
→「セキュリティーとプライバシー」〜ダウンロードしたアプリケーションの実行許可を「すべてのアプリケーションを許可」にすると実行可能と判明。
しかし、「実行できません」ならわかるけど「ファイルが壊れてる」というのはエラーメッセージが間違っているとしか思えない。


・ロジクールマウスの特殊ボタンが効かなくなった
ドライバーを更新しようにも、日本サイトにあるドライバはMountainLionには対応してない。米国サイト http://www.logitech.com/en-us/home で検索するとMountainLion対応の最新版がある。メッセージ英語のみになってしまうが、まあ、簡単だから問題ないかと。とありあえず日本語版が出てくるまでのつなぎはこれでOK。

・落ちる頻度はLion(10.7.4)より多い
まだ不安定な部分がある様子。
1ファイルへの多重アクセスをすると落ちやすいような気がする。
落ちるというか、無反応になってしまう。
Xcodeでタグ上に残っているファイルをDelete-Move trashとかすると一発。


とにかく、デバッグ要員を10倍くらい増やせ、アップル。新機能より安定性重視。
特に企業に入って行く気ならそれは非常に重要(その気はないのかもしれないが)。

2012年8月9日木曜日

UTF8とSHIFT-JISの判別し方

UTF8はUTF16を算術演算して一定のコード範囲に収めるようにした文字コードである、らしい。

 実際のところ、以下の5つパターンに収束する。

   (1)c2~df+80~bf                                                2バイト
   (2)e0~ef+80~bf+80~bf                                    3バイト
   (3)f0~f7+80~bf +80~bf +80~bf                             4バイト
   (4)f8~fb+80~bf +80~bf +80~bf +80~bf                5バイト
   (5)fc~fd+80~bf +80~bf +80~bf +80~bf +80~bf   6バイト

UTF8データ群中では、先頭のバイトで長さがわかる。
逆に後ろからでも順次読んでいけばその文字の先頭がわかるのは、ASCIIコードは0x00~0x7eなので、重複部がないからである。

SHIFT-JISは
  第1バイトは
    (あ)0x80~0x9f
    (い)0xe0~0xef (JISのどの水準までサポートするかで変化することがある)
  第2バイトは
    (A)0x40~0x7e
    (B)0x80~0xfc
なので、2バイト目がASCIIと重複する部分がある。
このため、逆側からの読み出しでは正しく文字を認識できない。

また、SHIFT-JISのファイルには1バイト半角カタカナも入っている可能性も高いので、
  0xa0(0xa1)~0xdf
のコードも存在する。UTF8中には1バイト半角カタカナはない

そういう状況でのUTF8とSHIFT-JISの識別の仕方。

前から順に読んでいって、上記(3)~(5)のパターン、すなわち0xf0~0xfdが出てきたらUTF8で即確定できる。


逆に、(あ)が出てきたらSHIFT-JIS。UTF8では(あ)のコードはいきなり出てこないから。
0xa0~0xc1が出てきたときは、半角カタカナなのでSHIFT-JIS。
ここまでの識別でもまだわからないのが
 (1)と(2)
である。この部分の完全な判別はできない。

しかし、確率論的には推測できる。
(2)のコードはSHIFT-JISでも存在しうるが、その範囲は第二水準であり、
しかも次の1バイトが第1水準及び半角カタカナとなるため、事実上その並びが
普通のファイルで出てくることはほとんどありえないと考えていいだろう。
だからここはUTF8。

残りは(1)。
0xc2~0xdfは半角カタカナと重複するからここだけでは判別できない。

2バイト目が0x80~0x9fならSHIFT-JISの第1バイトかもしれない。
したがって、この先を更に読み続け、どちらかの文字コード範囲として矛盾が
出てきた時点でその可能性を排除する、という方法しかない。
ただし、場合によっては、UTF8とSHIFT-JISの双方でありえる可能性もある。

ということで、完全自動の文字コード認識は不可能という話。
基本自動、読めなかったら手動で、という風にしておく必要があるわけである。

X−BASIC for iOSではコード範囲を限定しているので、全自動。

2012年8月1日水曜日

UTF8とSHIFT-JISコードの特徴

UTF8<->16の変換関数を書いたので、UTF<->SHIFT-JISの変換関数も公開したいところだが、それは出来ない。

なぜかというと、出し惜しみじゃなくて、文字コードにおいて、UTFとSHIFT-JISの間に算術的相関関係がないからである。

(一部のコード範囲を除き)基本的には、1:1で変換テーブルを作るしかないのだ。

だから、変換処理を公開すると言うことはそのテーブルを公開することに等しく、
SHIFT-JISの文字数を考えたら、それは現実的ではない。高速化を考慮するなら、
交互の変換にはそれぞれ別テーブルが必要となるのでなおさらである。

実際に、全ての対応表を載せているHPがあったりするが、その表示はかなり重い。


・・・

さて、X-BASIC for iOSの開発でUTF-8の文字コード(正確には文字エンコード、らしいけど)についてかなりだいぶ理解できたと思う。
SHIFT-JISに関してはその誕生時から見ていて、X1-turboからX68000、さらには
多くの組み込み機器にも処理を実装してきた。日本でもトップクラスの理解者である、と自負してたりする(^_^;)。
なもんで、両方のコードを理解した今となっては、怖いもん無しである(^_^;;)

いや、それは冗談として、 UTF-8の特徴を少し説明。

UTF-8は、JISコードに対するSHIFT-JISのような物で、UTF16に対して算術演算をかけることでコード範囲を限定している。

双方の特徴をまとめると以下のようになる。


SHIFT-JIS
・前から読まないと正しいコードが得られない
・しかしそれさえ守れば、ASCIIコードと混在可能
・ASCII用に書かれた処理の多くは、簡単な2バイトコード判定の追加するだけで流用可能
・基本的に見た目のバイト数と文字コードのバイト数が一致する
X68000の1/2角・1/4角文字など、例外も存在した(まあその範囲はそもそもJIS規定外だが)。
・第2水準漢字までが2バイトで収まる(第3水準以降は知らない)
・JISコード(=連続コード)と算術演算による交互変換が可能なため、漢字フォントの位置を求めるのが楽。
JISコード並びの文字フォントはフリーで多数出回っているため、 無償で漢字を表示できるシステムを構築できる(読みやすさは別にして)。
・JISコード第1水準漢字は音読みで並べられているため、音読み漢字変換なら比較的簡単に実装できる



UTF8
・前からだけでなく後ろからでも正しい文字コードを得られる
・そのままASCIIコードとの混在が可能
・しかもASCII用に書かれた処理の多くがそのまま使える
・見た目のバイト数と文字コードのバイト数が一致しない
・第2水準漢字まででも3バイト以上になることがある(というか2バイトで収まる範囲は少ない)


どちらがいいというのではなく、目的さえ間違えなければ、どちらもよく考えられたコードだと言える。が、SHIFT-JISは組み込み機器で使うに有益な特徴を持ったコードで、UTF8はOS上で英語圏発祥の処理を多国語化するに良いコードだと言えよう。

UTF8については次回もう少し解説。