ディレクトリの概念

コンピュータ言語の中で理解しづらいのにポインタというのがありました。
しかし、UNIXに変わりディレクトリが導入されてから、見方が変わりました。
UNIXのファイルシステムにはiノードというものがあり、そのテーブルの中のファイルにはみんな番号が振られています。ちなみに前に上げた、TextInputViewで説明すると、ターミナルで次のコマンドを打ちます。移動コマンドのcdで前のディレクトリに移動します。$ ls -iaR TextInputViewを打ちます。ターミナルはbashです。すると、

TextInputView/build:
3069456 . 3069470 Debug
3069428 .. 3069457 TextInputView.build

TextInputView/build/Debug:
3069470 . 3069471 TextInputView.app
3069456 ..

TextInputView/build/Debug/TextInputView.app:
3069471 . 3069470 .. 3069472 Contents

TextInputView/build/Debug/TextInputView.app/Contents:
3069472 . 3069473 Info.plist 3069474 PkgInfo
3069471 .. 3069510 MacOS 3069475 Resources

TextInputView/build/Debug/TextInputView.app/Contents/MacOS:
3069510 . 3069472 .. 3069515 TextInputView

TextInputView/build/Debug/TextInputView.app/Contents/Resources:
3069475 . 3069476 English.lproj
3069472 .. 3069477 README.rtf

TextInputView/build/Debug/TextInputView.app/Contents/Resources/English.lproj:
3069476 . 3069479 Localizable.strings
3069475 .. 3069504 MainMenu.nib
3069480 InfoPlist.strings

TextInputView/build/TextInputView.build:
3069457 . 3069458 Debug
3069456 .. 3069519 TextInputView.pbxindex

TextInputView/build/TextInputView.build/Debug:
3069458 . 3069459 TextInputView.build
3069457 ..

TextInputView/build/TextInputView.build/Debug/TextInputView.build:
3069459 .
3069458 ..
3069461 Objects-normal
3069466 TextInputView-all-target-headers.hmap
3069467 TextInputView-generated-files.hmap
3069468 TextInputView-own-target-headers.hmap
3069460 TextInputView-project-headers.hmap
3126726 TextInputView.dep
3069469 TextInputView.hmap
3069517 TextInputView~.dep
3126725 build-state.dat
3069516 build-state~.dat

TextInputView/build/TextInputView.build/Debug/TextInputView.build/Objects-normal:
3069461 . 3069459 .. 3069462 i386

TextInputView/build/TextInputView.build/Debug/TextInputView.build/Objects-normal/i386:
3069462 . 3069509 FadingTextView.o
3069461 .. 3069463 TextInputView.LinkFileList
3069508 Controller.o 3069507 main.o
3126724 FadingTextView.mi

TextInputView/build/TextInputView.build/TextInputView.pbxindex:
3069519 . 3130355 pbxindex.header
3069457 .. 3130354 protocols.pbxbtree
3130352 categories.pbxbtree 3130351 refs.pbxbtree
3130350 cdecls.pbxbtree 3069520 strings.pbxstrings
3130349 decls.pbxbtree 3130353 subclasses.pbxbtree
3130347 files.pbxbtree 3130346 symbols0.pbxsymbols
3130348 imports.pbxbtree

TextInputView/build/TextInputView.build/TextInputView.pbxindex/strings.pbxstrings:
3069520 . 3069519 .. 3130344 control 3130345 strings

一部抜粋ですが、こう出て来ます。これはターミナルからしか見る事が出来ません。
このコマンドは、Bruce Molay氏の著書であるUnix/Linuxプログラミング理論と実践の中から参照しています。

.　はそのディレクトリ(フォルダー)の番号で、..　はその上のディレクトリの番号でありリンクしています。
Finderでは、.　は、そのものフォルダーとして見えます。
..　はその四角のエリアであり見えますが、通常意識する事はありませんし、その上のフォルダーでもあります。
システムから見ると、この番号が無ければファイルの階層が分からなくなるという訳です。..　はHTMLでも使われています。

Objective-Cに、よく使われる表現に、
NSString *XXX , NSArray *XXXとかあります。ポインタと呼ばれる*　はコンパイラーが割り振るアドレスであり、XXXの部分の内容は後で変更可能な中身と言えそうです。私も大した自信があって言っているのではありませんから、参考程度にです。
NSで始まるクラスはクラスタクラスと呼ばれ、インスタンスを作成でき、それを変数として持つ事ができ、サブクラスとして振る舞う事が出来る、とあります。
Objective-Cには、デリゲートという親クラスがサブクラスに振る舞いを任せてしまう方法があります。そうすれば、親クラスは支障無くもっと多くのサブクラスを持つ事が出来ます。

こういった概念は、やはりUNIXならではのディレクトリの概念から来てるのだと思います。

タグ：ポインタ UNIX Objective-C ターミナル ディレクトリ コマンド

Objective-Cって何

暗い話ばかりでは、身にこたえますので、少し話題を変えてアップルのコンピュータ言語についてに変えました。
Macを買えばもれなく付いて来るXcode,Interface Builder。これを生業にしている人もいるでしょうけれども、私の場合、Objective-Cの解説という訳でもなく、単なる思い付きで、だらだらと述べるだけですので、興味の無い方は見ない方が良い程度のものです。
解説書ならいっぱい有りますし、ネットで探してもたくさん有ります。

調べていたらXcodeは、バージョンが4にアップされていて最新のサンプルコードはコンパイルできない事を知りました。このバージョンは有料で、600円(会員だけ？)。安いとは言え、売り物を作る気はなく、突っ込んで行くと悩まされそうなので、止めました。
アップルのやり方はいつでもそうです。そうゆう意味ではウインドウズの方が優しいのかも知れません。
だいいちObjective-Cはマックでなければ使い道はなく、そうゆう意味ではマイナーな言語です。
JAVAやC/C++とは、一線を越えます。
今携帯はiPhoneが発売されて以来スマートフォンに変わって来ました。アプリソフトで言えば、iPhone,iPadが群を抜いています。
今回のバーションアップは、このアプリケーション開発のためのものと判断しましたが、私には大分敷居が高い事が分かりました。実に圧巻です。

しばらく使ってなかったので、使用が様変わりしてしまったようです。無償版バージョンは、Xcode3.2.6でSDKがiOS SDKになっていました。一応会員なのでダウンロードしました。今インストール中ですがMacProなのに、時間がかかります。何がどう変わったのか早く見たい。

見たら殆ど変わりませんが、サンプルコードの中には、SDKがiOS SDKでないとやはり不具合がでるみたいです。

さてObjective-Cの構文ですが、C言語の拡張または延長線上にあるので、C言語の理解は必要です。
また土台(Foundation)が、unixのDarwinなので、ディレクトリの概念も理解しておかなければなりません。ダーウィンは殆どがC言語でできていて、ターミナルコマンドもC言語で出来ています。ではC言語との違いはと言えば、何と言ってもコンパイラ指示子@interface,@implement,@endではないでしょうか。
@で始まるものには他に
@public,
@protected,
@private,
@package,
@class,
@selector
@"…"等などC言語ではありません。つまり使える記号をふんだんに使った言語なのです。
次に　[レシーバ(obj)　メソッド:argument(論拠？)]　という通信手段です。
C言語では[ ]は、配列にしか使いませんが、空白を使う事に依ってコンパイラーは区別できます。
しかし、この空白はCでも使っています。例として#define DELAY 2とすれば、DELAYに２が代入されます。だったら最初から２を使えば良いかと言うと使い物になるソフトとなるとコードが長くなりますし、どこかでもう一つ２がでてくれば、どっちの２か後で迷ってしまいます。

対で使う記号には他に、
< >　は、主にインポートするヘッダーファイルを括る。
例：#import HTMLやXMLでも使われますが、意味合いが少し違って来ます。例えば、＜head＞…＜/head＞のように、< >で内容を指定して更に細かく内容を指定して、最後に＜/＞で終了した合図を送りますが、Objective-Cの場合読み込んだファイルを保持するだけです。共通して言える事は、< >の中の文字は表示されないとも言えます。 { }　は、大構文で使われます。例として @interface MyObject : NSObject { } ちなみにHTMLの場合、使われる事はありません。＜／＞があるからです。 ( )は、使われ方が色々です。 まずはメイン関数。例として、 int main(int argc, char *argv[]) { return NSApplicationMain(argc, (const char **) argv); } 次は型を指定する時。例として、 - (id)initWithFrame:(NSRect)frame {…} 後は、予約語と呼ばれる関数として、例としては、 if (…),for (…),while (…)… 最後に、C言語では自分が作った関数にも( )を使いますが、Objective-Cでは、NSであらかじめ用意した関数でしか使いません。例としては、 NSMakeRange(0,0) 特殊と言えば、関数の前に使われる-,+の記号があります。 +は、動的バインディング時にクラスのインスタンスを作成することらしいのですが、抽象的で分かりにくい概念です。-は他の関数と言う事でしょうか。System/Library/Frameworks/...framework/Headers/のヘッダーファイルを眺めていれば区別がはっきりするかも知れません。 後は何もしなくてもビルドすればwindowだけは立ち上がるということです。前のMac OS9迄はCode Warriarと言うコンパイラーソフトを買い、ウィンドウを立ち上げるだけでも大変でしたが、オブジェクト指向と叫ばれてどんなOSが出来るのかなあと思っていたら、こういう事だったのですね。 これだけ分かってプログラムが組めるかと言うと、ドレミファソラシドが引ける程度でしょうか。 もう一つ理解しなければならないものに、インターフェイスビルダーがありますが、これがなかなか参考書も無くビジュアルで分かり易いのかと思いきや、いざビルドすると失敗し場合、何処が悪いのか探すのが難しくなります。 ここでアップルが用意している簡単なサンプルコードで、説明したいと思います。 ここでは作られたコードは、ControllerとFadingTextViewしかありません。 MainMenu.xibはこんな感じです。 こんな感じでしょうか、早速ビルドしてどうなるのか試してみます。 ここでは、最初のMainMenuに無かったSpecial Characters…が追加されています。これを選択してみると文字ビューアが出て来て2200番台からの数学演算子がでて来ます。それを入力すると こうなりました。 でも可笑しいですねえ。Special Charactersは、何処から出て来たのでしょうか。いくらコードを追っても無いし、inspectorで探してみてもありません。これは成功した例なので、どこかに表示する仕組みがある訳ですが、このように参考書もないので隠れたところの動きは理解できないし、間違いも探しづらいのです。 誰か分かる人が居れば教えてほしいのですが、このサンプルは単純な方ですがここ迄です。

タグ：プログラム XCode Objective-C インターフェイスビルダー

メルトダウン

今頃になってメルトダウンだと言われても、実際問題困った話である。アメリカのスリーマイルの事故の時は、半径40kmを目安にしていたと思いますが、なぜ半径２、30kmなのでしょうか。
政府が100億円投じたとするSPEEDIも何の事か、正しい情報なのか単なる隠蔽工作なのか分かりません。第一気象庁の発表する風向きは、かなり上空のようで、地上での風向きとは逆な時がたびたび有ります。
今日のニュースでもセシウムは、茨城、千葉、東京、神奈川でも、基準値を超える線量が観測され、足柄の茶畑では葉を捨てているとか。
この被害は、始まったばかりであり拡大こそすれ、縮小はしないと思います。こうした被害を受けた人達を中傷している訳では有りません。
最近気づいたのですが、私は被爆した父から生まれた子供だったようです。広島にアメリカが原爆を落としたその日、父は呉の軍事工場に居たそうです。地図で見れば、呉と広島は、20kmと離れていません。映像で見る限り、半径40km圏は被爆の対象になりそうです。終戦となり田舎に戻って来て、出来た子供が私なのです。私が物心ついた時には、父にはある特定の病状が有りました。食事を受け付けない、アレルギー反応です。薬は手放せない人でしたが、医者がどう判断していたかは分かりません。
父はもう癌で亡くなりましたが、戦災の傷跡は私にも及んでいます。特に皮膚病です。まあ自分の事は良いのですが、今回被爆された方々がどの程度なのか、避難先での生活はどうなるのか、現状を把握するには、政府の口先三寸の言葉より、自分で判断した方が間違い有りません。
政府の対応は、今迄見て来た通り隠蔽工作です。最初原発で爆発があった時、水素爆発だとしたのでメルトダウン（炉心溶融）ではないと言えましたが、その後爆発は無かったので、放射線は出て来るはずが無いのに、観測されていました。誰が考えてもこれはメルトダウンでなければ起こりえない事象であり、後になり、レベル７に引き上げ、二ヶ月過ぎてからメルトダウンが起こっていると発表し、より多くの放射能を浴びた上、避難地域に指定されるという危険にさらされました。これは、ある種の隠蔽を行っている結果なのです。

原爆の恐ろしさ知ったはずの日本人が戦争の反省も無く、第一流国を目指して国債を乱発し原発の開発を押し進めて来ました。何事も無ければ、成功と言えたかも知れませんが、結果は大失敗です。
残ったのは、借金と放射能汚染と加害国としてのレッテルです。
かつて北の核と言って恐れられた北朝鮮ですが、これも昔話です。結果論としては、一番恐ろしかったのは自国の政策であり、政府であり、議員に置き換わりました。戦後の歴代総理大臣は皆責任があります。

今も国会中継を見ていますが、どうやって冷温停止しようとするのか有効な手段を示せません。放射線量が高い中、気温が夏に向かって高くなる中、人介戦術をいつ始めるのか、まるで分かりません。もう作業員に死者が出ていて、原因が放射線でないとされていますが、これも曖昧です。
いつ迄も、この状態を維持できると考えては行けません。原子の崩壊が進み中性子が増える中、制御棒が働かなくなれば、待っているのが再臨界で起きる中性子爆発です。これには色々な学者の見解があり、水の代わりに液体ホウ素や窒素を入れると防げるらしいですが、循環してませんので一時的な方法です。
圧力容器が既に穴があいているとすれば、原子炉格納容器が最終容器になるので、この容器での循環も考えなければなりません。温度が100°C以下とされていますが、どうも信じられません。一号機の発生している水蒸気量は今はまだ大した事が無いようですが、これが沸騰した状態になれば、もう手を付けられません。その前に何としても循環型熱交換器を設置してほしいのですが、無理でしょうか。

話は変わりますが、今回の原発の事故は東電の責任なんでしょうか。確かにある程度の責任はあるかも知れませんが、その建設を許容して来たのが、政府だったのではないでしょうか。つまり全ての機関の談合であり、安全神話をでっち上げれば、処理できるとした利権者の責任では無いのでしょうか。私には東電の社長ばかりを攻めるのは筋が違うし、保証と言ったって東電の清水社長の責任は関係者の中の一人分でしかないのだと思います。だから責めたところで問題は解決しません。東電はこれから本領を発揮してもらなければならない時、やる気をなくすような悪言雑言は、事態を更に悪化させます。

赤信号みんなで渡れば怖くない！はもう通用しないのです。生き延びたいのであれば、自己判断でしなければ、今後も同じことが起こります。自分の住む地域を見直しましょう。

タグ：メルトダウン 国会中継 レベル７ 水素爆発

西日本のプレート

北の方はある程度理解できましたが、では西日本のプレートはどう理解すれば良いか一例を考えました。プレートの重なりを見れば、フィリピン海プレートの日本に近い伊豆・小笠原海溝と南海トラフの間には大きな大陸が在ったようです。ではそれはどこから来たかと考えると、韓国の北東のようです。
しかしそれでも足りなくて、今度は北朝鮮の北東から第二陣が移動して来ます。その時出来た山地が、九州の大分県の佐賀関半島から愛知県の渥美半島迄続く直線的な山地です。名称では、九州山地、四国山地、紀伊山地で当時は連続していたはずです。
そこへオホーツクプレートがぶつかって来ます。そうすると玉突き状態となり、最初にあった大陸は逃げ場が南にしかありません。太平洋プレートの移動を止めながら、諸島を作りながらパプアニューギニア辺りで消滅したか、島の一部に取り込まれたかGEでは余りはっきり分かりません。

残りの大陸、今の西日本は文字通り玉突き状態となり、先端の方の九州が今の山口県と広島県から離れて、南西に移動します。四国も今の岡山県、兵庫県、大阪府、和歌山県から移動します。でもそれだけでは、今の四国のような形にはなりません。一つ抜けているパズルが有ります。台湾です。台湾を土佐湾と日向灘の間にあった大陸とすれば、問題解決です。位置的には一番海溝に近く南下し易い状態だったのです。
さあ、これで日本の地形が粗方説明できます。ぶつかって来たオホーツクプレート側は、直接ぶつかったところは、高い山々を作りますが、ある程度離れた所では振動としての戻りも有ります、東西に走る山地です。東北の西側には、県境ごとに山々があります。この振動に依る伸縮で南北にも山脈が出来たとすれば日本列島ジグソーパズルの完成です。

タグ：西日本のプレート オホーツクプレート

オホーツクプレート

北米プレートと呼ばれるプレートに乗ってる日本の地形を見ているのですが、どうもこれでは、どうしてこんな地形になったのか分からないので、オホーツクプレート全体迄広げてみました。
これからはジグソーパズルを完成させるようなものです。今オホーツク海に面したロシアと呼ばれる大陸に大きく引っ込んだ場所が有ります。アムール川河口の北側です。この部分に最初にくっ付きそうなのは、樺太(サハリン)です。反時計回りに45°回転させて北へ移動させれば可能です。その次が南側の隙間に北海道が入ります。その南に青森と三陸地方が付きそうです。その東側に福島の浜通地方、その東側にカムチャツカ半島をくっ付けると粗方一つの大陸になります。では残りの日本の陸地はと言うと、その東側、つまりカムチャツカ半島の脇と言いたいところですが、地形が合いません。がこれには、何万、何億年もの経過が有りますから、軽く見捨てる訳には行きません。ましてカムチャツカ半島の東側は、地震活動の活発なところです。
ですので、そうだと過程して考えて行きます。
そうすると何が言えるでしょうか。今の千島・カムチャツカ海溝、日本海溝に向け移動して来た事になります。
移動の順番ですが、カムチャツカ半島を含む本土の大陸が動きやがて本土と分裂して、西日本とドッキング、それでも足りなくて北海道と青森と上北高地を含む三陸地方と、阿武隈高地を含む浜通地方が南下。これは少し大きすぎて、浜通地方がまず分裂して、更に南下し、本土とドッキング、最後に青森と上北高地を含む三陸地方が分裂して本土とドッキングしたとすると巧く説明できます。これには大分迷ったし、色んなパターンを考えましたが、一つの例として上げました。証拠としては、グーグルアースで見ると、襟裳岬付近の海岸線には、両岸とも何かが移動した痕跡が残っています。又リアス式海岸線の先端部分の岩はほとんどが北を向いてます。そうだとすると、面白い事に最後に移動したのが三陸地方な事になり、大げさに言えば、一番出来立ての地殻だということです。何か変動が有れば一番狙われ易い事を意味します。樺太はその後北海道につられて移動して来たとしても、プレートの動きを止める海洋灘はもう出来てますから、そんなに動けません。

かつて北海道は本州と繋がっていたと仮定していましたが、ちょっとそれとは別物になってしまいました。
でも何故移動しなければならなかったのでしょうか。しかも北の方から。
ここも遠心力と重力が関係します。また地球は完全な球になろうとします。一つの大陸から分裂して西、東と分かれて行ったとすると、最終で合流します。しかし、完全なる球体は出来ないようにズレが生じます。太平洋プレートが東から西へ移動して来た場合、それを止める方向に大陸が移動します。その時出来たのが、千島・カムチャツカ海溝、日本海溝だとすると説明が付きます。しかし、移動にはブレーキは有りませんので、巧い具合に止まりません、盛り上がりは過剰になります。
今回の地震は、この余剰分を吐き出す地震だとすると、平らにならない限り何度でも起きる事を想定しなければなりません。つまりオホーツクプレートの太平洋側の地域は、今後も津波、地盤沈下は、避けられません。そのリスクを全く考えないで戦後の日本は発展して来ました。経済ばかりを追い求めて来ました。先人の教えも守られない有様です。そうゆう意味では今回の震災は人災と言えない事も無いのです。

タグ：オホーツクプレート リアス式海岸 カムチャツカ半島 アムール川