★ INCM Plug-in開発掲示板 ★ TinyGrass Ver0.32a ［戻る］
[0287] 00/11/09 21:50 GAE(vbbj25HUgnk): Re:285)RE: INCM1.21m
> これで少し試験して、うまくいくようなら一般公開したいんですが、ランタイム
> の問題はどうなるでしょうか。フツーの人に広く使ってもらうためには、IE入れ
> ろまではいいにしても、それ以上を要求するのは難しいと思うんです（ギリギリ
> が標準的なPerlをインストールしろまででしょう）。VC++のランタイムなしに戻
> すのは大変でしょうか？
msvcp60.dll は最近のMicrosoft製品がインストールされている
環境ならほとんど入っているようなので問題ないかなあと思ってます。
これを使わないようにすることができるかどうかは、
ちょっと調べてみないとわかりません。
Access 2000
Commercial Internet System 2.0A
FrontPage 2000
MapPoint 2000
Office 2000 Developer
Office 2000 Premium
Office 2000 SR1
Outlook 2000
PhotoDraw 2000
Platform SDK (Sept. 1999)
Visual C++ 6.0
Visual Studio 6.0
Windows 2000 BETA RC2
Windows 2000 Professional
Windows 2000 Server
Windows Millenium Edition
MFC42.dll については、Windows 95 OSR 2.5 から入っているようなので、
ほとんどの環境に入っています。
http://www.gld.mmtr.or.jp/~naofumi/incm/
[0286] 00/11/09 16:50 Buckeye(UnTUYw5MC2c): Re:285)RE: INCM1.21m
多少むりやり、複数会議室に同時発言をしてみました(^^;)
ちゃんと、複数のcmwファイルが書き出されていたようですし、プラグイン側も、
ちゃんと、ある限りのcmwファイルを処理してくれたようです。
Best Regards,
Buckeye
[0285] 00/11/09 15:59 Buckeye(UnTUYw5MC2c): Re:284)RE: INCM1.21m
はい、いいようです。とりあえず、複数のcmtファイルのうちの1つについて、複
数発言をするというのはうまくいきました。送信属性のUを削除したものは、送
信済みに移動します。ただし、送信属性を削除しなかったらどうなるかの試験は、
まだしていません。
複数のcmtファイルに投稿発言を書いたときの試験もすべきなんだろうけど……
発言練習みたいなことができるとこって、1フォーラムに1会議室くらいなんです
よねぇ。うーん、あっちこっちの話にムリヤリ割り込み参加してみるかぁ(爆)
これで少し試験して、うまくいくようなら一般公開したいんですが、ランタイム
の問題はどうなるでしょうか。フツーの人に広く使ってもらうためには、IE入れ
ろまではいいにしても、それ以上を要求するのは難しいと思うんです（ギリギリ
が標準的なPerlをインストールしろまででしょう）。VC++のランタイムなしに戻
すのは大変でしょうか？
INCM 1.21j→1.21kでINCMのサイズがかなり小さくなっているので、その際に一
部の機能をdll側に追い出した（というか、dllを呼ぶ形に変更した）んだと思う
んです。1.21kで実装されたhtmlビュー関連の機能でVC++のランタイムがどうし
ても必要なのでなければ、VC++のランタイムなしに戻していただけるとありがた
いんですが……
Best Regards,
Buckeye
[0284] 00/11/08 22:56 GAE(vbbj25HUgnk): Re:274)INCM1.21m
プラグイン書き込みに関する不具合を修正してみました。
これでどうでしょう？
http://www.gld.mmtr.or.jp/~naofumi/incm/beta/incm121m.lzh
http://www.gld.mmtr.or.jp/~naofumi/incm/
[0283] 00/11/08 22:56 GAE(vbbj25HUgnk): Re:277)RE: MSVCP60.DLLがない？
> 自宅のWin95、IE5.0にはMSVCP60.DLLがありました。なので、この発言はINCM
> 1.21lで書いています。
> このdllはどのソフトのコンポーネントなんでしょうね。私自身は、NTマシンに
> dllをコピーすれば問題なくなると思うのでいいんですが、普通の人のマシンに
> 入っているハズのコンポーネントなんでしょうか。ちょっと心配。
入ってたり入ってなかったりでしょうね。
VisualC++ 6.0 のランタイムです。
http://www.gld.mmtr.or.jp/~naofumi/incm/
[0282] 00/11/08 19:54 Buckeye(UnTUYw5MC2c): Re:280)RE: プラグインでの書き込みの仕様
だいたいのところはできたと思います。あとは、cmwファイルに全部の発言記事
が書き出されれば、たぶん、複数発言が可能になると思われます。ちなみに、全
体ヘッダは書き戻す形にしました。
Best Regards,
Buckeye
[0281] 00/11/08 17:36 GAE(3nxWzOCXjo.): Re:280)RE: プラグインでの書き込みの仕様
>ろの動作がおかしいのか、それとも、バグなのか……ちょっと確認してみていた
>だけませんか？＞GAEさん
ぐはあ。
確かに、1記事でのテストしかしていません…。
今晩帰ったら修正しようと思います。(予定)
>・ cmwファイルとなる時点で、ここにいろいろな情報が書き出されることはある
> のでしょうか。現状は、ほとんど空欄みたいですし、発言処理のために必要
> ということも特にないように思うんですが。
必要ないですが、処理の都合上くっついてます。
>・ プラグインで送信処理をしたあと、cmwファイルを書き戻すとき、このヘッダ
> は必要ですか？（書き戻さずにすむなら、簡単でいいんですが……って無精
> なヤツ^^;） 必要なら、どういう情報を書いておけばいいのでしょうか。
> （#Uの数を送信に失敗した発言数にしておけばいいのかなぁ）
必要ないです。
もしも、ファイル内の記事数が1万とかそんなレベルだったとしたら、
ちゃんと設定しておくとパフォーマンスが上がります(笑)
[0280] 00/11/08 13:51 Buckeye(UnTUYw5MC2c): Re:274)RE: プラグインでの書き込みの仕様
いくつか質問があります。
★ cmwファイルへの発言記事の書き出し
適当にいくつか発言を書いて巡回し、INCMが作ったcmwファイルをプラグインで
コピーしてみました（どういうファイルが書き出されるのかを確認するため）。
ところが、なぜか一度に1発言しかcmwファイルに書き出されていないようなので
す。繰り返し巡回すると、毎回、異なる発言が書き出されます。これは私のとこ
ろの動作がおかしいのか、それとも、バグなのか……ちょっと確認してみていた
だけませんか？＞GAEさん
★ 全体ヘッダの取り扱い
cmwファイルの先頭には、以下のような#で始まるヘッダがあるようです。
#T:
#N:0
#U:1
#B:0
#R:0
#F:
#P:
・ cmwファイルとなる時点で、ここにいろいろな情報が書き出されることはある
のでしょうか。現状は、ほとんど空欄みたいですし、発言処理のために必要
ということも特にないように思うんですが。
・ プラグインで送信処理をしたあと、cmwファイルを書き戻すとき、このヘッダ
は必要ですか？（書き戻さずにすむなら、簡単でいいんですが……って無精
なヤツ^^;） 必要なら、どういう情報を書いておけばいいのでしょうか。
（#Uの数を送信に失敗した発言数にしておけばいいのかなぁ）
Best Regards,
Buckeye
[0279] 00/11/08 13:51 Buckeye(UnTUYw5MC2c): Re:278)RE: まだ試してないですが
私も、*.cmwをまとめてつくって、ともかくプラグインを呼び出してもらうのが
いいと思います。*.cmwということがわかっていれば、プラグイン側でファイル
の存在を簡単に確認できますから（少なくともperlでは）。
Best Regards,
Buckeye
[0278] 00/11/08 07:01 一 五明(YMjHyfzdazU): Re:274)まだ試してないですが
>*.cmw 一個つくるごとにそのファイルを引数にして
>プラグインを呼び出した方が良いかもしれませんが…
これはオーバーヘッドが大きいでしょうし、送信から巡回まで1プロセス
で出来たほうが何かと便利な気はします。
直列表示系だと大抵送信後に掲示板の内容が返って来るので、そのまま読
んでしまえば再接続の手間も省けますから。
http://kt.sakura.ne.jp/~timeflow/M/
[0277] 00/11/07 19:55 Buckeye(UnTUYw5MC2c): Re:275)RE: MSVCP60.DLLがない？
自宅のWin95、IE5.0にはMSVCP60.DLLがありました。なので、この発言はINCM
1.21lで書いています。
このdllはどのソフトのコンポーネントなんでしょうね。私自身は、NTマシンに
dllをコピーすれば問題なくなると思うのでいいんですが、普通の人のマシンに
入っているハズのコンポーネントなんでしょうか。ちょっと心配。
Best Regards,
Buckeye
[0276] 00/11/07 17:53 GAE(3nxWzOCXjo.): Re:275)RE: MSVCP60.DLLがない？
>INCM 1.21lを落としてきたのですが、1.21jからバージョンアップすると、起動
>時に「MSVCP60.DLL」がないとおこられます。どっかから落としてくる必要があ
>るんでしょうか？
あらら、VC++のランタイムまでいるとは…(汗)
http://www.gld.mmtr.or.jp/~naofumi/incm/beta/
にコピーしておきました。
これで試してみてください。
[0275] 00/11/07 15:11 Buckeye(UnTUYw5MC2c): Re:274)MSVCP60.DLLがない？
INCM 1.21lを落としてきたのですが、1.21jからバージョンアップすると、起動
時に「MSVCP60.DLL」がないとおこられます。どっかから落としてくる必要があ
るんでしょうか？
ちなみに環境は、NT4.0+SP5、IE5.0です。
INCM 1.21kで必要になったというdllは、両方ともシステムにありました。
書き込み対応のテストをしたくてうずうずしてるんですが、起動できないんで先
にすすめていません(;_;)
Best Regards,
Buckeye
[0274] 00/11/07 00:28 GAE(vbbj25HUgnk): プラグインでの書き込みの仕様
とりあえず実装しました。＞ INCM 1.21l
http://www.gld.mmtr.or.jp/~naofumi/incm/beta/
プラグインでの書き込む場合、cmtに出力するとき、
F:POST,.... となっているのを
F:LIB,.... とします。
"LIB" というのはプラグインのことを
「ライブラリ」と呼んでいた頃の名残ですがまあ問題ないかな…。(すごい適当)
他に適切な物があれば指摘してください。
送信記事の送信方法が "LIB" となっていた場合は、
送信する記事を *.cmw にCMTフォーマットで書き出します。
INCMは普段通りの巡回方法でプラグインを呼び出しますので、
プラグインは、カレントディレクトリの *.cmw を検索して処理してください。
*.cmw 一個つくるごとにそのファイルを引数にして
プラグインを呼び出した方が良いかもしれませんが…
送信に成功したら、送信属性を削除してください。
内部的には *.cmw を出力する時点で、元の cmt から記事が削除されます。
そして、巡回後に *.cmw をインポートして、送信失敗した記事が
もとの cmt に戻るようにします。
送信属性が削除されていた場合は、送信済に移動します。
http://www.gld.mmtr.or.jp/~naofumi/incm/
[0273] 00/10/31 00:01 風葉(jmhR4bkKNz.): Re:267)エディタ
ぁぅ、失礼しました。(^^;
> 難しいみたいですね(^^;
はい(笑)。枉げられません。
特に（先程は書き忘れましたが）ASCIIの0x5Cが「￥」と表示される環境でC派生
言語や正規表現の閲覧・編集は耐えられません。(^^ゞ
> とりあえずエディタの終了を検知でなく、作業ファイルのタイム
> スタンプを監視して、書き込みを更新するオプションを付ければ対応
> エディタは増えるかも。
Emacsの場合ですとEmacsそのものをエディタに指定するのではなく、emacsclient
（或いはgnuclient）というものを指定する（のが恐らく一般的だと思う）のです
が、これは起動しているEmacsに該当するファイルを渡すプログラムです。ですか
らこの場合、終了判断では難しいと思います。
しかし、それよりもまずは作業ファイルの名前に日本語を含めないようにする方
が先であると思うのですが（Emacsではファイル名化けています(笑)）如何でしょ
う。>GAEさん
[0272] 00/10/30 23:50 風葉(jmhR4bkKNz.): Re:267)エディタ
[0271] 00/10/30 21:08 Buckeye(UnTUYw5MC2c): Re:258)RE: プラグインでの書き込み
成功したらそのままのほうが無精できると思ったんですが……途中でキャンセル
された場合とかもあるから、やっぱり、成功したら消すか、またはS:行の投稿発
言・投稿保留などを示している部分を書き換えるといった処理をするほうが正当
でした。
投稿をINCMにまかせずにプラグイン側でやろうというくらいなら、無精しような
んて怠慢なこと考えちゃいけませんね(^^;)
Best Regards,
Buckeye
[0270] 00/10/30 10:40 でぐ(MVbPwfyRCtk): Re:260)RE: 掲示板のダウンロードの仕方はどうするの？
> 掲示板のダウンロードの仕方はどうするの？
ヘルプにあるように、INCMを解凍、起動。
フォルダを作成し、フォルダのプロパティで適切なプラグインを指定し、「巡回設定」画面でURLを入力。
後は巡回を始めさせれば、大抵の対応済みの掲示板の記事は取得できると思います。
不明点は風葉さんの書かれているように、ここよりも「INCM質問掲示板」へどうぞ。
→ http://www2s.biglobe.ne.jp/~gae/incm/qa/cyclamen.cgi
http://degitian.portland.co.uk/index.xml
[0269] 00/10/30 10:40 でぐ(MVbPwfyRCtk): Re:265)Re: 閉包
余りつづけるべき話題でも、個別の話を載せるべき場所でもないのは承知していますが、一度だけお見逃しください。
この書き込みに対する返信等は、メールでのみお受けさせていただきます。
> またPerlのモジュールでは、特殊なものを覗いて概ねPerl言語それ自身で記述さ
> れており、ブラックボックスと称するのは些か抵抗があります。(^^;
私は、次のようなDLL、モジュールその他については、ある程度信用することにしています。
・ソースが公開されていること
・ソースないし製作者のドキュメント上で、RFCその他への配慮を感じられること
時として、配布元の信頼性その他も加わりますが。
その上で私のモジュールの利用法はブラックボックス的です。
中身は覗けるし、問題を感じれば覗きますが、普段はそこまでしません。
あえて怪しげな造語を作らせてもらえば、「透明なブラックボックス」ですね。
同時に、私はスクリプトを以下のいずれかの条件でしか配布できあせん。
・フリーで、As-Isであることを承知の上で使うこと
・スクリプトを読み、理解したユーザーのみが使うこと
実のところ、プログラマのみにブラックボックスを信用するな、ということは言いたくありません。
ブラックボックスの排除に意味をもたせるなら、ユーザーにも使うなと言うつもりでいます。
それ以前に、ユーザーとプログラマを区別したくないのですが。
とはいえ、このポリシーについては今まで配布のプラグイン等に書き忘れていましたね。
次にリリースするときは、As-Isである旨を書き加えることにします。
あ、もちろん、私のスクリプトと同じ目的のスクリプトを作成、公開していただくのはまったく問題ありません。
例えば、Yahoo! ニュースプラグイン、モジュール不使用バージョンなど。
# きっとLWPのしている余計な処理がなくなって、速度も向上するのでは？
http://degitian.portland.co.uk/index.xml
[0268] 00/10/30 07:12 一 五明(YMjHyfzdazU): Re:261)RE: thread
>えと、申し上げたかったのは、掲示板が「スレッド表示を」サポートしているか
>ということです。
あ、これは未対応です(^^;
もともとあんまし書き込みの無い自分のページ用に作ったシステムなので、
INCMのサポートに使うには力不足気味です。
http://kt.sakura.ne.jp/~timeflow/M/
[0267] 00/10/30 07:12 一 五明(YMjHyfzdazU): Re:250)対応エディタを増やす
>友達によく言ってますが、なかなかやってくれません(汗)
難しいみたいですね(^^;
とりあえずエディタの終了を検知でなく、作業ファイルのタイム
スタンプを監視して、書き込みを更新するオプションを付ければ対応
エディタは増えるかも。
http://kt.sakura.ne.jp/~timeflow/M/
[0266] 00/10/30 06:02 たいふ〜ん！(.VUmowh0S8w): Re:264)RE: ダイヤモンドカーソル(^^ゞ
楽しそうな話題なんで、無駄だけど参加(笑)
僕自身もDOS時代の人間なんで、エディタと言えば必ずemacs準拠と言うのが
あたりまえの世界でした。（本物知らないんだけど・・・）
それがいつの間にかWin時代に入るとダイヤモンドカーソルすら標準でない
というのが納得行かないながらも、「ctlr＋なんたら」という操作法が
すっかり海馬から消えてしまいました。
コンピュータ社会って、退化してないかい？って思う今日この頃・・・
だからこそのINCM・・・こっそりでも応援したいのです。
http://homepage1.nifty.com/typhoon/at-cgi/incm/
[0265] 00/10/30 01:23 風葉(jmhR4bkKNz.): Re:263)Re: 閉包
ちょっと修正と補足。
まず修正。
> またPerlのモジュールでは、特殊なものを覗いて概ねPerl言語それ自身で記述さ
s/覗/除/;
補足。
> だからといってしかし、内部を全く知らずしてプログラムを進めるという考えに
> は賛成出来ません。
ここで先に挙げた「アプリケーション〜」と「ソフトウェア〜」の違いが起こる
と思います。
つまり「使えればいいや」が前者、「よく判らないものを使うのは…だから」が
後者であると思います。
ただ、流石にバイナリ配布されるようなライブラリパッケージの場合は付属文書
のみでは依然「よく判らないもの」として使わざるを得ないことは事実です。
また或いは、メッセージダイジェストに用いるMD5やSSLなど、使わざるを得ない
もので、それが何をするかは判るがどうなっているかは簡単には判らないものが
あることも事実です。
ですから、先程のメッセージで纏められませんでしたが、避けられないものであ
るならば「よく判らないもの」を甘んじて使わざるを得ませんが、他に方策があ
ればそれを使うのを避ける――というのが私のポリシーです。
＃ ――ので、押し付けるつもりは全くさらさらありません。
その方がスキルも付きますので。
じっくりLWPを読めばいいのですが、やっぱり他人のプログラムを読む行為は苦
痛です。(^^;
それが自分の記述スタイルから大きく離れていると尚更です。Perlは汚く記述し
ようと思えば出来てしまいますし。
[0264] 00/10/30 01:05 風葉(jmhR4bkKNz.): Re:250)Emacs
> > それにしてもINCMの時だけ妥協してメモ帳使うとかしたほうが楽そうな
> > 気がするんですが、Unix系に慣れてると体が受け付けないものでしょうか？
>
> 友達によく言ってますが、なかなかやってくれません(汗)
> 文章を書くだけで、編集らしいことはほとんどやらないから
> なんでもいいと思うのですが…。
そもそも、Emacsはエディタに止まりませんので一旦常習化すると最早社会復帰
がままならないほどです(笑)。
エディタとプログラム言語(Emacs Lisp)が一緒になっているのでカスタマイズは
思いのまま、各種テキスト入力をサポートするモード・ビヘイビアは勿論のこと、
メーラ、ニュースリーダ、ブラウザなどなど、広範に渡り使用出来ます。
多言語の同時表示も（フォントがあれば）可能で、今年頭に制定されたJIS2000
(JIS X 0213-2000)も表示出来るマルチリンガル環境を備えています。
個人的に気に入っているのはfont-lockで、例えばプログラム言語のモードでは
キーワードや其々の型に色がリアルタイムに付きます。
(snip)
…つまり逆説的に捕らえると、「中々離れられない」のです。
[0252]Buckeyeさん>
> ないのに、ウィンカーとワイパーがハンドルの右左反対についてるヤツです。し
> ょっちゅう、ウィンカーとワイパーを間違えてフラストレーションが溜まること、
> 請け合いです。
で、Emacsにどっぷりなので偶にWindowsキーアサインなエディタを使うと特にコ
ピー、ペースト、ページ送りの周りでイライラします。
＃ 「C(M)-W」と「C-C」、「C-Y」と「C-V」ですね。判る方はお判りでしょう。
アンドゥの場合もEmacsをアイコン化してしまうことがあります。(^^;
いやはや。
[0263] 00/10/30 01:03 風葉(jmhR4bkKNz.): Re:252)閉包
> モジュール使うと、エンコードだの送受信だの、簡単にできるらしいんですが、いかがです？
[0253]でぐさん>
> ということで、でぐとしては今後のプラグイン作成にモジュールの使用を推奨。
> 理由は「プラグイン作者が苦労することはない」「新しいモジュールに期待したい」ということです。
> 例えばLWPモジュールを使えば。
人さまのポリシーを批判する訳ではありませんが、私は（site）モジュールの使
用に関しては否定的であり、このことに関してはある意味、一 五明さんの仰ら
れた――
[0255]一 五明さん>
> ちなみにモジュールは使わない主義です(^^;;
に賛成するものです。プログラム再利用時代に何を――と仰られるやも知れませ
んが、ソフトウェアプログラミングを信奉する私、風葉には「アプリケーション
プログラミングならばそれでいいかも」というスタンスです。
確かにある特定の環境状況等に特化した規則・処理を何かしらの閉包に収めるこ
とに何等依存はありません。所謂カプセル化、オブジェクト指向ですね。
だからといってしかし、内部を全く知らずしてプログラムを進めるという考えに
は賛成出来ません。
またPerlのモジュールでは、特殊なものを覗いて概ねPerl言語それ自身で記述さ
れており、ブラックボックスと称するのは些か抵抗があります。(^^;
[0253]でぐさん>
> ・RFCだとかhttpの仕組みだとかをあまり知らなくて良い
Internetに関わるプログラミングを行うに際し、RFCを全く知らないというのは
問題があると思います。せめて基本的な原理（httpならばHTTP/1.0のRFC1945）
は目を通しておく必要があるのではないでしょうか。
P.S.
更にFTP用も…。(^^ゞ
[次のページ]