iOSウオッチドッグの存在

今まで全く気にしてなかったが、どうもiOS中にもウォッチドッグタイマーが存在するようである。

ウォッチドッグが何であるか、詳しくは調べてもらうとして、超簡単に書けば、
暴走防止のためのタイマーである。 組み込み機器ではウォッチドッグにひかかったら、
暴走や(周辺デバイス)無反応とみなしリセットをかけるのが普通である。
(正確には、プログラム的に一定時間以内にウォッチドッグタイマーをリセットしないと、ハードウエア的にリセットがかかるようになっている。)

某所の情報によると、iOSでもWebView周りには

• Watchdog: 20秒(アプリケーション起動時など)
• DNS: 30秒
• TCP Connection: 75秒
• NSURLConnection: 60秒

というウォッチドッグがいるらしい。
"0x8badfood"という例外コードを返してくるとか。"ate bad food"ということらしい。
ateはeatの過去形。発音が8=eightと同じである。

しかし、X-BASIC for iOS開発時の調査の結果、カーネルそのものに関わるタイムアウトも存在ようである。

以下のループをシミュレーター上で実行すると、約256秒でプログラムが落ちる。
while (1) {
#if 0
    NSDate *dt=[[NSDate alloc ]initWithTimeIntervalSinceNow:0.0];
    [[NSRunLoop currentRunLoop]runUntilDate:dt];
    [dt release];
#endif
 }
これで落ちるときはEXC_???(11)(code=0,subcode=0x0)となる。

#ifの中は有効無効どちらにしても変化なし。
また、この中にどれだけ長いCの処理を書いていたとしても、落とされてしまう。
 iOS5.1/6.0とも。

しかもこれ、Xcodeにつないでいる実機上やシミュレーター上でもLeakでトレースしていると発生しない。単独の実機ではHOMEに戻ってしまうし、シミュレーター上で普通に実行している場合は、上記エラーというかトラップを発生して止まる。

2013/11/10追記
iOS7シミュレーターでは発生しない様な気がする。Xcode5で改善された？

・・・

無限ループらしきところを警告しているつもりなのかもしれないが、定期的にcurrentRunLoopに戻しても発生するから、迷惑な事この上ない。
警告ならメッセージで出すべきであって、プログラムを落とすのはやりすぎ。

普通ウォッチドッグタイマーにはそれをリセットする機構があるが、iOSにはない。
ゆえに、iOSは組み込み機器的には使えない。
(iPadやiPod touchが安いから、筐体に組み入れて組み込み機器にしたらいいじゃん、という意見を見たことがあるが、iOSはこの件を含め、組み込み機器向けじゃない。組み込み機器なめんなよってな感じ。)

    ・・・

さらなる調査で、RunLoop内では、如何様にしてもループを回し続けるのはご法度と判明。必ず落ちる。
バッググラウンド内なら回し続けても大丈夫。でもバックグラウンドからからは表示させることができない。というか、表示や入力に関わるすべてのUI要素が使えなくなる。UIWebViewに至ってはレポートまで出力して落ちる。
だが、バックグラウンドからRunLoopに通信する方法が見つからない。
（KVOは同一スレッド内で実行されるのでダメ。 Notificationもおそらく同様。)
これさえあれば何とかならんでもないのだが。

KVOの通知でフラグを立て、先のループ内で表示するという手を考えた。
while (1) {
    NSDate *dt=[[NSDate alloc ]initWithTimeIntervalSinceNow:0.1]; // 0.0はだめ
    [[NSRunLoop currentRunLoop]runUntilDate:dt]
    [dt release];
    if (flag) {
       // 表示
    }
 }
実際にこれで表示が出るには出る。が、秒１回くらいならずっとOKなのだが、秒３０回くらいの速度でしばらく回していると表示が出なくなる。どうも、NSRunLoopの行から帰ってこないようだ。RunLoopに入りっぱなしになるという感じ。バグじゃろうこれは。

→アップルのドキュメントの中にRunLoopにスレッドを接続する方法を発見。
何とかUIViewの表示だけは出来るようになった。が、問題はUIViewだけじゃなくUITextFiled等も含む全UI要素に関わるので対応が非常に大変。
→実機で落ちなけりゃそれでOKで無視することにした。

iOS6での画面対応について

iOS6での画面回転対応に非常に苦労したのでここに記録する。
iOS5以前にも対応するなら、従来の回転処理も残しながら、
新たに以下のメソッドを追加する。
細かい話は他のサイトで調べてもらうとして、ここではやり方だけ列記。

（１）基本的に、全てのUIViewControllerに以下の処理を実装する

- (NSUInteger)supportedInterfaceOrientations
// 回転を許可する方向を返す
{
#if 0　// リターン値はこの中から選択
    typedef NS_OPTIONS(NSUInteger, UIInterfaceOrientationMask) {
        UIInterfaceOrientationMaskPortrait,
        UIInterfaceOrientationMaskLandscapeLeft,
        UIInterfaceOrientationMaskLandscapeRight,
        UIInterfaceOrientationMaskPortraitUpsideDown,
        UIInterfaceOrientationMaskLandscape,
        UIInterfaceOrientationMaskAll,
        UIInterfaceOrientationMaskAllButUpsideDown,
    };
#endif
    return UIInterfaceOrientationMaskAll;
}

- (BOOL)shouldAutorotate
// 回転を許可するかどうかを返す
{
    return YES; // NOなら回転させない
}


もし個別のUIViewControllerに実装するのが面倒なら、以下の実装を入れればよい。
（各UIViewControllerの回転時にここが呼び出される。 ）

-(NSUInteger)application:(UIApplication *)application supportedInterfaceOrientationsForWindow:(UIWindow *)window
{
    return UIInterfaceOrientationMaskAll;
}



（２）[window addSubview:navigationController.view];
ではなく
    [window setRootViewController:navigationController];
に変更する。

ここまででiPadは回転するようになる。iPhone/iPod touchでもPortraitUpsideDown以外は回転するようになるが、PortraitUpsideDownだけが回転してくれない。



（３）UINavigationControllerの中にも上記回転制御を入れる。そのためにサブクラスを作る。


@interface NavigationControllerForiOS6 : UINavigationController
@end

@implementation NavigationControllerForiOS6
- (NSUInteger)supportedInterfaceOrientations
{

    return UIInterfaceOrientationMaskAll;
}

- (BOOL)shouldAutorotate
{
    return YES;
}
@end

UINavigationControllerを使っているところを全て、このNavigationControllerForiOS6
に変更する。



・・・

となる。
（３）がわかりにくいところ。（２）まででiPadまで動いてしまうので見逃しがち。

しかし、アップルはなんでこんな重要な、しかも非常によく使われている部分の仕様を変えたりするんだろうか。その上、変えてなにか良くなっったりしているとも思えないし。
まったく。

Mac Blu-ray playerのバグ

Mac上で唯一のBlu-rayディスクプレイヤーソフトであるというMacgo社の
「Mac Blu-ray Player」。

「こんな名前いいのん？」というような名前だが、早く出したもん勝ちである。
（Windows版も同じ名前なのはご愛敬？）

それはどうでもいいとして、最新版V2.8.5になっても「BDプレイヤー」としての挙動が全くなってない。「Mac Blu-ray Filer」に変名した方がいいくらい。


その出ているバグ。


＊V2.8.5に更新した後はMacの再起動が必要そう
再起動する前はDVDを読ませようとするとハングアップした。
（BDは読めた。)
Windows版では再起動は不要だった。


＊V2.8.3以降で出ているバグ
・音声選択名がおかしい
BDでのみ確認した。
Englishで日本語、無効で英語になり、Japaneseは選択できない。
最初、音声選択ができなくなっているのかと思った。
最新のV2.8.4でも治ってない。
V2.8.5では直ってた。

＊V2.8.4以降で出ているバグ
・スリープ明けに必ずハングアップする
しかもこのときディスクのアクセス権を握ったままにするので、ディスクが排出できなくなる。
OSでイジェクト命令を発効しても排出されない上に、そうしてしまうとOSからの認識もされなくなるので、強制排出でディスクを入れ替えても認識されない。結果、OSの再起動しかなくなる。
V2.8.5でも直ってない。

・音がおかしくなる
前の音の一部を引きずるような感じになる。

BD:モーレツ宇宙海賊２３～２６話の内どれか。重低音が効くところ。
V2.8.5で発生。以前のバージョンは不明。


なんでこんなにエンバグするのか、チェックが甘すぎる。

何回かバグレポート出しているけど一向に治す気配がないので、もはやそういう会社だということで。

・・・従来バージョンからずっと出ているバグ

＊ディスクによって出たり出なかったりするもの

・複数話が記録されているディスクで、途中の1話しか再生出来ないことがある
  　例)BD:Infinite Stratos 1枚目 第2話しか再生されない。
　最新版では治ってた。

・１話再生するごとに再生が止まってしまう
ファイラー的に動作しているので、各話が独立したファイルになっているディスクではこうなってしまう。
次の話を再生するためには、ディスク選択→オープン、その他のタイトルから話数選択をしなければならない。しかも音声選択していたときはそれも選択し直す必要がある。

・宣伝しか再生されない
　BD:シュタインズ・ゲート
　タイトル選択から本編を選べば本編の再生ができる。
　これもファイラー的動作によるものだろう。
　DVD版では、ちゃんとメニューから再生される。

・話の順番がおかしい
　BD:神のみぞ知るセカイII／けいおん！（第２期）
　そもそも連続再生できないが、「その他のタイトル」から選ぶと、第6話が9話目に入ってる（神のみぞ知るセカイ)。
V2.5.4.0994で治った気がする。でもまだ連続再生はできない。

・いきなり途中から再生が始まることがある
　BD:バカとテストと召喚獣
最新版では発生していない。

・字幕設定が1話毎にデフォルトに戻されてしまう

　DVDでも発生。

・全再生が終わると、メニューに戻るのではなく再生そのものが終わってしまう
・BDのメニューが表示できない
　２つはほぼ同じ意味。
　すべてのBDで発生。
　重大なバグ。

・タッチ反応エリアが狭すぎてディスクメニューがほとんど操作できないことがある
　例)DVD: MOONPHASE、タユタマ、シュタインズ・ゲート
　BDはメニューそのものが表示できないので発生し得ない。

・勝手にチャプターが飛ぶ
　例)BD:FINAL FANTASY VII
　最後最後、主人公のセリフが途中で飛んでしまう。しかもその飛び方が絶妙なのでセリフの意味が全く逆になってしまう。だめじゃん。

・チャプタージャンプが単なる時間ジャンプになってる
最新版では更にわけの解らんジャンプの仕方をする。およそ使いものにならない。

  ＊ディスクにかかわらず発生するもの
・再生中にスリープに入ると、スリープ明けに再生が継続されない事が多い


・再生中に停止すると、次回再生でファイル選択を求められる
最新版では、ここでディスクを選択すると一応前の再生位置から再生が再開される。
が、音声状態はディスクデフォルトに戻されてしまう。


・「最近の視聴履歴」というものがあるが、全く機能してない
　というか、今見ているディスクの名前しか出てこない。
　必要ないと思う。
これはメニューに出るのではなく、Dockの方に出る物だった。
正常動作している。


・AppleRemoteでの操作法が標準アプリの「DVDプレイヤー」とぜんぜん違う。
　ディスクメニューの操作がマウスで出来ないのにリモコンも使えないので操作不能に陥ってしまう。

・ディスクが排出出来ない
　DVDプレイヤーにはEjectボタンもあるし、ツールバーのEjectからでも排出可能だが、
　こいつはEjectボタンがない上に、 ツールバーのEjectを押しても排出できない。
　Finderからディスクをゴミ箱に入れてもダメ。このアプリを終了しないと排出されないのだ。排出のためにいちいちアプリ終了するなんて面倒な事この上ない。
最新版でも治ってない。
→1つ前版では、Eject出来ないだけでなく、再生中にEjectを実行し、その状態で再生を停止すると「ディスクを開く」を選んでもメディアが認識されないというバグも発生する。OSレベルで認識されていないようなので、Ejectされない事が問題の根本。
これをしてしまうとOSの再起動しか手がなくなる。極めて重大なバク。 


ディスクを取り出すだけなら、ドライブの強制排出を行うか、USBケーブルを抜き差ししてEjectボタンを有効化した方が楽だが（BDドライブは外付けしかないのでこの方法が使える）、OSから認識されない状況は変わらない。


・再生速度が微妙に変わる
これはこのソフトだけじゃなくMac上のほとんどのプレイヤーソフトいえるけど、
再生速度が微妙に速くなることがある。VLCでも発生する。

リズムがはっきりしている音楽再生時に音程が狂うのでよく分かる。
同じデータでもWindows上のプレイヤーでは発生したことがない。
Macの省電力に伴うクロック制御などが影響しているのだろうか。
Mac上での音楽再生はこの理由により、正確な意味では「実用的でない」と判断している。
→これはMacOSのバグだったようで、10.8.3で治ったような感じがする。治ってなかった。発生率は下がったけど未だ出ることがある。出たときのひどさは今までの比ではない。

・・・
特にBDでの再生があまりにもひどい。ちゅうか、DVDならMac標準の「DVDプレイヤー」でいけるのだから、ウリのBDでこの状況は「使いもんにならない」。
ディスク内に記録されているいろいろな情報の読み出しそのもの、またはその解釈が正しくないと思われる。もっとDVD/BDの仕様書を読んで正しく実装してほしい。

とりあえずもっとたくさんのディスクを再生して確認しろ。
テストディスク1枚くらいでしかやってないんじゃないか？
本当にデバッグしてるのか？
少なくとも複数枚組作品なんて見てないと思う。そうでなきゃ排出問題は絶対気づくはずだから。なんか、作品を変えるごとに違う不具合が出るんだけど。まともに操作を含む再生が出来る方が少ない。


徐々に良くなってきてはいるが、まだだめ。
フリーウエアじゃないのだから、メーカーには一日も早い全てのバグの修正をしてほしい。クリスマス対応とかしている暇があったらさっさと直せ。どうでもいいような修正でバージョン番号ばっかりあげてんじゃねぇ。


一向に改善されないので、とうとうメーカーに報告。
まあ、治らない可能性が大だけど。
→返答によると、５～６月頃にメニュー対応を初めとした大バージョンアップがあるらしい。

現状では先にも書いたとおりファイラーの域を出てないので、初心者には「全くおすすめできない」し、熟練者でも「なんとか我慢して使える」レベル。
Mac標準のDVDプレイヤーがBDにも対応してくれることを強くかつ、切に願う。

・・・2013/04/23追記
あまりに出来が悪いので、とうとう使用を中止。
来月以降にあるという大バージョンアップが出るまで使わない(当然検証もしない)。(他にモニタが用意できるなら)、専用BDプレイヤーを買った方がよほど精神衛生上良い。
そういうこと。
→ちゅうことでSONYのBDプレイヤーBDP-S190を買った。安いのにとてもいい機種。
HDMI入力に余裕がある人にはおすすめ。

・・・2012/10/24追記
とうとう新型iMacでも光学ドライブがなくなってしまった。
ということは、AppleはPCでのDVD/BD再生はもはやサポートする気が無さそうなので、
BD対応は将来的にもありえないかも。

NSTimerのバグ

NSTimerの時間指定は基本的に秒単位である。

例えば

+(NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)seconds target:(id)target selector:(SEL)aSelector userInfo:(id)userInfo repeats:(BOOL)repeats

のsecondsは秒単位なわけだが、０より大きく１より小さな数を指定すると１秒以下でも指定できる。

ここで、仕様書を読むと「負数を与えるとその負号を取った値を0.1ms単位として使う」と書いてある。これをそのまま理解すると例えば、-1000と指定すると1000*0.1=100msを指定したことになるはずである。

がしかし、実際にはそうはならない。
非常に短い時間でタイマーがかかってしまう。
NSTimerそのもののバグか、仕様書の間違いである。
少なくともiOS5.1まではこのとおりだ。

仕方ないので、0.??の値を使っている。

早々に正しい仕様を公開して欲しいところ。というか、仕様書通りに動くように直してくれ、Apple。

MountainLion v10.8.2での不具合ほか

iOS6にあわせてMoutainLionも10.8.2にバージョンアップされた。

V10.8.1にあったバグの修正具合を確認。update2でも変化なし。

（１）自動スリープ後、Ethernetが切れてしまうバグは修正された模様
 　　IPv6では接続できるがv4では接続できない状況になる。
　　未完全な修正だったということで。
（２）画面共有のログイン画面のスリープでスリープできないバグは修正された模様

が、また例によって新しいバグがいる。

 （３）スリープ明け後最初の受信で、メールが高確率で落ちる
メール側の対応漏れかOS側の問題かはわからないが、落ちたらあかん。

どうもスリープ明けの最初の受信メール有り時に高確率で落ちる様子。


（４）DVDプレイヤーで、話の切り替わり目で数秒〜数分が飛んでしまうことがあるバグは治っていない。
　やはりMac go社のMac Blu-ray Playerでは発生しないのでDVDプレイヤーのバグ。
（Mac Blu-ray Player自体もバグだらけなので使いものにならないが。）

（５）スリープ中にリマインダーの通知が来ると、スリープ明けに通知の「閉じる」を押しても閉じない。しかも二度と通知が操作できなくなる。
ユーティリティのアクティビティモニタで「通知センター」を選んで「プロセスを強制終了」すると一応治る。

アップルは少なくとも、まだ５倍はデバッグ要員を増やせ。

Xcode4.5およびiOS6の動作状況はこれから確認。
iOS5/5.1のバグは今回のアプリ開発でだいぶ見つけたのだけど、それらが治っているかどうか。

・・・ついでのXcode4.5の確認・・・

Xcode V4.4.1であったバグが4.5でどうなっているかの確認ちょっとだけ。

（１）Separate Assistant Editorの右側で補完候補がすぐに消えてしまうバグ
やっぱり治ってない。更に悪いことに、Google日本語入力では日本語入力がまともにできなくなった（ことえりでは未確認）。

（２）ソースファイルの改行コードが0x0d+0x0aのとき(Windowsで作っていたファイルを持ってきた時など)、エディターでDelete To End Of Lineを実行すると行末までを削除すると、次の行が接続されてしまう
これは前のバージョンから治ってない。

他は再現させるのが面倒なので省略。今のところ、ファイルの認識間違いは発生していない模様。

後バグじゃないけど、iPhone5対応のため、Launch ImageにRetina(4-inch)が追加されてる。
そのままでは黒画面画像(Default-586@2x.png)を入れられるので、何らかの置き換えが必要。私は、面倒だったので、従来のRetina(3.5-inch)の画像そのまま入れておいた。おいおい書き換えると言うことで。

NSString UIKit Additions のバグ

NSString UIKit AdditionsにあるsizeWithFont:は、文字列を指定フォントで表示した時の表示サイズを求めるメソッドとされている。


ところがこれ、横幅は正しいのだが、縦幅は正しくないことがある。
表示幅が取得値(size.height)より大きいことがあるのだ。

どのような場合にそうなるか。


指定フォントが英字フォントで、文字列に日本語を含む場合がそれに当たる。

この場合、英字部分は指定フォントが使われるが、日本語に関しては代替フォントが使われる。
例えば、標準的フォントとしてよく使われるHelveticaは英字フォントであり、実は日本語は含まない。それでも日本語も表示できるのは、この代替機能があるからだ。絵文字もこの機能によって、どのフォントでも表示できるようになっている。
（フォントが実際のところどの文字コードに相当するフォントを持っているかは、FontBookで情報を見ると分る。）

そして、殆どの場合その代替フォントのほうが大きいので、高さがそちらに合わせられる。
このため、実表示サイズが取得値と合わなくなる。

 sizeWithFontが返してくるのは指定したフォントのlineHeightであり、文字列に含まれるすべての文字を考慮した高さではないのだ。

その代替となっている日本語フォントのlineHeightを得ておけばいいと思うかもしれないが、それがそう単純ではなく、実際に表示される文字だけのフォント幅に合わせられる。
よって、表示文字列が固定ならいいが、文字列が可変なら高さも可変になる。

ということで、現在出来る回避策は、実際に表示させてみるしかない。
例えばUITextView.textに「改行付きで」代入し、その前後でcontentSize.heightの
差分を取る。これなら正確に取得できる。
ただし、.textへの代入の処理はかなり重いので、すべての行の高さを得ようと思うなら、ちょっと工夫が必要である。


アップルは英語圏なので、こういう日英文字混在の条件下ではデバッグされていないのだろう。iOS5.1でも治っていない。iOS6でどうかは未検証。


2012/09/25追記
drawAtPointの返してくる高さも同様と判明。横幅はなぜかちょっと違う。
sizeWithFontの方が小数点以下を切り上げた幅を返してきている感じ。

あと、ひょっとしたらこの問題はUITextView内に表示した時だけに発生するのかもしれない。UITextViewないならフォントの高さなんて気にしなくていいのではないかと思われるかもしれないが、外部表示との同期をかけようとすると問題になる。
それがどういうことかは、次回アプリを見てもらえばわかるかと。

2013/09/29追記
1年ぶりの追記。実はiOS7では contentSize.heightの返す値が全く意味不明になっておりこの方法が使えなくなってしまった。現状回避策は見つかってない。

Macのゴミ箱の中の消えないファイルの消し方

Macで「ゴミ箱を空にする」を実行しても消せないファイルが残ることがある。

（不要になった）TimeMachineのフォルダを削除したときなど、boot.efiというファイルにロックがかかっていて、情報からアクセス権を変更してロックを外そうにも外せず、
この状態になる。

こういう時は、Optionキーを押しながら「ゴミ箱を空にする」を実行すればよい。

たったこれだけで綺麗サッパリ消してくれる。

Xcode 4.4.1とMoutainLion V10.8.1のバグ

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

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

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

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

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

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


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

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


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

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


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

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

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


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

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

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

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

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

（９）日本語名ファイルが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で直った模様。まだ２回だけでの結果なので、もう少し様子見。
V10.8.2でも発生。IPv6では接続できているがV4では接続できない。
うちのプロバイダはｖ６を通さないのでインターネット接続ができなくなる。
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)より多い
まだ不安定な部分がある様子。
１ファイルへの多重アクセスをすると落ちやすいような気がする。
落ちるというか、無反応になってしまう。
Xcodeでタグ上に残っているファイルをDelete-Move trashとかすると一発。


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

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ではコード範囲を限定しているので、全自動。

UTF8とSHIFT-JISコードの特徴

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

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

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

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

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


・・・

さて、X-BASIC for iOSの開発でUTF-8の文字コード(正確には文字エンコード、らしいけど)についてかなりだいぶ理解できたと思う。
SHIFT-JISに関してはその誕生時から見ていて、X1-ｔurboから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上で英語圏発祥の処理を多国語化するに良いコードだと言えよう。

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

UTF8-16変換処理の抜け

先に発表したUTF8-16変換処理でdefine関数の部分の定義が抜けていたので公開。

#define b32(w)  (((w)&0xff000000)>>24)
#define b24(w)  (((w)&0x00ff0000)>>16)
#define b16(w)  (((w)&0x0000ff00)>> 8)
#define b8(w)  ( (w)&0x000000ff)
#define w16(h,l)   (((h)<<8 data-blogger-escaped-define="define" data-blogger-escaped-hh="hh" data-blogger-escaped-hl="hl" data-blogger-escaped-l="l" data-blogger-escaped-lh="lh" data-blogger-escaped-ll="ll" data-blogger-escaped-pre="pre" data-blogger-escaped-w16="w16" data-blogger-escaped-w24="w24" data-blogger-escaped-w32="w32">

UTF16をUTF8に変換する処理

今度はUTF16をUTF8に変換する処理。

実を言うと、UTF16はあまり使い道がない。と思う。
->とか書いてたけど、実はiOSの中の文字コードはUTF16だと判明。
characterAtIndexで返ってくるコードはUTF16である。
UTF8だと思って処理を書いてたらうまく動かないので調べたらそうだった。
(後日アップルのドキュメントを読み返したら、UTF16だとちゃんと書いてあった。
でも、あんなところに１行だけでは気が付く人少ないのでは？)
ただし、ソースコード(その中に記述する文字列)そのものはUTF8でなくてはならない。
ここは少しややこしいところ。

SHIFT-JISは、組み込み機器ではプログラムもデータも小さくなるので非常に使いやすい。
表示幅とバイト数が一致するのもいい点である。
UTF8はASCIIコードとの互換性が高く、ASCII用のプログラムを移植するに都合がいいことが、X-BASIC for iOSの開発でよくわかった。

SHIFT-JISとの変換に関してはUTF16の方が行いやすい。

ulong Utf16ToUtf8(ulong n)
// http://ja.wikipedia.org/wiki/UTF-8 参照
// Unicodeは文字コードの総称で、UTF-16やUTF-8はその表現方法の種類、である。
{
 if (n<=0x7f) return(n); // ASCII互換
 if (n<=0x7ff) {
  // 8421 8421   8421 8421
  // 110x_xxxx | 10xx_xxxx
  return  w16(             (0xc0|(n>>6))   , (0x80|(n&0x3f)) );
 }
 if (n<=0xffff) {
  // 8421 8421   8421 8421   8421 8421
  // 1110_xxxx | 10xx_xxxx | 10xx_xxxx
  return w24(       (0xe0|((n>>12)&0x0f)) , (0x80|((n>>6)&0x3f)) , (0x80|(n&0x3f)) );
  
 }
 // n<=0x1fffff
 // 8421 8421   8421 8421   8421 8421   8421 8421
 // 1111_0xxx | 10xx_xxxx | 10xx xxxx | 10xx xxxx
 return w32( (0xf0|((n>>18)&0x07)) , (0x80|((n>>12)&0x3f)) , (0x80|((n>>6)&0x3f)) , (0x80|(n&0x3f)) );
 
 // 定義上はこれ以上もあるが、実在しないので省略
} 

UTF8の文字コードをUTF16に変換する処理

しばらく忙しすぎて更新できてなかった。
理由は、どスランプとか開発作業とか。
中核の処理は動くようになったが、まだiOSへの対応については手つかず。
ずっとWindowsのCygwin上で開発してたので、Xcodeも忘れてしまった(^_^)。
まずはその思い出しから始めないと。

ということで、超久しぶりの更新は、そのプログラム中で使っている処理を１つ。
UTF8の文字コードをUTF16に変換する処理。
ただし、UTF8で32ビットの範囲に収まるコードのみ。

UTFまわりの処理はインターネットで探しても 意外と見つからない。
最近はOSや言語レベルでサポートされているようで、
Cでの記述、というかフローが正確にわかる物が無かった。
ということで、公開。

ulong Utf8ToUtf16(ulong b)
{
 if (b<=0xff) return(b); // ASCII
 if (b<=0xffff) {
  return (        (b16(b) & 0x1f) << 6) + (b8(b) & 0x3f);
 }
 return ( ((b24(b) & 0xf) << 12) + ((b16(b) & 0x3f) << 6) + (b8(b) & 0x3f) );
}

C言語；ポインターの増減

C言語のポインターに対する演算の結果について。
しばらく使わないと忘れてしまうので覚え書き。

long  *lp=0;
short *wp=0;
char *cp=0;

としたとき、それぞれを++した時の実アドレスは、
lp++ == 4
wp++== 2
cw++== 1
である。

同様に、
&lp[1]のアドレスは4
&wp[1]のアドレスは2
&bp[1]のアドレスは1
である。




同じ演算子でも、ポインターの型によって得られる実アドレスが異なる。

アセンブラーでアドレスを演算する場合にも変化が伴うことがあるが、
Cとは結果が違う。

たとえば680x0MPUでは、
a0.l=0のとき、
move.l d0,(a0)+  　→　a0=4
move.w d0,(a0)+   →　a0=2
move.b d0,(a0)+   →   a0=1
であるが、

move.l d0,4(a0)
move.w d0,4(a0)
move.b d0,4(a0)
はいずれも4番地からにデータを書き込む。
自動インクリメント(またはデクリメント)は大きさを考慮するが、オフセット指定は
大きさは関係ないと言うことである。

通常加算は大きさを考慮しないので、
addq.l #1,a0
addq.w #1.a0
はいずれもa0=1となる。

アセンブラとC言語の両方に精通していると、C言語におけるポインターの演算結果を
迷うことがあったりするので、注意。

Windows7のデスクトップガジェットの強制的な削除仕方

Windows7でデスクトップガジェットを使っているとき、まれにその起動が出来なくなることがある。

ガジェット内部でエラーを発生してしまうと、そのエラーを起こしたガジェットだけでなく、登録している全てが落ちてしまうようだ。うちでは、IO-DATAのDrive Centerがこの状態になって往生した。

いったんこうなってしまうと、コントロールパネルのデスクトップガジェットも開けなくなり、通常ではどうしようもなくなる。
この場合、

c:\Users\ユーザー名\AppData\Local\Microsoft\Windows Sidebar

にあるSettings.iniをテキストエディタで開き、エラーを起こしていると思われるガジェットの設定を削除する。

削除対象は、[Root]タグ内にある
  Section?="?"
というセクション名の登録、
[Hashes]タグ内にあるプログラムの登録と、
[Section?]タグの内容そのものである。

念のため、編集前にはバックアップをとっておいた方が良いであろう。

また、同\Gadgets\の下にガジェットのプログラム本体(のフォルダ)があるので、場合によってはそのフォルダも削除する。

いや、ガジェットが落ちるようになってしまったけど、解決に関する情報がどこにもなくて、
いろいろやっている内に発見した。同様なことで困ったいる人がいたら、どうぞ。

Xcode4.3.2のバグ修正のチェック結果

ようやく公開されたので、現在調査中。

・・・

なんかうまく動かない。
V4.3.2自体が正常動作しない上に、V4.2.1までも動かなくなってしまった。

ということで、全部再インストールする羽目に。

アップルはいったいどういうチェックをしているのだ?
クリーンインストールの機体だけしかチェックしていないのではなかろうか?

→なんかまたインストールされ方が変わってる。

・・・
再インストール後チェック。

(1)iPadシミュレーターの枠がない(HOMEボタンが表示されない)のは仕様
(2)[[UIDevice currentDevice]systemVersion]が@"Unknown”を返してくるバグは修正された
(3) ビルトインマクロ__VERSION__は"4.2.1～"のまま。
"4.2.1 Compatible Apple Clang 3.1～"になってる

(4)実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けするバグは修正されていない。

(5)日本語ファイル名があるとgitでcommit出来ないバグは修正されていない

(6)OrganizerのArchivesでアプリのアイコンが表示されないバグは修正された
(7)DistributionのCodeSigningが外れるバグは修正された

(8)シミュレーター上のUITextView/UITextFieldで落ちるバグは修正された

(9)WiFi接続のデバイスの検出機構(iOS Device DiscoverryのSupport Wirelessly Connected Devices)がなくなった
問題が多かったから？


ということで、重大なバグは修正された模様。一応開発に使えるレベルには戻った。

でも全てのバグは直ってない。

早よ直してくれ。

methods named 'xxx' found

プログラムを組んでいると、「methods named 'xxx' found」という警告がいくつか出た。

直訳すると「xxxという名前のメソッドが複数見つかった」となろうが、
それならエラーになるはずではないか。


よくよく調べると、id型のクラスインスタンスに対してメソッドを発行しようとすると
発生する（ことがある）とわかった。

「例」
タッチイベントを処理する
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
 NSTimeInterval tm=[[touches anyObject]timestamp]; // ここでmethods named 'timestamp' foundが発生する


}

touchesに実際に格納されるのはUITouchであるが、[touches anyobject]はid型で返す。
timestampという名前のメソッドは複数のクラスが持つので、
どれか解決できずに警告が出てしまう。

実行時にはNSSetの内容は決定しているので、[touches anyobject]のidが実際は何であるか、
この場合UITouchであることがわかっているのでtimestampを呼び出す先もわかる＝実行時エラーはでないのである。

警告を回避するには
 NSTimeInterval tm=[(UITouch *)[touches anyObject]timestamp];
として型を確定してやればよい。ポインター型でキャストすることに注意。

Xcodeのエラーコードはわかりにくい(その上ドキュメントがない)ので困る。

The new iPad

「The new iPad」が届いたのでちょいと感想など。

Xcodeでつなぐと「iPad (3rd generation)」と表示される。
なら「iPad3」でいいじゃん、と思ったりもするのだが、
まあ、こだわりがあるのだろう。

で、ちょっと触ってみた感じのiPad2との違い。

• 文字がきれい。これは今回の一番の売りのRetinaDisplay(解像度倍)だから当然だけど、目に優しく感じる。
• iPhoneモードの2倍表示がきれい。従来のiPadにもiPhoneモード2倍表示はあったけど、単純拡大で文字はがたがただった。これが改良されたのか非常にきれいになった。iOS5の改良項目かと思ったが、iPad2では今まで通りだったので、3の特徴と言える。
• 音が良く聞こえるようになった。スピーカーの位置は同じだけど、音ははっきりしている。スピーカーそのものが良い物になったか。
• グラフィックを使う処理にもたつきがなくなった。iPad用のゲームで少々もたつきがあったゲームが、3では全くもたつかない。3はCPUの能力はほぼ同じだが、解像度倍に合わせてグラフィックの能力があげられているので、iPad解像度のゲームは恩恵を受けてこうなっているようだ。3専用ゲームではそうはいかんだろうけど。
• 背面カメラの画像が格段に良くなった。PCの画面を撮影しても今までは文字が読めなかったが、3でははっきり読める。ただ、モアレの発生はかなりきつい。
• 重さは、カタログ上は初代iPadと同じに戻ったらしいが、手に持った感じではiPad2と変わらなく思う。
  多分に、厚みが変わっていないからだと思う。
• 外観上の違いはほとんどない(だからここにも写真を載せなかった)。あえて言うなら、背面カメラのレンズ径が倍くらい大きくなったのと、規格適合マークが大きく変わったことくらいか(iPad2はVCCIなど国内規格マークだったが、3はFCCやCEなど海外規格のみになっている)。両方持っている人は、自分でわかりやすいようにシールでも貼った方が良いかもしれない。

そんなところ。

開発用実機の接続について

Xcodeで開発用実機を「USBケーブルで」接続する場合、
本体のUSB端子もしくはそこに差したUSBハブからでなければならない。

USBハブにさらにハブをつなぎ、そこに差したケーブルで実機を接続すると認識してくれない「ことがある」。してくれることもあるが、不安定。
USBハブの種類というか構造にもよると思うけど。

Xcode4.2ではWiFi接続も出来るけど、また使ったことがない。
どんなもんだろうか？
→Xcode4.3.2ではWiFi接続機能は削除された。

Lionの壁紙が起動毎に初期化されてしまう・・・ように見える

Lionにしてから、壁紙が起動（またはログイン)毎に初期化されてしまう(Andromeda Galaxyになる)という問題が発生した。

調査の結果、以下のようにすれば解消されると判明。

(1)システム環境設定～デスクトップを開き、各画面に違う壁紙を設定する
そのときの各画面の壁紙名を控えておく

(2)Fiderからライブラリ～Preferences～com.apple.desktop.plistを開く
(3)BackGroundの下にある、0以外の数字だけの項目が画面別壁紙設定 なので、全てを開き、
　　(1)で 設定した壁紙名「以外」の設定の入っている項目を全て削除(Cut)する
    spaces/default/0は消さないこと。

これで直る。

・・・修正。
初期化されたのではなく、表示されるページが変わっていたと判明。
デスクトップを複数用意している場合、背景(バックグラウンド)はデスクトップ毎に設定できる。
そのため、別のページが表示されると背景がおかしくなったように感じる。

上の処理をすると壁紙は戻るが、消したデスクトップに配置していたアプリの画面情報も消えるので注意。

なお、デスクトップの追加はMissionControl表示中、物理画面の右上あたりにマウスカーソルを持って行くと「＋」が出るので、これで行う。
MissionControlは本当にわかりにくいし、操作しにくい。

ExposeとSpacesに戻して欲しい（可能なら切り替えでも良いので両方使えるようにして欲しい)。
ちゃんとユーザーの声を聞け、アップル。