[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

[MD:4314] minutes of the meeting (was: COM support plan)



>>>>> [meadow-develop : No.4307] にて
>>>>> "大場" = Koichiro Ohba <koichiro@xxxxxxxxxxx> さんは書きました:

大場> 神懸かりトランス状態になった himi さんが突然粘土板に古代バ
大場> ビロニア文字で仕様を書きはじめたり、その碑文を発掘した三好
大場> さんといっしょに困惑してますます泡盛あおってみたり、

あんまり記憶がないのですが、碑文を発掘して困惑したことを議事録と
して報告します。訂正、追記願います。

(1) COM サポート
  o 大場さんが [MD:4307] で報告してくれたので省略。

(2) 印刷機能のサポート
  o COM を使うよりも native で実装する方が良いだろう。

  o win32 API では GDI を使って情報を渡している。

  o ビットマップ情報を使って印刷するのは却下。

  o himi さんがフォント周りで物理座標を徹底的に排除したのは、印刷を容
    易にするため。

(3) GC 関連
  o GC を引き起こす可能性があるのは、Feval() と Ffuncall()。これらが呼
    ばれる場合には、gcpro すべし。

  o gcpro しない Lisp_Object が GC で破壊された場合には、Emacs は落ち
    る。その場合の症状は不定。

  o Feval() と Ffuncall() を呼んでる関数は cflow2cflow で調べることが
    できる(*)。

  *) 当方で試したところ、cflow2cflow は cygwin でビルドできなかなった。
     cflow では、関数を直接呼んでいるものしか分からないので使えない?

(4) スレッド間のリソース競合
  o メインスレッドとメッセージスレッド間のリソース競合による問題(リソー
    ス破壊、デッドロック) を完全に解決するのは難しい。

  o この問題を複雑にしている mouseface の非同期表示を止めて、Meadow1 
    と同じように同期表示に戻すの手もある。

(5) xdisp.c と dispnew.c の役割分担

  o “大域的な状態の変更処理”と“表示の更新処理”は明確に分離されてお
    り、前者は xdisp.c、後者は dispnew.c に実装されている。

  o “表示の更新処理”のトリガとなるのは redisplay()@xdisp.c だけであ
    る(詳しくは xdisp.c の冒頭のコメント参照)。

  o この Gerd による設計思想はすばらしい。

  o dispnew.c の new は新しく更新されたものという意味(xdisp.c のコメン
    トによると redisplay の新しい実装という意味にも取れる)。

(6) Meadow2 不安定
  o 疋田さん環境では Meadow2 が週に2, 3回は異常終了するらしい。
    →報告をお願いします。

--
三好 雅則 mailto:miyoshi@xxxxxxxxxxxxxxxx
          http://www.boreas.dti.ne.jp/~miyoshi/ (Meadow2 のページ始めました)