March 2000
Su Mo Tu We Th Fr Sa
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
flist->thread = g_new(pthread_t, 1);
pthread_create(flist->thread, NULL,
(thread_function_t)opendir_impl, (void *)arg);
GList *p;
GList *first = g_list_first(list);
GList *last = g_list_last(list);
for (p = first; p != last; p = g_list_next(p))
ほげほげ
}
「デザインパターン 改訂版」を買っちゃいました。
解説が詳しいですし、良く書けていると思います。
ので、超お勧めです。
> メイクファイル、作るの面倒くさい。
確かに、ファイル数が数十個ぐらいになるとかなり面倒ですよね。
ではMakefileを簡単に生成するようなツールを使ってはどうでしょう?
僕は、最近はGNUのAutomakeとAutoconfを使ってMakefileを作る事が多いです。Autoconfは究極の移植性を追求するツールで、AutomakeはAutoconfを楽に扱うためのツールと言ったところ。(ついでに、GNUへの信仰を表明するためのツールとの噂も。(笑)) Automakeを使うと書く量がかなり減ります。Autoconfはヘッダファイルや関数やデータ型がツールがあるかどうかや、他にも様々な事を調べてくれるconfigureというスクリプトを生成してくれます。ところが、このconfigureスクリプトは調べ方が凄い。ヘッダファイルの有無なんかはファイルを検索するという常識的な方法なんですが、関数の有無となると実際にその関数を含むプログラムをコンパイル・リンクしてエラーにならない事を確かめたりしてて、まさに目的のためには手段を問わない凄まじいツールです。便利なんですけどね。
> 確かに、補完機能はありませんけど、行編集機能と、ヒストリなら
> DOSKEYコマンドを実行すればできるようになりますよ。
へえ、そうなんですか〜 それは知りませんでした。
あまり知らない事についてグダグダ言うのは良くありませんでしたね。
すいません。
> 何で企業はLinuxを選ばないんだ？
Linuxを選ぶ企業って少ないんですか?
僕はそう言ったことは良く知らないんです。
(それに興味も無かったし・・・)
*** gtkmm-1.1.3.orig/gdk--/gdk--/gc.cc Thu Feb 25 03:56:05 1999
--- gtkmm-1.1.3/gdk--/gdk--/gc.cc Mon Mar 6 01:54:21 2000
***************
*** 272,278 ****
gchar dash_list[],
gint n)
{
! gdk_gc_set_dashes(*this,dash_offset,dash_list,n);
}
#endif
--- 272,278 ----
gchar dash_list[],
gint n)
{
! gdk_gc_set_dashes(*this,dash_offset,(gint8*)dash_list,n);
}
#endif
「デザインパターン」というのは、ソフトウェア設計の定石についての本です。 結構有名な本だと思うんだけどな〜 ちなみに、少し前にjlug.ml.usersで、 「プロなら以下の本で使われているテクニックは丸暗記すべき」という話があった。 全く同感で、プロでなくても教養として知ってた方が良いかなと思う内容。 「プログラミング言語C」 「プログラミング言語C++」 「Cプログラマのためのアルゴリズムとデータ構造」 「Booch法:オブジェクト指向分析と設計」 「デザインパターン」 > 使ってない関数やAPI宣言も > バンバンEXEに組み込まれるので・・・。 そういえば、決して呼ばれることの無い仮想関数をリンクしてしまう コンパイラというのはかなり多いはず。 いま、ファイルマネージャを書いているんだけど、 WaitForMultipleObjectのような変態的な機能がないので、 ちょっとスレッド回りが面倒。 Cでgtk+(http://www.gtk.org/)を使って書いていたんだけど、 クラスの扱いとかがちょっと面倒になって来たので、C++とGtk--にしようかな・・・
Date: Mon, 06 Mar 2000 22:35:18 +0900 (JST)
Message-Id: <20000306.223518.00733812.ZVM01052@nifty.ne.jp>
Errors-To: hogehoge1@foo.bar.ne.jp, hogehoge2@foo.bar.or.jp,
hogehoge3@foo.bar.ne.jp
To: ZVM01052@nifty.ne.jp
Subject: test of errors-to
From: ZVM01052@nifty.ne.jp
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
となっているメールを送ったとすると
Return-Path: ZVM01052@nifty.ne.jp
Date: Mon, 06 Mar 2000 22:35:18 +0900 (JST)
From: ZVM01052@nifty.ne.jp
Errors-To: hogehoge1@foo.bar.ne.jp, hogehoge2@foo.bar.or.jp,
To: ZVM01052@nifty.ne.jp
Subject: test of errors-to
Received: from smtp2.nifty.ne.jp (smtp2.nifty.ne.jp [202.219.63.54])
by ums501.nifty.ne.jp (8.9.3+3.2W/3.7W991006) with ESMTP id WAA14217;
Mon, 6 Mar 2000 22:36:41 +0900 (JST)
Received: from nifty.ne.jp (susho@fjsw0815.ppp.infoweb.ne.jp [202.208.38.79])
by smtp2.nifty.ne.jp (8.9.3+3.2W/3.7W-991025) with SMTP id WAA24073
for <ZVM01052@nifty.ne.jp>; Mon, 6 Mar 2000 22:36:39 +0900 (JST)
Message-Id: <20000306.223518.00733812.ZVM01052@nifty.ne.jp>
hogehoge3@foo.bar.ne.jp
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
X-UIDL: 38c3b49608PFQMQE
等となる。
Content-Typeとか、Content-Transfer-Encodingにつくこともあって、それで正常に表示できなかったので、気がついた。早急に直して欲しいものだ。
gtkはスレッド対応でコンパイルされていれば、いちおうスレッドセーフのはずです。 ただし、その下のXlibがスレッドセーフでない場合があるので、 gtk+がスレッドセーフでも安心できませんけど。 libcについては良くは解りませんが、使ってみた感じだと、 常識的な範囲内ではスレッドセーフのようです。 これもバージョンによりますね。 ところで、私もC言語の勉強を兼ねて、 gtkベースのファイルマネージャを実装してみることにしました。 当然スレッドを多用しているのですが、上記のような理由から、 「gtk(とX)にはメインスレッドからしかアクセスしない」 という方針で実装しています。 (そのため、DelphiのVCLで使われているような、 ちょっとトリッキーな方法を用いました。) まだ、基礎的な部分しか実装できていないのですが、 スレッドを使っている方がずっと快適です。 ただ、一方でスレッドを無効にしてもそこそこ高速に動作しています。 ということは、Cxploreはスレッド採用以外にも 最適化の余地がけっこうあるように感じました。 もう少しコードを整理したら、公開しようと思うので、 少しは参考になるかも知れません。 # やっぱり、C++とGtk--の方が楽だな〜 ついでですが、国際化するつもりは無いですか? 現在は日本語ロケール以外で使うとアレなので、 ロケールとかgettext(or catget)とかを活用した方が良いと思いますよ。
> 「夜明けのブギーポップ」が置いてなかった。(TT
> その他は山積みされてたのに。(^^;
そういうことって結構ありますよね。
僕も先日本屋にいったら、「風の大陸」のお目当ての巻だけ置いてなかったです。
# のでなんとなく、Danielle Steel の「THE GHOST」を買って来ました。
# それにしても、US $7.50の本が￥1380なんて暴利だ〜
(プロセス間通信)
> ActiveX EXEを使わずにプロセス間でやり取りとかしてみたい。
> 何となく可能な気もするし。
{名前付きパイプ or ソケット or メールスロット} and 共有メモリ(メモリマップトファイル)
ただし、WindowsAPIだと、新しく作成したプロセスにハンドルを渡すのが少し面倒だな。(ユニークな名前のメモリマップトファイルを使うのが定石か?)
ソケットを使うと双方のプロセスが同じホスト上で動作している必要が無くなるので、特に理由がないなら、ソケットがお勧め。(とは言っても、別のホストだったら共有メモリなんて使えないけどね。)
# UNIXのforkシステムコールは便利だが、これも凄まG〜
# (プロセスをフォークするなんて普通の発想じゃないぞ。)
# これを設計したのは天才かキチガイに違いないぞっと。
(スレッド)
スレッドは、DelphiではTThreadクラスを継承してExecuteメソッドをオーバーライドするっす。(このExecuteメソッドが実際に別スレッドで実行される処理) ただ、VCLはスレッドセーフじゃないので、TThreadにはSynchronizeというメソッドがあって、こいつにメソッドポインタを渡してやると、同期的に実行してくれるので、けっこう便利でした。
VBでもMutexを使って自前で排他処理を行なうとか、同期的に実行する仕組みを自前で用意してしまえば、問題ないのでは?
僕が今書いているファイルマネージャでも、gtk+の下位のxlibがスレッドセーフじゃないバージョンかも知れないので、念のため後者を選択しました。それに、何たって扱いが楽だもんね。^^;;
> WaitForMultipleObjectってそんなに便利なんですか？
> う〜ん、変態的とは・・・。
同期を取るために使用できるオブジェクトは、「イベント」, 「ミューテックス」, 「セマフォ」あたりが常識的な範囲だと個人的には思うのですが、WaitForMultipleObjectはさらに「FindFirstChangeNotificationの変更通知」, 「コンソール入力」, 「プロセス」, 「スレッド」が使えちゃうのです。(他にも何かあったかな?) しかも複数の同期オブジェクトを指定できるし。
逆にPOSIXのモデルは非常に洗練されているけれども、少し頼りない印象を受けるな。もっとも、今までそれで困ったことは無いけれど・・・
(製作依頼掲示板) > 制作依頼掲示板を新しく設置。 Cosource.com とか sourceXchange みたいなやつですかね。 http://www.cosource.com/ http://www.sourcexchange.com > 共有希望者はSouthern Windさんまで。。。 Windows限定でなければ、参加してみようかな。> Southern Windさん (スレッドとプロセス) > DelphiではTThreadクラスを継承してのマルチスレッドですか。 > なるほど、ためになるなぁ〜〜。 Javaも似たようなもんですが、もうちょっと面白いです。^^;; Javaでは、2通りの使い方があって、 最初の方法はThreadクラス(jave.lang.Thread)を継承して、 runメソッドをオーバーライドする方法です。 これは、Delphiとほぼ同じですね。 もう片方は、Threadのコンストラクタに Runnableインターフェースのインスタンスを渡す方法です。 すると、そのオブジェクトのrunメソッドが新しいスレッドで実行されます。 一見すると奇妙な設計に見えますが、実は、 Threadクラス自身がRunnableインターフェースをimplementしているので、 コンストラクタでRunnableインターフェースのインスタンスが渡されればそれを、 渡されなければ自分自身を、Runnableとしてrunを呼ぶ事になります。 # Javaは楽ですよ〜 > とりあえずVB既存の命令がめちゃくちゃ落ちやすくなります。 ですから、Mutexを使って同時に「VB既存の命令」を呼び出すスレッドを 一つに限定しては? と言うことです。 でも、これはこれで面倒ですね。 > forkシステムコール > これまた便利なんですか？ fork()が実行されると、 同じプログラムが子プロセスとして動きはじめるのですが、 何と子プロセスもfork()を呼び出した状態から実行が始まるんです。 ワーオ!! 親がfork()を呼び出した時点ではプロセスは両方ともfork()内を実行していて、 それぞれが同じようにfork()からreturnします。 ただし、forkの戻り値は異なる (親プロセスでは子プロセスのID, 子プロセスでは0, 失敗すると-1) ので、新しいプロセスがどうかは区別できます。 どれほど便利かは自明だと思います。 (たとえば、子プロセスにデータを渡す必要性が無い点など。) この常軌を逸した発想はまさに天才的だと思います。 # DDEを旧時代のIPC(プロセス間通信)とするなら、 # 最先端だとCORBAやDCOMとかっすかね〜 # RMIはJavaでしか使えないし。 (メソッドポインタ) > 所でメソッドって実体は関数と変わりないのでしょうか？ > メソッドのポインタから普通の関数呼び出しで実行しても > やっぱりうまく行かないのかな・・・。 ちょっとこころさんの意図するところがよく解らないのですが、 もし、ポインタをキャストして呼び出すという意味なら、 うまくいかないと思います。 *Delphi(とC++Builder)だと*、メソッドポインタ(C++Builderだとclosure)の バイナリレベルでの実体は、オブジェクト自身へのポインタと メソッドのVMT(仮想メソッドテーブル)へのポインタからなる構造体です。 (ゆえにポインタ2つ分のサイズがあるので、 通常の関数へのポインタとは相互に代入できない。) メソッドを呼ぶ処理は実際には、VMTを検索して実際に呼び出す関数を決定し、 (隠された)第一引数にオブジェクトへのポインタを与えてこの関数を呼び出します。 メソッド内で自分自身を参照する時(Delphiでのself, C++でのthis)、 この隠れた引数が用いられています。 コンストラクタの扱いはちょっと違ったと思うけど覚えてない。 C++だと、Delphiのようなメソッドポインタの概念はない。 メンバ関数へのポインタという概念はあって、 多分内部的にはVMTへのポインタなんですが、 実際に呼び出すときにはオブジェクトを与える必要があります。 そのくせ通常のポインタと互換ではない。 さらには、メンバ関数へのポインタは宣言するときにクラスを 与える必要があり、この点でも任意のオブジェクトのメソッドへの ポインタを格納できるDelphiのメソッドポインタと比較できるものではない。 具体的には、Delphiだと、 type TTestMethod = function(Foo: Double): Integer of object; var TestMethod: TTestMethod; のように宣言して、使い方は、 TestMethod := @AnObject.AnMethod; TestMethod(Bar); のようにするのに対して、C++だと typedef int (AnClass::*fptr)(Foo: double); のように宣言して fptr s_fptr = &TheClass::AnMethod; (AnObject.*TestMethod)(Bar) のように使います。ウゲー C++だとstaticなメンバ関数の実体は普通の関数と変わりありません。 ので、当然仮想関数にもできません。 (でも、C++はクラス自身はfirst class objectでないので、 仮想関数に出来ても特に嬉しいわけではない。) Javaでもメソッドへの参照型という概念は無かったと思うけど、 イベントハンドラとかはアダプタ/リスナを使うので、別に不自由しない。
> > > これも同じく興味がありません。日本語Onlyです。 > > それは残念ですが、興味が無いのは仕方ありませんね。 > > では、私(か誰か他の人)が作業を行なったら、 > > その成果は取り込んでくれますでしょうか? > > (というか、ライセンスはどうなってるんだろう・・・) > 成果によりますね（笑）。 > 私の目的に添うような成果であってくれれば取り込みも可能です。 じゃ、適当に国際化に挑戦してみます。 僕の自作中のファイルマネージャですが、 けっきょく、飽きて来たので、 http://homepage1.nifty.com/susho/software/amethyst/amethyst-0.0.1.tar.gz に現在のスナップショットを置いておきます。 gtkやUNIXのAPIにとても苦戦しました。 ディレクトリとファイルを表示するだけで、 ファイルを操作したりする機能はまだ一切実装していませんし、 ソースコードもきちゃないです。 多分、また気が向いたら作業すると思います。 あんまり参考にならなそうですいません。 大口叩いた割に情けないです。
make[2]: Entering directory `/usr/src/linux98-2.3.48/arch/i386/boot/pc9800'
gcc -E -D__KERNEL__ -I/usr/src/linux98-2.3.48/include -D__BIG_KERNEL__ -traditional -DSVGA_MODE=NORMAL_VGA bootsect.S -o bbootsect.s
as -o bbootsect.o bbootsect.s
bbootsect.s: Assembler messages:
bbootsect.s:729: Error: base/index register must be 32 bit register
bbootsect.s:737: Error: base/index register must be 32 bit register
bbootsect.s:738: Error: base/index register must be 32 bit register
bbootsect.s:739: Error: base/index register must be 32 bit register
bbootsect.s:996: Error: base/index register must be 32 bit register
make[2]: *** [bbootsect.o] Error 1
起動時に実行させたいだけなら、 HKEY_LOCAL_MACHINEのSOFTWARE\Microsoft\Windows\CurrentVersion\run 以下に書くのが楽。 VC++では、リンカのオプションに/SWAPRUNを指定すると、 普通に自分自身の実行ファイルを消せるようになりますよ。 ・・・って、どうしてこんなしょうもない事覚えてるんだろ。 忘れろ忘れろ > れお
You must use binutils 2.9.1.0.7 or later. Latest release is 2.9.1.0.25. Beware that binutils 2.9.1 (note the absence of a suffix) from the FSF does not work. If you are upgrading from earlier versions, you should consider upgrading to the latest 2.9.5.0.x (beta) release.
gcc -O3 -I./gc -I/usr/local/ssl/include/openssl -I/usr/local/ssl/include -I. -o w3mhelperpanel w3mhelperpanel.o -L. -lindep gc/gc.a -lm -lgpm -lbsd -lncurses -L/usr/local/ssl/lib -lssl -lcrypto
/usr/bin/ld: warning: libncurses.so.3.4, needed by /usr/lib/libgpm.so, may conflict with libncurses.so.3.0
2000年 3月 23日 (木) 14時 18分 57秒現在
あなたは 71.3%
コンピュータに汚染されています。
かなり危ないです。背中を押されたらあっという間に落ちていきます。
もし周りに悪友がいるのなら、すぐに手を切るべきでしょう。
自分のWebサイトがあるのなら閉鎖すればまだ間に合うかも知れません。
これ以上踏み込むと後戻りは絶対に出来ません。
というか、後戻りするには相当な訓練が必要でしょう。
人間としての尊厳をまだ持っているのなら今しかありません。
貴方はどちらかというと、UNIXマニアですね。
Windowsのコマンドラインでつい「ls」などと叩いて
悔しい思いをしていることが多いことでしょう。
打倒ゲイツOSを掲げて日々精進してください。
よっ! どうしたのかって? 心配すんじゃねえ。愛の告白なんかじゃねえから。 いや、まあ言い残したことがいくつかあってさ。 まず、謝りたい事が一つ。 文化祭の話だ。 (snip) 君はこれまで出会った人間のなかで、もっとも不可解な存在だった。 すべてを見下しながら、同時にそれから離れることを拒絶する。 ずぼらでいて、でもとても真面目だ。 言いたくてたまらないのに、いつも沈黙している。 矛盾している? いや、そうじゃない。 矛盾じゃないよ。これらは全然矛盾しない。 誰であれ、人間はこういったものだ。 ただ、君はひどく不安定に見える・・・僕の目には。 何かを恐れているようだ? 君の現実が変わってしまうことを? でも、君はそれを望んでいる。違うかい? (snip) 俺は君を認めてる。 だから、もっと胸をはったっていいじゃないか。って思ったわけ。 俺なんかに言われてもしかたないって? ははは、それもそうだな。sigh でも、どうしてこんなことを話す気になったんだろ、とても不思議だ。 もう、会うことは無いかも知れない。 でも、また会えるといいな。 あ、同窓会とかあるか。 んじゃね!
と言われてしまった。imlibは1.9.4を使っているのに一体どうした事だ! 実害は無かった。checking for IMLIB - version <= 1.8.2... no *** Could not run IMLIB test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means IMLIB was incorrectly installed *** or that you have moved IMLIB since it was installed. In the latter case, you *** may want to edit the imlib-config script: /usr/local/bin/imlib-config
deborah# /etc/rc.d/can35b2.r start
Starting Canna server:
ERROR:
Another 'cannaserver' is detected.
If 'cannaserver' is not running,
"/tmp/.iroha_unix/IROHA" may remain accidentally.
So, after making sure that 'cannaserver' is not running.
Please execute following command.
rm /tmp/.iroha_unix/IROHA
deborah# /etc/rc.d/rc.pgsqld
FATAL: StreamServerPort: bind() failed: errno=1
Is another postmaster already running on that port?
If not, remove socket node (/tmp/.s.PGSQL.5432) and retry.
/usr/local/pgsql/bin/postmaster: cannot create UNIX stream port
/usr/local/pgsql/bin/pgsqld: start failed.
if(hw_config->io_base != -1 || hw_config->irq == -1 || hw_config->dma == -1) {
printk(KERN_WARNING "ad1848: must give I/O , IRQ and DMA.\n");
return;
}
#ifdef CONFIG_PROC_FS
create_proc_read_entry("net/unix", 0, 0, unix_read_proc, NULL);
#endif
でも、unix_read_procって書き込む前にlengthを見てないっすよ。これってオーバーフローの恐れは無いのだろうか。やっぱり、こういうところにはコメントが欲しいな、と思った次第。
*** udp2tcp.cc.orig Tue Mar 28 15:44:23 2000
--- udp2tcp.cc Tue Mar 28 15:44:35 2000
***************
*** 312,314 ****
printf("accepting....\n");
! size_t sin_size = sizeof(struct sockaddr_in);
tcp_new_sock = accept(tcp_sock, (struct sockaddr *)&tcp_remote_addr,
--- 312,314 ----
printf("accepting....\n");
! int sin_size = sizeof(struct sockaddr_in);
tcp_new_sock = accept(tcp_sock, (struct sockaddr *)&tcp_remote_addr,
Gnome-ERROR **: Could not create per-user Gnome directory </home/susho/.gnome> - aborting
依頼という程でもないんだけど、今こういうソフトを探しています。 どこかにないかな〜 もしくは、誰か作ってくれないかな〜 ・ MHonArcでHTMLに変換されて公開されているMLのログから、 メールを指定してそれに連なるスレッドを一括取得するツール ・ CVSのGUIフロントエンド (ただし、最低でもX Window System と Windows をサポート) ・ GIMP用のウェーブレットを利用した画像処理と MRA(多重解像度解析)を行なうプラグイン あと、eicq(http://www.sfu.ca/~stephent/eicq/)のGNU Emacs対応も希望しときます。 自分でもいじくっているのですがLispは初心者だし XEmacsについても良く知らないので・・・