【なでしこ】なでしこプログラムコンテスト

ああ、長いことほったらかしになってしまった（⌒◇⌒；。

日本語プログラミング言語　なでしこの10周年記念プログラムコンテストと
言うのがあって、これに応募しようと思ってたんだけど、3月末に間に合わず…
と思ったら6月に延長になって、これは！…と思ってたけど、結局ギリギリに
なるまで意欲湧かずヾ(;´▽｀A``。月末になって漸く応募できるだけの
プログラミングが出来たので、なんとか間に合いそうか！。

当初httpdなDLLを作ろうと思ってHTTPについて色々調べたんだけど、
どうしても「文字列でなんでもやる」プロトコルが好きなれずに挫折。
多分、C言語でHTTPプロトコル実装するのってかなりシンドいんだと
思う。

なでしこについては、プログラムコンテストもイマイチ盛り上がってない
感じ。圧倒的に使ってる人が少ないのかも知れないなあ。確かに
日本語でのプログラムは逆に抵抗があるけど、言語としては良く
出来てると思うし、せめてゲームが作れるぐらいの整備がされたらなあ。

HSPは2chとかでは結構たたかれることもあるんだけど、毎年の
プログラムコンテストとなれば（玉石混合だけど）結構な応募があって
裾野が広いって感じるなあ。

Windowsももう直ぐ10がリリースされて、主流はデスクトップよりも
スマホやタブレットになる予感。なでしこも、そういうところをターゲットに
色々と作れると楽しいのに！。

【なでしこ】httpdなDLL

また間が空いてしまったヾ(;´▽｀A``。さて、なでしこのGUIをなんとかしたいと思って
始まったんですが、最終的にはローカルWebサーバ(httpd)を実装してこれをDLLに
して、なでしこからこれを使えば、自分で作ったHTMLをローカルに閉じた状態で、
WEBブラウザに表示できそうです。

その際、やっぱり多少セキュリティーは考えとかないとマズそうなことが分かりました。

・なでしこ側ではファイルの操作などなんでも出来ちゃうので、下手にこのDLLを
　通してなでしこにアクセスされるのはダメ

　→ローカルなのでアドレスはhttp://127.0.0.1/となるけど、たとえば別のインターネット
　　サイトから表示させたリンクにこのアドレスが指定されていると、PCが攻撃されて
　　しまう。

・クロスサイトスクリプティング(XSS)には対応しておいたほうが良い。

　→FORMの入力に変な入力をされて、それをそのまま表示してしまうと、ローカルな
　　データベースに不正にアクセスされてしまうかもしれない。インジェクション関係は
　　対応は必要そう。

・クロスサイトリクエストフォージェリ(CSRF)には対応しておいた方が良い。

　→アプリで使うローカル用のHTMLを偽装されて、それを表示したら変なスクリプトが
　　走るようなことがあってはダメ。

DLLがそのアプリ作者の目的どおりに使用されていることを確認するためには
最低限、Basic認証ぐらいは入れておいたほうがいいかな…と考えてます。
本当はブログのコメント各時みたいに、画像でランダムな4桁の数字入力求める
のがいいかも知れないけどなあ。


httpのプロトコル自体は、実はそんなに難しくなくて、ローカルでしか使わないから
IPv4に限定してTCP/IP上でデフォルト80番ポートで文字列通信するだけ。リクエスト
で使うメソッドも少ないから、まあ頑張れば実装できそうかな。

なでしことのインターフェースは

・初期化・終了関係
・任意のデータの送信（HTMLファイル、テキスト、画像ぐらいかな？）
・ブラウザ側でフォーム入力がありSubmitされた場合のGET/POSTされた
　要素のイベント

ぐらいでしょうか。

【なでしこ】Win32APIを使ったGUI（案） その2

で、色々と検討した結果、ResEditを使うと、VisualStudioライクなRAD環境で
リソース生成が出来て、且つ、これをリソースDLLに変換できることが分かりました。
ってことで、なでしこのGUI用DLLを作成し、ここから上記のリソースDLLを読み込んで
やれば、なんとかなりそうかなあ…。ただ、この方法にはいくつか問題がありまして…

・リソースDLLと同時に、各リソース（ボタンとか、テキストエリアとか）のIDを定義した
　ヘッダファイルを同時に生成し、これをなでしこ用DLLで読み込んだ上でなでしこ側の
　スクリプトと共有しないといけない。

・DLL側でGUIを生成したとしても、おそらくWin32のメッセージ処理用キューは
　なでしこ(gnako)が持っているメッセージキューと同じになる。これを回避するために
　なでしこ用DLL内でスレッドを生成して、そこでメッセージを受ける様にすれば、
　「母艦」のメッセージとは区別できるが、メインスレッド（つまりなでしこ本体）との
　通信方法は考える必要がある。

・gnakoの場合、立ち上げた時点で「母艦」フォームが表示されてしまっていて、
　これを消すとgnako自体消えてしまいそうな気がする。

上記ResEditでリソースを作る方法以外にも、Tcl/Tkを用いてなでしこ/Tkみたいな
ラッパーを作る、wxWidgetsのラッパー、Qtなどなど色々考えたけどやっぱり母艦が
自動で生成されていることで相性がイマイチ。vnakoの方は重そうなので、そもそも
却下、GUI（フォーム）が生成されないcnakoなら…と思ったけど、コマンドラインの
DOS窓が消せない…ってことでいずれも破綻しました（￣□￣；。う～む。

ってこでなでしこのGUI環境をいじる別の方法を考えた分けですが、可能性としては
以下の二つ。

・nako.dllにはインタプリタ本体も入ってそうなので、自分でwnako.exeみたいなのを
　作って、無理やりResEdit＋リソースDLLに対応してみる。

・Win32は諦めて、別の汎用GUI的なものを目指す。

自分でexe作るのも面倒ですし、そもそもインタープリタ部の使い方も説明はない
ため破綻しそう…ってことで後者を考えます。より汎用的ってことで、ローカル
WEBサーバを用いたブラウザ上でのGUIとの連携を考えることにします。

【なでしこ】Win32APIを使ったGUI（案） その1

なでしこには「積み木デザイナー」と言うRADツールが付いてるんですが、
これはあくまでちょっとしたGUIプログラムを作るためのもの。複雑な、
GUIのパーツがイッパイ付いてるものを作ると、それを読み込むだけで
「積み木デザイナー」が重くなり、ロードされるのに結構時間がかかり
ます。

なでしこのGUI部分は\lib以下の「gnako.nako」「windows.nako」がその定義。
windows.nakoがWin32APIのラッパーで、gnako.nakoにはそれらを使った
なでしこの関数、グループなどの定義があります。

このやり方でも全く問題ないんですが…

・gnako.nakoに定義されたグループや関数のコールは、なでしこベースに
　なるので結構遅い（Win32APIをコールするより、なでしこのコールが
　入る分、一段遅い）

・windows.nakoのラッパーに定義されているメッセージ定数は、グローバル
　として定義されているので、イッパイメモリ食ってる。

・積み木デザイナーは「簡易」RADツールなので、複雑なものは作れない。

ってことで、もうちょっと複雑なGUIアプリを、実行速度も考慮しながら
作れる様に考えます。

【Quartz】数式

数式は大体はC言語と一緒です。

------------------------------------------------------------
a = 1 + 2 * 3 / 4        #四則演算
b = (1 + 2) * 3           #(　)付き演算
c++                         #インクリメント、デクリメント
a = 1 << 2                #ビットシフト
b = a & 0x00000001   #ビット論理演算
c = "moji" + "retsu"  #文字列連結
------------------------------------------------------------

ビットの論理演算は数値に対してのみ有効で、結果は16進に
なります。文字列の連結は便利そうなので入れておきます。
文字列と文字列意外の連結は…どうしようかなあ。文字列として
返す様にしようかな。

【Cubieboard2】コンパイル備忘録 その2

Buildrootのmakeができたら、これをSDカードにます。4GBぐらいあれば
いいみたいですが、8GBのものを使いました（実際、イメージはそんなに
大きくないので、2GBとかでもいけるかもしれません）。

■書き込み用のスクリプトを起動

# sudo ./board/cubietech/cubieboard/mkcubiecard.sh output/images/ /dev/sdd

Buildrootのフォルダ直下で、上記を実行。最後の/dev/sddの部分は環境に
ことなります。mountされてるとエラーになる可能性があるので、あらかじめ
umountしておきます。

mount時、/dev/sdd1とかなってますが、引数師弟の場合は/dev/sddとします。
これを実行すると、SDカードにすべて書き込んでくれます♪。

■起動！

microSDカードをCubieboard2に挿入して起動！。シリアルポートで動作確認
できますよ～。ちなみにシリアルポート接続はFTDIのUSB接続タイプのを使って
ますが、Cubieboad2のシリアルポート(USB1/2ポートのすぐ後ろくらいにある
4pinヘッダのコネクタ)には

GND...黒
VCC...×
RX...緑
TX....白

の様に接続。VCCに赤のラインをつなぐと動きませんので、ここはNCです。

■シリアルコンソール

Ubuntuの場合、「Serial port terminal（シリアルポート端末）」と言うソフトがあるので、
ソフトウェアセンターでインストールできます。ただし、これを普通に動作させると
「許可がありません」とか言われるので、コンソール（端末）から

# sudo gtkterm &

でOK。シリアルポートはボーレートが115200、8bit、stop:1bit、パリティーなし、で
動作してます。

やってみたら意外と簡単でした♪。Buildrootすげー。

【Cubieboard2】コンパイル備忘録 その1

Cubieboard2を買ってほったらかしになっていたので、それ様のBootイメージを
作ってみようかと思います。

公式サイトではYocto使う様に書かれてたり、Debianイメージが配布されていたり
するんですが、ウチの非力なPCではYoctoのコンパイルには時間がかかりすぎるし
Debianは色々入りすぎてる感じ…。ってことで 割とお手軽そうなBuildrootを選択。

■Tool Chain

Ubuntuの場合はapt-getで取れます。

# apt-get install gcc-arm-linux-gnueabihf

 
■U-Boot

gitで取ってきます。

# git clone https://github.com/linux-sunxi/u-boot-sunxi.git

取ってきたらu-boot-sunxi/に入って、まずはConfigを作ります。

# make CROSS_COMPILE=arm-linux-gnueabihf- Cubieboard2_config 

U-Boot本体を作ります。

# make CROSS_COMPILE=arm-linux-gnueabihf-

■ツール類

gitで以下の2つを取ってきます。

# git clone git://github.com/linux-sunxi/sunxi-tools.git
# git clone git://github.com/linux-sunxi/sunxi-boards.git

sunxi-tools/に入って、ツールをまず作ります。

# make fex2bin

sunxi-boards/sys_config/a20に入ります。ここに目的のcubieboard2.fexファイルが
あります。これはボードのハード設定諸々を記述したもので、これをコンパイルしてbin
ファイルにした後、U-bootからKernelに引き渡す様です。

# ../../../sunxi-tools/fex2bin cubieboard2.fex script.bin

生成されたscript.binが目的のファイルです。

※Buildrootを取ってくると、上記も一緒に入っててAutoでコンパイルしてくれてました。
　なので、Buildroot使う場合は必要ないです。

■Buildroot

gitでも取れますが、今回は

　　http://buildroot.uclibc.org/download.html

からtar.gzファイルを取ってきて展開。

# tar  zxvf  buildroot-2014.08.tar.gz

buildroot-2014.08/に入ってコンパイル。まずはconfig作ってから本体のmake。

# make cubieboard2_defconfig 
# make

今日はここまで♪。