[dennou-ruby:000427] Re: proto2c

[gotoken@xxxxxx (GOTO Kentaro)]

ごとけんです

すぐにコメントできるトコから先に答えます。

# その前に業務連絡、RASCからの派遣依頼来ました > 堀之内さん

In message "[dennou-ruby:000425] Re: proto2c"
    on 00/10/29, Kuroi Keiko <keiko@xxxxxx> writes:
>配列の宣言からサイズを計算する部分を書いてみましたが、ごちゃ
>ごちゃしている上、ちゃんと動いていないような気がします。

あとでみてコメントします。

>また、配列のサイズで、DFLT_SIZE を多用しています。もう少し
>類推する手段はないのでしょうか？ パーサーでできることも限界
>がありますしね。ちゃんと動けばいいのですが。

これは、言ってしまえば明記されていないDCLの仕様に責任があり
ます。少なくとも、cdclを使うときには同じ問題が発生しますし。
LAPACKのようなこなれたライブラリではもっとやりやすいようです。

>メソッドの定義は、一応それなりに動いてはいるのですが、もっと
>いい書き方があると思うので、ごとけんさん、チェックして頂け
>ますか。

あとでみてコメントします。

>例えば、出力用の real 配列の変数を返す場合、Array のオブジェ
>クトか、NumArray にするかの判断で迷ったのです。(まだ、実は
>書いていない部分ですけど。)
>Ruby/DCL ( Ruby/CDCL ? 名前はどうしますか、みなさん… ？)
>が、NumArray を必須にするなら全て NumArray にします。でなけれ
>ば何かフラグを持ちますが、NumArray が大前提ですよね、きっと。

えっと、場合によりますね、可能性としては
  (1) Array
  (2) NumArray 
  (3) NumArray の Array
の3パターンがありえるはずです。とりあえず一律Arrayにしましょう。
逆に(2)や(3)でないとおかしなDCL関数には何がありますか?

>work タイプの変数は、Ruby/DCL で領域確保しないといけないで
>すよね？ また、領域確保は ALLOC_N() でよろしいでしょうか。

ALLOCA_N()でよいです。alloca()された領域は関数から返るタイミ
ングで解放されますが、work変数はまさにそのような用途であるハ
ズですので。

>NumArray オブジェクトかどうかのチェックは、タイプが T_DATA 
>か見ているだけなのですが、どうすればいいでしょう？

kind_of? に相当する、object.c:rb_obj_is_kind_of() を使うのが
よいでしょう。実行コストが増えますが、Complexなどは早晩Cで実
装しなければならないことを考えると T_DATA によるチェックは危
険です。

>これからの作業ですが、
>私は、Ruby/DCL から呼ぶ関数(オブジェクトから C 配列への変換と
>その逆) を作ろうと思っています。
>
>あとは、proto2c の修正と、Init_dcl() を作り、コンパイルと動作
>確認等々、ごとけんさん、どのように分担しましょうか？

では、僕は Init_dcl() を担当します。proto2c の確認はお互い気
が付いたところでぶつけあいましょう。

>と、質問ばかりになってしまいました。
>では、よろしくお願いします。

いえいえ、とても助かります。まともに指示を出していない僕のほ
うがどう考えても悪いんです __;

-- gotoken