トップページ⇒unix
987コメント301KB

全文検索エンジンEstraier

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。NGNG
個人用途向けの全文検索エンジンEstraierに関する話題を扱う
スレッドです。

http://estraier.sourceforge.net/
0202名無しさん＠お腹いっぱい。2005/05/03(火) 13:09:05
Hyperestraierでestcmd gatherするとき、
sym link をdereferenceしないようにお願い
したいんだが、どうすれば良い？
0203名無しさん＠お腹いっぱい。2005/05/04(水) 16:46:01
中の人に言えば?
02042022005/05/04(水) 20:12:26
static const char *pathtourl() のなかで
realpath()を呼んでるからだ、つうとこまでは分かった
んだが、絶対パスに展開するのやめさすと各方面に
色々面倒が起きそうな希ガス。
>>203の言うとおり、作者に頼むしかないかな。
0205名無しさん＠お腹いっぱい。2005/05/04(水) 21:30:07
APIの呼び方さえ変えなければ特に問題ないと思うけど。
MLに投げれば対応してくれるかも。
0206名無しさん＠お腹いっぱい。2005/05/08(日) 11:02:50
mboxファイル用のフィルタはないですか?
0207名無しさん＠お腹いっぱい。2005/05/08(日) 18:34:26
>>201
高林さんとかの JavaScript を参考に組めば出来ると思うけど、
たぶんめっちゃおもくなるとおもわれ。
0208名無しさん＠お腹いっぱい。2005/05/08(日) 20:54:44
>>207
>>201 は Ajax なインターフェースのことを言ってると思われ。
0209名無しさん＠お腹いっぱい。2005/05/08(日) 20:59:06
>>208
> >>201 は Ajax なインターフェースのことを言ってると思われ。

ちがう。
0210名無しさん＠お腹いっぱい。2005/05/08(日) 21:01:23
>>207
> 高林さんとかの JavaScript を参考に組めば出来ると思うけど、
> たぶんめっちゃおもくなるとおもわれ。

migemoのアイデアって、1990年ころに、プライベートな
研究会で見たことがあるよ。いや、べつにそっちの方が
先だとか言いたいわけではない。みんな同じことを考え
ていたんだということ。で、「たぶんめっちゃおもくな
るとおもわれ」とコメントされ、それで終わっていた。
0211名無しさん＠お腹いっぱい。2005/05/08(日) 21:46:12
>>209
ありゃ、違うのか。 >>208 で合ってたのかな。
0212名無しさん＠お腹いっぱい。2005/05/08(日) 22:30:05
Ajax風に難しいことをやるのでなければ、
onChangeイベントでsubmitするだけでしょ？

たぶんめっちゃおもくなるとおもわれるけど。
0213名無しさん＠お腹いっぱい。2005/05/08(日) 22:34:28
前に Ajax でリクエストをばんばん飛ばすスクリプト書いたけど、結構レスポンス良かったよ。

ただ、インクリメンタルにする意義が感じられなくて結局使ってないけど。
0214名無しさん＠お腹いっぱい。2005/05/08(日) 22:42:49
インクリメンタル検索って、オモチャとしては面白いけど、実用的ではないよね。
エディタで使うみたいに、一個のファイルの中をインクリメンタル検索するのは便利
なんだけど、不特定多数の文書をファイルを対象にた場合は意味がない。
インクリメンタルである利点は、前後関係が確定している場合にのみ享受できる。
0215名無しさん＠お腹いっぱい。2005/05/08(日) 23:39:23
エディタでも実用的じゃないし
0216名無しさん＠お腹いっぱい。2005/05/08(日) 23:41:20
インクリメンタルなんてほしがるのは素人だけ。
あれは単なるけばけばしい包装、はなばなしいだけの
ファンファーレ。
そんなものをほしがるやつには、UNIXを使う資格はない。
0217名無しさん＠お腹いっぱい。2005/05/08(日) 23:50:04
プログラマなら、エディタのインクリメンタル検索は使いまくる
と思うんだけど、みんなは違うの?
0218名無しさん＠お腹いっぱい。2005/05/08(日) 23:58:20
目と頭が付いていけないから使ってない
俺の言う事を最後まで聞け（ｺﾞﾙｧ　と思う事多し

動的なインターフェイスは使用者に掛かる負荷が大きいんだよね
何も考えずにインクリメンタルサーチ使える人は正直感心する
0219名無しさん＠お腹いっぱい。2005/05/09(月) 00:14:29
んなこと言ってたら自動車の運転もできないじゃん。
0220名無しさん＠お腹いっぱい。2005/05/09(月) 01:27:21
これは複数サーバ(or ディスク)を使って分散処理を行う事は出来るの？
チュートリアルにそれに関した記述が見当たらなかったんだけどやっぱり無いのかな。
0221名無しさん＠お腹いっぱい。2005/05/09(月) 01:55:12
estの方はできるでしょ。hyperの方は知らない。
0222名無しさん＠お腹いっぱい。2005/05/10(火) 11:37:13
自分でインデックスを更新するのでなく、新しく保存したファイルを自動検知
してその分だけ更新するようにできないかな。
0223名無しさん＠お腹いっぱい。2005/05/10(火) 12:03:00
>>222
もちろんできるでしょ。
0224名無しさん＠お腹いっぱい。2005/05/10(火) 12:38:46
新しいかどうかを検査する負荷もバカにならないから現実的じゃ無い気も。
0225名無しさん＠お腹いっぱい。2005/05/10(火) 13:04:17
>>224
そう思うなら、口を閉じて引っ込んでろ。
0226名無しさん＠お腹いっぱい。2005/05/10(火) 13:34:10
FAMとかgaminとか使うといいかも。
FAM：http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_Developer/books/IIDsktp_IG/sgi_html/ch08.html
gamin：http://www.gnome.org/~veillard/gamin/

いずれにせよOS依存なので、自分の環境にかなり精通していないと難しいだろう。
Google Desktop Searchはどうやってるのか知ってる？
0227名無しさん＠お腹いっぱい。2005/05/10(火) 13:51:17
>>225
なにそんなカリカリしてるの？
02282222005/05/10(火) 14:26:13
>>226
どうもです。でもプログラミングしないといけないのは辛いですね。
過去1時間に更新された更新ファイルのパスのリストがどっかのファイル
に記録されているような仕様だったら嬉しいのですが。

あ、ちなみに225は私じゃないですよ。
0229名無しさん＠お腹いっぱい。2005/05/10(火) 14:41:52
>>223
それどうやるの？
0230名無しさん＠お腹いっぱい。2005/05/10(火) 15:02:09
>>226
Beagleは使える環境の場合はInotifyを使うみたい。
0231名無しさん＠お腹いっぱい。2005/05/10(火) 16:15:10
dnotifyだと指定したディレクトリ直下しか見れなかったけど、
inotifyでもそこんとこは変わってないよね?
監視対象を再帰的に広げるよりは、定期的にfindした方が負荷が小さいような。
0232名無しさん＠お腹いっぱい。2005/05/10(火) 16:32:35
>>231
そう思うなら、口を閉じて引っ込んでろ。
0233名無しさん＠お腹いっぱい。2005/05/10(火) 16:40:20
>>231
軽量高速な更新検出手段の探求/実現が必要ですねッ!!
0234名無しさん＠お腹いっぱい。2005/05/10(火) 16:47:45
>>233
ガンバレー！！
0235名無しさん＠お腹いっぱい。2005/05/10(火) 17:44:25
高速じゃなくてもいいなら、適当にsleepして軽量にすることは可能だろう。
明示的に更新を通知する手段と、更新頻度が高い場所は巡回頻度も高めると
いった工夫を併用すればかなり使いやすくなるんじゃない?
0236名無しさん＠お腹いっぱい。2005/05/10(火) 17:54:10
>>232
そうカリカリすんなよ。歯痛にでもなったか?
0237名無しさん＠お腹いっぱい。2005/05/10(火) 23:44:55
あとOracleのFull-Text Searchは専用のデーモンを立ち上げて監視させる
仕組みになってたと思う。
0238名無しさん＠お腹いっぱい。2005/05/11(水) 18:00:03
ファイルシステムから作ればいいんだっ！！
0239名無しさん＠お腹いっぱい。2005/05/11(水) 18:20:12
>>238
わかった。全部お前にまかすわ。あとはよろしくな。
0240名無しさん＠お腹いっぱい。2005/05/11(水) 18:24:58
あと重要なのは、特定の格納形式/更新形式を持つファイル群を
ハンドリングするプラグインを扱う枠組みだな。
0241名無しさん＠お腹いっぱい。2005/05/11(水) 18:29:16
>>240
わかった。そっちはお前にまかすわ。あとはよろしくな。
0242名無しさん＠お腹いっぱい。2005/05/11(水) 18:53:11
APIがあるからアプリケーション主導で開発できるわけで、
プラグイン機構は不要だと思われる。
それよりPerlかRubyのバインディングを早く出してほしい。
0243名無しさん＠お腹いっぱい。2005/05/11(水) 19:57:37
>>242
いや、じゃなくて、新しい文書扱いシステムを作った側が、
検索エンジンがそれを効率良く扱えるように
一連の設定やプログラミングを行なう枠組みが
いるのではないかという話だ。
02442422005/05/11(水) 22:48:38
なるほど。
更新処理をトリガとして関数が呼ばれる仕組みが大抵のDBには備わっているけど、
一般的な文書扱いシステムではどうなんだろう。
0245名無しさん＠お腹いっぱい。2005/05/12(木) 11:45:47
監視対象のディレクトリがわかっているなら、そのディレクトリに対して
select() かけることで対応できないかなあ｡
0246名無しさん＠お腹いっぱい。2005/05/12(木) 12:18:15
それだとcreatとunlinkは検出できるけど、writeが検出できなくない?
0247名無しさん＠お腹いっぱい。2005/05/14(土) 02:55:39
日本製全文検索が開発中のもよう
Rast: A full-text search system
ttp://www.netlab.jp/rast/

●検索対象となる文書の分野や言語を選ばない
テキストデータを n 個の文字の並びである N-gram に分割して検索を行うため，「検索漏れが生じない」，「辞書の整備が必要ない」という特徴がある N-gram 方式を選べます．
これにより，検索対象となる文書の分野や言語を選ばずに広く利用することができます．

●多様なファイル形式への対応
HTML や Microsoft Word といった多様なファイル形式の文書からテキストデータやタイトルや作成日などの属性情報を抽出し，検索対象にできます．

●全文検索ライブラリの提供
C 言語と Ruby で利用可能な全文検索ライブラリを提供することにより，本ソフトウェアを利用した全文検索を行うアプリケーションを開発することができます．
さらに，ライブラリの利用例として，過去のメールを全文検索できる電子メールソフトを開発します．

●インクリメンタルな文書の追加登録
作成したデータベースに対して，インクリメンタルに文書の追加登録ができます．このため，一度作成したデータベースを作成し直す必要がありません．


誰か試して
0248名無しさん＠お腹いっぱい。2005/05/14(土) 03:58:31
精度とかはまだまだ。euc-jpだとutf-8にくらべてバグが多い気がする。
C APIを提供してるわりにクライアントライブラリまでGPLなのはちょっと痛い。

せめてXMLRPCの仕様を公開してほしいが、だったらEstraierのノードAPIを
待った方が幸せになれそう。

Matzのお膝元のnetlabで開発してるので、Rubyを使ったアプリケーションが
いろいろ出回ってきたら面白くなるのかもしれない。
0249名無しさん＠お腹いっぱい。2005/05/14(土) 17:02:09
Rubyがどうしたとかテストにはtcl使ってね
とか言われた時点でもう、センスつうか趣味
つうか合わないを思いますわ、パスですわ
>>247
0250名無しさん＠お腹いっぱい。2005/05/14(土) 17:18:49
>>249 Perlだったらいいわけか?
0251名無しさん＠お腹いっぱい。2005/05/14(土) 19:50:07
Javaだったらよかったのにね。
0252名無しさん＠お腹いっぱい。2005/05/14(土) 20:45:23
>>251 lucene
0253名無しさん＠お腹いっぱい。2005/05/14(土) 22:58:21
hyperestraier 0.3.8 コンパイルしないな。
ML archive も落ちてる。
0254名無しさん＠お腹いっぱい。2005/05/14(土) 23:58:14
「QDBMのバージョンが古い」に一票 >> 253
02552532005/05/15(日) 07:59:47
その通りだった。トンクス >>254
02562542005/05/17(火) 00:09:15
俺もはまったからさ。
0257名無しさん＠お腹いっぱい。2005/05/25(水) 10:37:35
0.3.10あげ
http://hyperestraier.sourceforge.net/
0258名無しさん＠お腹いっぱい。2005/05/25(水) 16:35:21
インクリメンタル検索がサポートされたね
0259名無しさん＠お腹いっぱい。2005/05/25(水) 22:28:14
>>258
SUGEEEEEEEEEEE!!!!!!!
0260名無しさん＠お腹いっぱい。2005/05/27(金) 18:44:35
rastをCygwinで構築出来た人いる？
0261名無しさん＠お腹いっぱい。2005/05/31(火) 23:04:02
OpenSearch対応してくんないかな
0262名無しさん＠お腹いっぱい。2005/06/01(水) 11:26:51
今日から金曜まで東京ビッグサイトで開催中の LinuxConference では、

6/2 13:00〜 「全文検索システム Rast の設計と実装」
6/3 10:00〜 「全文検索 BOF」

などという企画をやってる。
0263名無しさん＠お腹いっぱい。2005/06/04(土) 22:50:24
げ、昨日か… (;´Д`)ﾊｧ
0264名無しさん＠お腹いっぱい。2005/06/04(土) 23:10:40
Googleの文字が全部四角になってしまいました。
（□←ばかり）どうしてか教えてください。
0265名無しさん＠お腹いっぱい。2005/06/05(日) 00:05:25
坊やだからさ。
0266名無しさん＠お腹いっぱい。2005/06/05(日) 00:20:49
どうすれば大人になれますか？
0267名無しさん＠お腹いっぱい。2005/06/05(日) 00:54:33
>>266
「電車男」という映画を見に行くとなにかヒントが得られるかもしれません。
0268名無しさん＠お腹いっぱい。2005/06/05(日) 18:28:53
噂通り、インデックス作成がやたら速いね。
並列化できればGoogleとかに匹敵するんじゃないか?
0269名無しさん＠お腹いっぱい。2005/06/06(月) 10:22:14
>262
全文検索BOFでは、NAMAZU開発者とRast開発者とHyper Estraierの開発者が
一堂に会して、開発思想とかを語ってくれた｡
ただ、2時間もあった割には突っ込んだ話ができず、薄かった感じがする｡
0270名無しさん＠お腹いっぱい。2005/06/10(金) 22:35:21
Python&Perl&Rubyバインディングキターーーー
http://tokuhirom.dnsalias.org/~tokuhirom/tokulog/1193.html
0271名無しさん＠お腹いっぱい。2005/06/10(金) 23:07:46
コアAPIのバインディングかぁ...
Rastと違ってAPIがリモートとローカルで違うらしいから、
やっぱノードAPIを待った方がいいんじゃないかと思う。
0272名無しさん＠お腹いっぱい。2005/06/10(金) 23:27:57
パフォーマンスを考えるとコアAPI使って自分でサーバ書いた方がよかないか。
RubyとかだとHTTPサーバのツールキットもあるわけだし。
0273名無しさん＠お腹いっぱい。2005/06/11(土) 10:40:11
HTTPd を自前で実装する、というときにパフォーマンスを考えるならスクリプト言語の
バインディングをわざわざ選ぶかなぁ?

むしろスクリプトで書いたプログラムにいちいちサーバ立てるのやってらんないという
面倒くさがり向きなんじゃないの。
0274名無しさん＠お腹いっぱい。2005/06/11(土) 16:42:53
いや、HTTPdを実装すること自体にスクリプト言語が向いていると思う。
Cでなんてやってられない。
0275名無しさん＠お腹いっぱい。2005/06/12(日) 03:31:38
そうかなぁ... libapr とか使ってみれば?
ちょうどいいから rast のソースでも読んでみなよ。

といいながらも ruby が楽しくなりつつある今日この頃です。
0276名無しさん＠お腹いっぱい。2005/06/12(日) 09:49:52
APRはやばいでしょ。
WEBrick+HyperEstraierとかWEBrick+Rastってのが強力かつ簡単でよさげ。
0277名無しさん＠お腹いっぱい。2005/06/12(日) 15:35:53
>>276
ライセンス問題?
0278名無しさん＠お腹いっぱい。2005/06/12(日) 23:07:12
これってCygwinでも動きますか？
0279名無しさん＠お腹いっぱい。2005/06/24(金) 07:37:52
デスクトップサーチっぽいのが出たね。
まだ作りこみが甘い感じだけど、今後に期待age。
http://www.mitsuki.no-ip.com/~seagull/software-archives/hyperestraier/gdestraier.html
0280名無しさん＠お腹いっぱい。2005/06/24(金) 09:56:05
もうでさぽ
0281名無しさん＠お腹いっぱい。2005/07/04(月) 01:40:52
>.279
open/closeシステムコールをを監視してスポットライト風にインクリメンタルアップデートが
できると面白そう。ガンガレ。
まずは更新があったファイルを指定するとその情報のみをアップデートする機能が
必要だな。既存のものだと全部を指定してアップデートする方法しか用意されてないからな。
0282名無しさん＠お腹いっぱい。2005/07/04(月) 18:08:11
>> 281
いちお、estcmdに-sd -cm 付けてるです。
だから全更新してもタイムスタンプの新しいやつ以外はスキップされるですよ。
0283名無しさん＠お腹いっぱい。2005/07/06(水) 00:48:17
>>281
namazuにしろなんにしろ従来のは全更新しかなかったと思うんだよね。
だから、逆に一部更新はできるのかと。
編集した利用者ならどこを編集したかわかっているわけだから全更新して
全部のディレクトリをなめる時間待たされるよりも更新した箇所を指定して
updateできたほうがよくない？

んで、その上でシステムコールを監視してスポットライト風アップデートですよ。
0284名無しさん＠お腹いっぱい。2005/07/06(水) 03:03:16
システムコールの監視はカーネルに手を入れるかアプリをVM上で動かすか
しないと難しいんじゃない? いずれにしても、オーバーヘッドがでかくなってしまう。
移植性の問題もあるし。

よく更新されるディレクトリの監視頻度を上げるのと、ユーザが明示的に更新を指示
をするのを併用すれば実用上は十分だと思うけど。メールボックスとかだったら、アプ
リケーションのプラグインかなんかで更新ロジックを組み込めるといいね。
0285名無しさん＠お腹いっぱい。2005/07/06(水) 10:40:58
カーネルまで触らなくても、ファイルシステムに細工をすればできるんじゃないか。
Windowsじゃ無理だけど、UNIX系ならそのへん独立してるし｡

WinFSには全文検索っぽい機能が組み込まれているというウワサも聞いたけど、
どうなんでしょ。
0286名無しさん＠お腹いっぱい。2005/07/06(水) 10:49:45
>>283
Hyper Estraierは、ディレクトリでなくファイルそのものを指定して
インデックスに登録できるよ。


>>284
famを使い、特に指定されたディレクトリだけ監視。
移植性と監視コストの問題はfamに丸投げして、各プラットフォームに最適
なアルゴリズムで監視できる事を期待。


更新された時に即座に更新だと確かにオーバヘッドが大きすぎなんで、
遅延してある程度のまとめ更新するデーモンをniceしておけば実用的な
範囲に収まるっぽくね？
いくらなんでも、数分前に更新した文書くらい探さなくても判るだろ。


それより問題は、インデックスをユーザ毎に持つと重複が多すぎるって
事だな。サイズもそうだけど、オーバーヘッドも整数倍になる。
業務の書類とかmanページを探したい時なんか完全に重複だね。

インデックス中の文書データに対するパーミッションをなんとかして、
システムグローバルなインデックス&検索機能のデーモン化をしないと
現実的でないような気がしてきた。
0287名無しさん＠お腹いっぱい。2005/07/06(水) 11:04:33
>>285
ファイルシステムオーバーライドするのは面白そうなんで、
LUFS使って簡単に実装しようと思ったけど、
/usr をすげかえる気にならないし、対象ディレクトリが増えた時に
fstabの構成変えるのも馬鹿らしいので廃棄処分にしますた。
0288名無しさん＠お腹いっぱい。2005/07/06(水) 15:04:04
数分前に更新した文書っていうけど、自分が更新したとは限らないのが問題。
事実、どっかからダウンロードしてきた文書をすぐに全文検索したくなる
ことは多い。それを考えると、やっぱり手動更新指示の機能もほしいよね？
Hyper Estraierの更新処理は異常に速いから、検索窓の横に「更新」ボタンを
つけておいて、結構気軽に更新をかけさせても実用になると思う。

ラジカセのメタファを使って、「再生（右向きの三角）」で検索をして、
「録音（丸）」で更新をして、「停止（四角）」で検索や更新の停止をして、
負荷状態を音圧っぽく表現するというのも面白いかもね。
0289名無しさん＠お腹いっぱい。2005/07/06(水) 16:25:21
>>288
...目的のファイルが判ってるなら、grepした方が早いような気がする...
でもまぁ、同時ログインしてる別ユーザもいるから、確かに遅延はかなり小さく
しないと厳しい状況がありうるだろうね。

更新ボタンを置くのはいい考えなので、Quick build機能付けるよ。
0290名無しさん＠お腹いっぱい。2005/07/06(水) 19:04:30
>>286
デスクトップ検索アプリを目指すなら、マルチユーザのインデックスの共有はそれほど考え
なくてもいいんじゃね?
自分のホームディレクトリを対象にしたインデックスさえ作れればほとんどのユーザは満足
でしょ。デーモン走らせないと使えないのは初心者向けでないような気がするよ。
副次的な機能として、他人のインデックスをリードオンリーで開けるようにして、チェック
ボックスをオンにすればそこの結果もマージして表示できるといいかも。
つまり他人のインデックスを更新できる必要はないってこと。
manとかの共有物のインデックスはrootで最初に作っておいて、/var 以下においておけば
いいんじゃない? その更新もわざわざデーモンにしないで、cron実行で十分でしょ。
0291名無しさん＠お腹いっぱい。2005/07/06(水) 20:47:50
>>290
基本的にはそうなんだけどさ。
manなら問題ないけど。rootで作ると、本来ユーザに読み込み権限の無いファイルも検索
できて、要約も見えちゃうわけじゃん。
かといって、権限単位にインデックス作るというのも現実的でないし。
業務用の、たとえ共有ディレクトリに入っている技術経歴書とか、仕様書とかを対象と考えた時、
細かい制限ができないと問題だと思ったわけ。

つーわけで、ホームユーザには間違いなく十分だけど、職場で活用となると問題があるわけよ。


試してないけど、
> 副次的な機能として、他人のインデックスをリードオンリーで開けるようにして、チェック
> ボックスをオンにすればそこの結果もマージして表示できるといいかも。
これは現段階でできるような気がする。
今現在、検索用にはDBをリードオンリーで開いてるし、マージもデフォルトだし。
Hyper Estraierはリードオンリーで複数プロセスがオープンしても平気だし。


ってか、みんなのところでちゃんとビルドできてる？、、、って、だれも試してませんか、そうですか。
0292名無しさん＠お腹いっぱい。2005/07/07(木) 00:53:57
見せたくないファイルはインデックスに入れないようにするしかないんじゃないか?
一般ユーザの読み込み権限（S_IROTH）がついているファイルだけ読み込むように
すれば大抵は大丈夫だと思うけど。
0293名無しさん＠お腹いっぱい。2005/07/07(木) 13:16:11
>>286
> Hyper Estraierは、ディレクトリでなくファイルそのものを指定して
>インデックスに登録できるよ。

　・・・できないんですけど？
>第3引数としてファイル名を指定すると、そのファイルから処理対象のパスのリストを読み込みます。
　って書いてあるし・・・
0294名無しさん＠お腹いっぱい。2005/07/07(木) 13:43:20
>> 293
そのリストにファイル名書くんだよ。

find . -name '*.txt' | estcmd gather オプション インデックス -

0295名無しさん＠お腹いっぱい。2005/07/12(火) 00:26:37
howmはこっちをサポートしてくれるといいんだけどね。
Cygwinを使えるし。
0296名無しさん＠お腹いっぱい。2005/07/12(火) 16:15:12
Hyperの方ってCygwinじゃなくてネイティブのWin32じゃなかったっけ?
Cygwinでも動くのかなぁ。
0297名無しさん＠お腹いっぱい。2005/07/16(土) 23:16:11
> Hyper Estraierの最終目的はP2P型の分散処理に支えられた高速で高精度な検索システムを構築することですが、

そうだったのカー (AA略
0298名無しさん＠お腹いっぱい。2005/07/17(日) 03:20:26
ノードAPIキターーーー(ﾟ∀ﾟ)ーーーー！
0299名無しさん＠お腹いっぱい。2005/07/17(日) 20:23:17
namazuの改良したいんですが、キーワード毎に重み付けするような
プログラムってどうすればいいかわかりますか？？
調べてもわかんないです。本でもなんでも教えてほしいです。。。
0300名無しさん＠お腹いっぱい。2005/07/17(日) 21:44:47
>>299 http://pc8.2ch.net/test/read.cgi/unix/1113150661/
03012992005/07/17(日) 21:48:42
>>300
サンクス
■ このスレッドは過去ログ倉庫に格納されています