地球に住んでいれば衣食住が足りれば生きていけますが、火星には呼吸可能な十分な気圧の大気が無いので、一番の悩みの種になるでしょう。与圧された部屋の外に出るには気密服（宇宙服）の着用が必要。
火星の重力は地球の約４０％と小さいが、ISSで使われている宇宙服は１２０ｋｇを超え、火星でも５０ｋｇ近い重さになる。また身体と宇宙服の間に隙間があるため重力下では服の重量が皮膚の一部に集中し一層重く感じるハズで軽量で身体にフィットする圧迫式が出来上がるまでは歩くのも重労働で、与圧された施設から外にでる機会は意外と少ないだろう。
その施設の建設はどうするのだろう？
気密服を着用しての作業で難しいのであれば、まず巨大な風船を膨らませ、その中で作り上げるしかないでしょうし、農作物栽培や広い作業場などは風船そのものを施設として使われるのかもしれません。居住区などはしっかりとした気密設備を別に作るでしょう。
動力源は？
呼吸に適した大気が無いので内燃機関は使えないから、主にバッテリーを頼ることになる。
バッテリーの充電は？
大方の発電は大雑把に云えば「モーターの軸を回すことで電力を供給」しています。火星でモーターの軸を回し続けられる現象（風、水流など）があれば容易に発電が可能ですが、無さそうなので、ソーラーパネル一択の様です。
しかし、車をバッテリーだけで動かすのでは行動範囲も時間も短く、充電時間もかかります。なので、ソーラーパネル付バッテリーをいっぱい地面に並べておく場所をバッテリースタンドとするのも手です。一見馬鹿げた話ですが、巨大なソーラーパネル発電所を建設し送電網で充電スタンドを繋ぐシステムの構築はとても大変ですしメンテも大変ですし、メンテ中は送電もできないでしょう。それならいっそ空になった車のバッテリー（ソーラーパネル付）を地面に撒き、フル充電になった頃に回収し車に取り付ける方がお手軽で充電待ちの必要もありません。いつでもどこかにフル充電のバッテリーがある思える安心感があります。緊急時にはかき集めることもできます。但しいっぱい持っていく必要があります。
 

バイトコードとも云う。
ＣＰＵが直接実行できる機械語（バイナリーコード）の多くはＣＰＵのメーカーやシリーズごとに違っている。その理由はプログラムを載せるメモリは昔からアクセス速度が遅く、かつ小容量で、かつ高価であったので、使用頻度が多い命令ほど短く作られ、また少ない機械語で多くのことができる方がお得だったので、どんどんと入り組んだ進化の道を進んでいったためである。
これに対して中間コードはプログラムが読みやすいように作られている。
命令（４ビット）レジスタ指定（０～１４）（４ビット）
命令（４ビット）メモリ指定（０ｘｆｆ）（４ビット）　＋　メモリアドレス
な感じ。
一時期はＣＰＵチップの中に多くのレジスタを配置し、遅いメモリをアクセスするよりも速く処理できることがよしとされた時期もあるが、今ではＣＰＵチップに６Ｍバイトのレベル３キャッシュまで載るようになっているので、スタック演算マシンでもそれほど遅くなくなってしまったので・・・
今回はスタックマシンとしてバイトコードを作ることにする。
つまり、Add命令にはレジスタ指定もなく、Add(0x01)となり、演算系の命令は0x01～0x0f となり、最大１６種類（Not-Operationを含む）の演算が可能になる。
スタック命令は、PUSH(0x11)、POP(0x12)、CALL(0x13)、RETURN(0x14)の４種類とスタック上の任意の位置のデータを転送する命令(0x15)で、データもlong(8byte)のみ操作可とする。
後はIF(0x16)とJUMP(0x17)命令があるのみ。
さてそうなると、スタックに０や１をどうやってセットするのだろうか？
実行直前に０や１を設定済みの外部変数を全てスタックするようにできればいいが、各外部変数にアクセスするための命令が必要だし、外部変数を持ついくつかの中間コードを組み合わせる場合を想定すると実行前に全ての外部変数をスタックに積む必要があり、ダイナミックに中間コードを増強できない可能性が高いので、実行コード、外部変数、スタックを分けてメモリに配置することが多い。
ここではそう面倒なことは考えず、作った中間コード相対アドレス参照モードを用意し、各外部変数を読み書きする命令(0x18,0x19)として実装する。多分、異なる中間コードファイルのコードを実行するCALL（その２：0x1a）も必要だろう。
さて次は例外処理の実装である。
あの try ～ catch ～ finally ～だ。
しかし関数内の関数として実装してしまえば、CALLとRETURNとIFで代用できるが、スタックが進むので、それならforやwhileも同様の実装でいいだろう。
と適当に並べてみた。
あとは、どこで使うのか？
スキリプトの正規化表現と文法の定義テキストは左辺と右辺だけではなく、その右側に対応する中間コードの生成を定義することで、中間コードが勝手に作られるようになる。
 
 
 
 
 

『新天地』その言葉には胸躍るものがありますね。
しかし、『新天地』が火星だったら・・・
それでも、マーズワンの火星移住計画に２０万人も応募があったらしい。（9月頃
地球は異常？な温暖化中なので、太陽より遠い火星は『新天地』に思えるかもしれない。
地球では敵視されている大気中の二酸化炭素濃度が９５％以上だったり、こっちも大変過酷です。
とは云え、火星の大気の気圧は６ヘクトパスカル、地球の平均気圧が１０１３ヘクトパスカルだから、かなり薄い、だから気温差も激しい。
しかも上が摂氏マイナス２０℃あたりだったりと、大変厳しい環境です。
早い話がエアボンベと気密服無しでは野外に出るのは大変危険です。
それでも、月より大きいのでテラフォーミングしたら別世界になるかもしれません。
勿論、火星を緑の星にするのは無茶ですが、太陽系で一番深い渓谷もあるので天井を貼れば、そこだけ居住可能な空間が広がるかもしれません。
しかし、何よりも一番の心配なのは、地球人の飽きっぽさです。とりあえず地球でサバイバルと云えば周囲の食い物をあさることから始まるくらい地球は生きていくだけなら太陽系で一番恵まれた惑星ですからね。
火星で恒久的に居住可能な空間や色々な設備が揃う前にプランがとん挫したら、どうしたらよいでしょうか？大ピンチですよね？地球で寄付を募っても火星まで必要な物資を運んでくれる組織なんて極わずかしかないですし、火星まで片道２年半ぐらいかかるそうなので、非常に心細いですね。
そんなことも考慮済みなのか、最初に火星に行く人は人気投票で決まる様です。
オリンピック並に盛り上げてイベントを張って勢いを付ける必要はやはりあるのでしょう。
 
火星で自力で生活できるようになるまで、いったいどれだけの年月と費用がかかるんでしょうね？
 
そう考えると・・・
 
無理っぽいなぁ～

２～４枚のSDカードをS-ATA接続するボードはあったと思うけど、基盤だけでも結構高かった。
基盤が２．５インチSSDサイズで、最大１０枚もmicroSDメモリが挿せるものがあるらしい。
販売ページはこっち。
性能はイクインで5.9なのでそう悪くもない。
 
ただ、刺したmicroSDメモリのうちで１枚でもコケたら・・・
痛いことになるんだろうなぁ？
 
4枚版もあるようです。
 
 

１つは字句（トークン）解析（パーサー）。
単調なパターン、主に正規化表現で読める範囲でテクストを切り取るのが主な役目。
読むようによっては何通りもの値（Value）が出てくるので、文字列なら０１２３、数値なら１２３、でも８進数なら８３、１６進数なら２９１のハズなどと余計なことはしない方がいい。
for ( var  i ; i < 1/3 ;  i+= 0.000100000 ) {
のような場合は解析した値の精度が不十分だと、困った結果になるし、コード単位でデバッガをステップ動作させるには、テクストから切り取った文字の長さも重要だからだ。
「リテラル」「何かの名前」「数値」「演算子」「空白」「改行」程度の字句（トークン）に分類できればOK。
２つめは文法解析（パーサー）。
var i = j * 2;
をトークンの組み合わせを短い文法のパターンを優先順位順にパターンのマッチングを行い、正解があれば、パターンと対になる処理を実行する。
トークン（字句）ベースの正規化表現を処理する感じ。
字句解析との違いは、内包表現が可能で、
処理 ::= 処理 | 文
のように、処理に文と追加したものは処理としてまとめる、な感じの拡張ができる。
当然、
処理 ::= 文
処理ブロック ::=処理 ＋
のように内包しない書き方も可能。
 
自己拡張型トークン定義を用い、トークンパーサーとパーサーを１つで実装し、中間コード生成（コード・オーガナイザー）、中間コード実行（インタープリタ）の３つにまとめて考えるとすると・・・
つまり、
リテラル文字　::= \[rntsd”]   \\   \u[0-9a-fA-F]{4}  [\u0000-\uffff]
リテラル文字A　::= [^”]　& リテラル文字
リテラル文字B　::= [^”]　& リテラル文字
リテラル ::= \”  リテラル文字A  \”　｜　’   リテラル文字B  ‘
数字 ::= [0-9]+  “.” *  [0-9]*
のように最下層から定義することになる。
厄介なのは\エスケープ表現で、こんな感じで自己拡張可能なようにしないと内部コードに\エスケープ表現や\uxxxxの文字表現を埋め込まないといけなくなる。
また自己拡張型の欠点としてすぐ思いつくのが「処理が遅い」がある。
さらに、リテラル文字とリテラルの表現を観れば、なんとなく　リテラル文字の中に”が含まれているので、永久にリテラルの左の”や’を判別する気がないように感じる。
そこは、リテラル文字A,Bの最初の [^”]　[^’]で回避する。
つまり、この自己拡張型トークン処理ではサブルーチンにお任せではなく、１本の文字列ストリームを各階層でチェックしながら分析することになる。
それではやはり処理が重い、毎回正規化表現テクストの解析の後に、対象テクストを読み込むことになるので、正規化表現テクストの分析結果をキャッシュし、２度目は再利用することにする。
つまり、文法を解析し、文法解析する中間コードを生成し、インタープリタで実行させ、対象テクストを文法解析し、その中間コードを作り、最後にそれを実行することになる。
勿論、ターゲットとなるCPUやOSが限定する環境では各中間コードを完成直後に、バイナリーコードに置き換えて実行しても構わない。
さて細かい実装を考えると、
parser -g grammer-text  -i  analize-text
のように引数で与えるのは好ましくない。
なぜならファイルシステムが存在しなければ、grammer-text  も  analize-text　も読みようがないからだ。これはサンドバックの多くがファイルシステムへのアクセスを好ましく思わない現状を考えると、現実味のあることで、外部インタフェースを頼った方がいいので、DLLやシェアライブラリィのエントリィつまり一般に許可されているAPIを直接使うことにする。
parser -imports imports-defines -g grammer-text  -i  analize-text
な感じになる。
imports-definesには各OSごとに異なるAPIアクセス方法を記述した何か、ファイルシステムが無くても読みこむ様にする方法は、パーサーに組み込んだソースに依存する。
もちろん、パーサーでimports-definesの文法解析を行い、結果の中間コードをキャッシュしたままつかってもよく、対になる処理は、パーサーの初期設定にエントリィを組み込んでおけばよいので、imports-definesはWIN64とかLH6と宣言のみで中身はパーサーのソースの中でいいような気がするけどね。
 
な感じかな？
正規化表現をどこで解釈するのか記述しないと困るのかな？
やっぱり重そうだな（笑

MMORPGのマクロが

コマンド１　パラメータ１、パラメータ２、パラメータ３・・・

コマンド２　パラメータ１、パラメータ２、パラメータ３・・・

ばかりでは済むのは、
分岐処理やループ処理を

手作業（人力）

で代行しているからだ。
画面の【ボタン】を押して、ジャンプするだけなら同じでいいけど、

画面の雰囲気を読み取って、

画面解像度が１６８０ｘ１０８０だからフルセットでメニューを並べるけど、

画面解像度が１０００ｘ５００だからメニューは最初の１つだけ並べる。

ジャンプするにはif文ぐらいは必要だ。
設定ファイルから似たようなパターンのデータを読み取って、メニューを作るなら
似たようなパターンなマクロを繰り返すのでループ処理も欲しい。
長くなった処理を分離したくなったらreturn 文も必要だ。
 
だが、それ以上にscript　に必要なのは、
普通のインタープリタやコンピュータ言語では一目見ただけで嫌われる自己増強型インプリメンタル機能だ。
A.addMethod (function format(formatDate,startTime,endTime, nextStep) {
Alert（ String.Format(formatDate,endTime – startTime)　）；
post(nextStep);
});
なんてヘンテコでしかない。
しかし、ブラウザの非同期通信の返信に渡すと、何気に経過時間が返ったりOKボタンを押すと先に進むのであれば（？）何気に便利な気もする。（するだけ
 
だが、便利さに足元を巣食われて、サーバーとブラウザで全く違う書き方のスクリイプトが動くのも、不自由なので、
できるだけJavaScriptっぽくした方が楽だろう。
厳密に云えば、Scriptは　サラっと書けて、サクっと使えて、使いまわしができるのが一番だ。
そう考えれば、サーバー・スクリプトをサラっとJavaScriptに変換するトランスレーターを詰め込んでおくのも悪くないだろう。

あまりにも単純。
日当たりが悪い物件は、南側の日当たりが悪い場合が多い。
もっとはっきり云えば、西日しか入らない物件は安いだろう。（笑
そう考えると、ソーラーパネルを日が当たる時間が長い西側に向けた方がいいに決まっている。
というのは半分冗談だけど（笑
だいたいソーラーパネルのほとんどは完全に固定されているので、
一番発電量が稼げる設定が望ましい。
朝方は濃霧の日が多い地方なら西の方へ、東は海岸で日の出が早く、西は高い山脈に遮られ日の入りが早い場所なら、東の方へ調整した方がいい。つまり、設置する場所に非常に依存するものだ。同じ市内（盆地だったり等）でもかなり違いが出てくるケースもある。
そのせいか、地方ごとの1日の日照時間は公表されているが、毎時の日照時間は見当たらない。
また緯度の影響も受ける。
一般常識として太陽は１２時に真南方向にあると信仰されているが、
例えば日本標準時間は明石市なので、東西の地方でブレがある。
どれくらいブレがあのか？日の出の時間から推定すると、1月1日の根室は 6:50、那覇は7:17である。概ね３０分のブレがあるから、
±１５分ぐらいだろう。
磁石でぴったり真南方向に設置しても１５分ぐらいのブレは許容しなくてはいけない。
そんな訳でネット投票みたいに人間の都合で決めても何もメリットは無いものだ。
多分、設置する際にはとりあえず、屋根の上から周囲を見渡し、緯度、経度、日の出、日の入りの時間、地方の長期の天気から推定するのがいいのだろう。
そして、発電量の計測は当然だけど、東向きや西向きの小さな発電ユニットも設置して、1年間ぐらい記録し、もう少し東？西？の方がよいのか調べるのもいいだろう。
ということは、ソーラーパネルは若干の傾斜角度や東西角度が調整できる方がいいような気がする。
但し、豪雪地帯や強風が多い地方では、妙なデコボコを作ると長期間の間にパネルの傷みが進みやすい恐れがある。
 

今よく出ている３Dプリンターは、熱接着剤銃（グルーガン）で接着剤を盛っていくみたいなものだ。グルーガンはグルースティック（長さ１０ｃｍ）の材料をセットして使うが中には長いリール状の材料を後ろから詰め込むタイプのものもある。これをX-Yプロッタの上にペンの替わりに取り付けれたのが今の３Dプリンターだ。
過去にナノマシンが結構評判が良かったが、部品の摩耗がひどいらしく、今一つだったが、多分３Dプリンタとしては本命だろう。
グルーガンで盛っていく手順を追っていけば、盛れる限界が判る。

• 重力に逆らえない。
• 盛れる材料の種類は限られている。
• そんなに強度は無い。

そのため、足場材と組み合わせることで、自由度を上げているものの。
出来上がるのは、３Dプリンターだから◎かな？な程度のものだ。
金型でプラスチックを射出成形したものだといったら、多分×な仕上がり具合だ。
※バリとかあるし・・・
中には金属材料も使えるものもあるが溶接でもしているのかな？ただ、普通に売っている金属素材の程度の高温高圧にも耐えられない粗悪品としか云いようがないものしかできないようだ。
では、射出成形並の品質のものはナノマシンで作れないのだろうか？
答えは「作ってみないと判らない」
成型具合は多分、今よりマシだと思うけど、強度や重力の影響のゆがみが今の３Dプリンターの様に重力下の影響を強く受けつつ形成されるものとは異なるので、一時間放置すると鏡餅状になってしまっているかもしれない。（大笑
残念だが、ナノマシンでも分子単位でちゃんと結合させないと、今よりどうしょうもないモノしかできない可能性は高い。
悪く云えば、今３Dプリンタで出来るものは、素材を適当な形に積み上げ、ギュっと熱い手で固めた程度のものしかできない。
分子間結合、金属結合、これらをちゃんと再現できてやっとまともなものが出来上がるのだ。
でも、ギュっと熱い手で固めた程度でOKなら、今でもOK。（大笑
仮にちゃんとした強度を持った金属結合を再現できるような３Dプリンタが出来たら？
自動車や銃や戦闘機などは作れるだろうか？
多分、作れるだろう。ただ、その機動力や破壊力を良く知っているものなら、ちゃんと使い物になるのかテストしてみないことには危なくて仕方がない。仮に自転車を作ってみたとして、走っている最中にバラバラになったらどうなるか？（笑
どんな完璧な製造工程でも欠陥品が生まれない訳では無い。出荷されないだけなのだ。
３Dプリンタのそう遠くない問題は、出来上がったものの「品質管理」ではなく「品質検査」をどうやるか？だろう。
残念だが、３Dプリンタでは「品質検査」はできない。これが今の３Dプリンタの最大の欠点なのだ。
目で見て判るのは見た目だけなのだ。中身までは判らない。（大笑

コマンドラインでのデバッグはできたけど、ソースを見ながらのデバッガでソースを見れなかった。
原因は判らない。

http://127.0.0.1:8080/debug?port=5858
を表示した後に何かしなければいけないのかもしれないけど
ま、それはいい。
ただ、

http://127.0.0.1:8080/debug?port=5858
のために

npm -g install node-inspector

すると結構はソースが必要なのには驚いた。
今はまだ
ソースレベルデバッガをNode.jsに移植してみたぉ！
って感じがするので、1.0.0まで待つべきなのだろう。
そんなこんなで、
自前.jsで一式作った方がマシな気がしてきた。

Today : 2510
たまに馬鹿みたいにカウンターが上がります。
プロバイダー（ISP）のBOTが一斉に挨拶に来たようです（笑
BOTが持ち出した内容を人が見たら、ブログの分類に悩むんじゃないかな？
分類は【趣味】でお願いします。
このブログの真の目的は、自宅でのCentOS+WorsPressの長期運用ですから、
記事の内容はかなり適当です。
ご了承ください。
実際、ここのブログはよく止まります。
多くはDDNSのIPアドレス更新が失敗してたりしますが、
原因不明でapacheが無反応だったり、
TeraTermですら入れずリセットなんてこともあります。
ログを見てみると、突然パタッと止まってるんで
熱暴走なのかも。
更新する度にファンが回る音がしますね。
やっぱりホコリがたまってるかな？
ｐｓ.
臨時メンテ（お掃除）は終了しました。
ホコリは溜まっていなかったので室温のせいかな？
このブログは安いCeleron847 NUC
+無線ＬＡＮ(INTEL純正)
+ＳＳＤ（60GB）
+DDR3(4GB)1枚
CentOS6+WordPressで稼働しています。

# df -h
Filesystem            Size  Used Avail Use% マウント位置
/dev/mapper/vg_＊＊＊-lv_root
                       50G  8.2G   39G  18% /
tmpfs                 1.7G     0  1.7G   0% /dev/shm
/dev/sda1             485M  139M  321M  31% /boot
/dev/mapper/vg_＊＊＊-lv_home
                      5.7G  472M  5.0G   9% /home
# free
             total       used       free     shared    buffers     cached
Mem:       3366440     914636    2451804          0      19212     182316
-/+ buffers/cache:     713108    2653332
Swap:      3506168          0    3506168