とりあえず狙ってたところまで動作確認完了ヽ(´ー｀)ノこれは面白い
OpenCOBOL側のSTOP ABOUT.踏むと読んだ側が死ぬ（OpenCOBOL側でexit()呼んでるので）とかいろいろありましたが、アレがarrayに積んだ値をOpenCOBOL側から読み出して変数に設定したり、OpenCOBOL側の変数をアレが読んだりとか結構楽しいものができました。
詳細はいずれ発表されるでしょうからヽ(´ー｀)ノご期待アレ。
ひさびさに about:mozilla してみたり(;´Д`)
邪神マモンは眠りに落ちた。復活せし野獣は大地を巡り、数を増やして軍勢をなした。新たな時の到来は広く告げられ、人々は狐の叡智をもって実りを炎の供物とした。そして聖なる書の約束の地、夢を紡いだ第二の世界を築いた人々は、その子らに野獣を語り継いだ。マモンが目覚めた時、見よ！残されしはただ一人の従者のみ。from The Book of Mozilla, 11:9
(10th Edition)
こんなんだったっけ？(;´Д`)Mozilla Firefox 3 Beta 5にて
色々調べてたら
http://forums.firehacks.org/l10n/viewtopic.php?t=2539とかで議論されてたのね。納得(´ー｀)
ついでに：about:robots ヽ(´ー｀)ノ
いちいち変数のアドレスを積むのはいいとして、型だとか長さだとか解析するのが面倒だなあと思いつつ(;´Д`)昨日のプログラムを眺めていたら…
GETVALUE(char *value, const char *varname) {
cob_module *module = cob_current_module;
cob_field *f = module->cob_procedure_parameters[0];
printf("%08x %08x\n", value, f->data);
}
/* field attributes */typedef struct {
unsigned char type;
unsigned char digits;
signed char scale;
unsigned char flags;
const char *pic;
} cob_field_attr;/* field structure */
typedef struct {
size_t size;
unsigned char *data;
cob_field_attr *attr;
} cob_field;
OpenCOBOLが吐きだしたCのソースを眺めてましたが(;´Д`)弄りにくいすぎる
という事で方針を大転換して、OpenCOBOL内の変数のアドレスと変数名をOpenCOBOLコード中から送るようにして、別途用意したCで書かれたサブルーチンにストックした値と差し替える方向でファイナルアンサーヽ(´ー｀)ノ
CALL "GETVALUE" USING VARNAME0 "VARNAME0"
CALL "GETVALUE" USING VARNAME1 "VARNAME1"
CALL "GETVALUE" USING VARNAME2 "VARNAME2"
CALL "GETVALUE" USING VARNAME3 "VARNAME3"
みたいな感じで、WORKING-STORAGE SECTIONで定義してるすべての変数について値を取りに行ってみる等。上記はOpenCOBOL中では以下のように展開されるようです（部分）：
/* TEST0001:41: CALL */
{
{
int (*func)();module.cob_procedure_parameters[0] = &f_27;
module.cob_procedure_parameters[1] = &c_1;
module.cob_procedure_parameters[2] = NULL;
module.cob_procedure_parameters[3] = NULL;
module.cob_procedure_parameters[4] = NULL;
module.cob_procedure_parameters[5] = NULL;
module.cob_procedure_parameters[6] = NULL;
cob_call_params = 2;
func = cob_resolve_1 ((const char *)"GETVALUE");
(*(int *) (b_1)) = func (b_5 + 540, (unsigned char *)"VARNAME0");
}
}
/* TEST0001:43: STOP */
Cで書いたプログラム側には変数はポインタ渡しされますし、文字列リテラルももちろんポインタ渡し（そしてNULL終端）されます（参考：OpenCOBOL マニュアル -> C インターフェース : C プログラムへの静的リンク)
たった1個のCALLでも清々しいほど重そうな処理ですね(;´Д`)。こんなのが変数分だけ（つまり数百個も！）並びそうですがコンパイラの最適化に任せましょう(;´Д`)不要な変数の引き渡しについては最適化も可能なわけですから、それは将来の課題として。
で、C言語ではかせて弄り倒すよりも（外見は）シンプルになりますから、説明はしやすいんじゃないかと思います。魔術的なコードやトリック、カラクリで稼働させるよりは良いんじゃないかとかなんとか。
某N社COBOLからOpenCOBOLからの印刷を検討していて(;´Д`)
印刷時のフォントの取扱いとか、罫線レイアウトの取扱いとかどうするべ？って考えているうちに指が自然と cat /etc/termcap してしまう今日この頃。
# FONTS: The UNIX PC also has a strange interpretation of "alternate
# character set". Rather than the VT100 graphics you might expect, it allows
# up to 8 custom fonts to be loaded at any given time. This means that
# programs expecting VT100 graphics will usually be disappointed. For this
# reason I have disabled the smacs/rmacs sequences, but they could easily be
# re-enabled. Here are the relevant control sequences (from the ESCAPE(7)
# manpage), should you wish to do so:
#
# SGR10 - Select font 0 - ESC [ 10 m or SO
# SGR11 - Select font 1 - ESC [ 11 m or SI
# SGR12 - Select font 2 - ESC [ 12 m
# ... (etc.)
# SGR17 - Select font 7 - ESC [ 17 m
まあフォント種の切り替えはこれで良いかな。または手作業での変換が楽になるようにフォント名指定可能にして ^[["FONTNAME"SF ^[["FONTNAME"DF とか。COLUMNは必要なら "^[[数字H"でやるとしてレイアウトファイルの読み込みはどうするかな。^[["filename"L (とかにしとくか（いい加減）。改ページは\f吐いてくるようなのでこれを処理すればいいかな。(;´Д`)とか
今回は通信量は問題じゃないし、速度も気にしなくていいので結構冗長でも可動性が良ければOKOK。コード中のフォント指定やカラム指定のコードの代わりに FILLER部分に入れるんだし。
で termcap見てて気づいたんだけどTERMに teratermとか puttyとか指定できるのね。今度試しみるかな。puttyつかってるときの動作がxtermよりもputtyの方が落ち着いてるかもしれんから。
参考：