w3m その7

**名無しさん＠お腹いっぱい。** · 2005/11/15(火) 17:20:00

w3m is a pager with WWW capability.
It IS a pager, but it can be used as a text-mode WWW browser.

http://freshmeat.net/projects/w3m/
http://sourceforge.net/projects/w3m/
http://w3m.sourceforge.net/

その6 http://pc8.2ch.net/test/read.cgi/unix/1106393065/
その5 http://pc5.2ch.net/test/read.cgi/unix/1087225153/
その4 http://pc5.2ch.net/test/read.cgi/unix/1065600900/
その3 http://pc.2ch.net/test/read.cgi/unix/1047038317/
その2 http://pc.2ch.net/test/read.cgi/unix/1035755937/
その1 http://pc.2ch.net/unix/kako/1012/10124/1012484783.html

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 00:15:49

何時も最初は本質からズレた記述なんだよな
何がしたいかが目的であって、
その実装法にそれがベストかどうかは分かんないのに

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 00:18:41

取り敢えずページャとして「何でも」観れるようになればいいな、と。
ただそれだけです。

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 00:26:51

言うまでもありませんがw3mdとはasyncのことです。
デーモン化しておいて複数のリクエストがあれば
それぞれのスレッドを形成して互いに独立のレンダリングを実現します。

この時点で1.0に相応わしいだろうと考えました。

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 00:31:42

flash見れる事が「ページャとして」なのか

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 00:34:53

flashサイト描写 ∈ WWW_capability

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 01:31:35

皮算用スレッドはここですか?

2005/12/26(月) 04:28:40

> 2006/3 w3m 0.6 +xml, +sql
xmlはxml.cgiを作ればいい
履歴はproxyを使えば十分
> 2006/9 w3m 0.7 +js
不要
> 2007/3 w3m 0.8 -BoehmGC
大した問題ではない
> 2007/9 w3m 0.9 +flash
flash.cgiを作れば十分
> 2008/3 w3m 1.0 +w3md
久しぶりにw3md厨が来たか

2005/12/26(月) 04:33:29

悪意のあるスクリプトが実行されないというw3m独特の安心感が消えるのは困る
機能面で不足しているのなら素直にfirefoxを使えばいいだけの話、firefoxは十分軽い
要は棲み分けが重要

それよりも、ページを読み込みながらレンダリングすることを強く希望

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 05:43:54

JavaScript が使いたいんなら、elinks を使えばいいのに。

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 08:05:18

>>158
つうかBoehmGCのメモリ管理に問題があるなんて話がどこから出てきたのか謎。
このスレではしつこく主張する人がいるけれど根拠がよくわからん。

2005/12/26(月) 13:50:40

w3mのプロセスサイズがぶくぶく太るからじゃね？

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 14:29:30

>>168
elinksじゃ日本語読めないじゃん

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 17:30:53

>>171
今から w3m を直すくらいなら、elinks の日本語化した方が早いよ。
GC の削除と JavaScript への対応をしたら、一から書き直すのと変わらんよ？

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 17:55:03

スクリプトは設定で機能を切ることが出来る様になってればいいだけで、
まったく実装する必要が無いということではないと思う。

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 17:57:21

elinksも日本語対応させるにはかなりの部分を
書き直さなくちゃならなかったりするかもよ

2005/12/26(月) 17:58:13

どうしてもjs欲しいんだったらw3m-jsを改良したら？
なぜあれが実用レベルに達しなかったかを考えることだね。

GCの削除は労多くて功少ないのは明らか。

2005/12/26(月) 18:55:21

そこでfirefoxですよ

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 19:15:08

>>174
内部的にはUTF-8だから楽勝かと思って覗いてみたことがあるが、
内部処理がシングルバイトであることに全面的に依存しててどうにもならんかった。
まともにやれば相当の大手術になるのは間違いなさそうで
172の見積は単なる机上の空論。

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 19:25:51

>>フンバリャーウンコ・ヨーデル ◆xlAOIq6jZw
> xmlはxml.cgiを作ればいい
> flash.cgiを作れば十分

早く作れよ、低能君ｗ

**157** · 2005/12/26(月) 19:32:45

>>159
|-BoehmGCは単純にリファクタリングの問題です。
|現在ではGC依存に何の価値もありません。

そもそもGCを使うことの価値って何だと思ってますか?
コードを理解した上での発言ですか?

2005/12/26(月) 20:05:44

>>159
GCなかったらw3mは作れなかったと作者が言ってたぞ。
おまえら、GCに感謝しろ。

>>178
わかんない奴だな。必ずしもw3m本体に組み込む必要ないってことだ。

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 20:10:53

>>179
GC使ったのは単にメモリ管理がメンドかったからだそうです。
そのような丸投げが最適解だとは思えません。

w3m固有のメモリ管理メソッドがあって然るべきだよ。

2005/12/26(月) 20:15:37

自分で実装するよりも既存のライブラリを使うのが悪いのかね？
いちいち車輪を再発明してたらやってられない
そもそも最初はページャとして設計されたんだから長時間立ち上げっぱなしは想定外だろう
さっと立ち上げてさっと閉じるという使い方をすれば多少肥えても問題ない

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 21:03:23

メンドい管理を丸投げできることを上回る「最適解」ってのがよくわからない。
他にメリットがないのなら、コーディングの一番楽な方法が「最適解」でしょう。

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 21:22:00

GCとは別に、大きなTABLEを扱った時なんかのメモリ効率が改善されればそれはそれで幸せ。
でもたぶんタブ保存機能を入れた方が早いか。

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 21:57:16

>>181
「w3m固有のメモリ管理メソッド」を用意する事に、
プログラマの自己満足以上の意味が何かあるのか？
メモリが太るのはバッファをキャッシュファイルで持たないとか
w3m自体のアルゴリズムとかのせいであって、
ガベージコレクションとは関係ないだろ。

2005/12/26(月) 22:24:43

メモリまわりのバグは厄介だぞ
その厄介事を肩代りしてくれてるGCに感謝しろ

**嫌われ者のVipper** · 2005/12/26(月) 22:28:09

両派の言い分は良くわかるんですよ

**嫌われ者のVipper** · 2005/12/26(月) 22:28:53

GCがああだこうだって話し　私も

**嫌われ者のVipper** · 2005/12/26(月) 22:29:32

FreeBSD/Alphaで苦労したんですよね

**嫌われ者のVipper** · 2005/12/26(月) 22:30:15

何もできないから指を加えて上手く動くのを

**嫌われ者のVipper** · 2005/12/26(月) 22:31:10

待ってましたよ　でも黙ってましたよ

**嫌われ者のVipper** · 2005/12/26(月) 22:32:38

私には何もできないから　ですよ

**嫌われ者のVipper** · 2005/12/26(月) 22:34:10

論破よりもソースだと思うのですよ

**嫌われ者のVipper** · 2005/12/26(月) 22:35:18

もう見てらんない　つまんない小競り合いは

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 22:38:13

ほんのちょっとしたファイルでやたらメモリ喰って
Xを落としてしまった事がある。

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 22:41:06

どんなちょっとしたファイルだよ・・・

2005/12/26(月) 22:45:04

<DIV><TABLE><TEXTAREA></DIV>
前に話題にでたけどこういうのだろ。

2005/12/26(月) 22:49:54

どんな大男も弱点を突かれればあっさりとぐったりするみたいに、
w3mにも落とすための急所が存在する
もっとも197の欠陥は修正されたが

**名無しさん＠お腹いっぱい。** · 2005/12/26(月) 23:11:54

>>181はきっと、普段プログラム組む時ライブラリを一切使わない人なんだろうな
そのうちlibcは排除の方向でとか言い出すよ

**名無しさん＠お腹いっぱい。** · 2005/12/27(火) 00:20:07

>>199
ちょｗｗｗどこの大岡山ｗｗｗｗｗ

2005/12/27(火) 00:25:58

ちょっと勘違い君がいるようなので表明しておく。
わしは名無しで自演などはしない。きちんと名前を書く。
人は見かけで判断できないように名前で荒らしと決め付けるのは早計だ。
それともうひとつ、火のないところに煙は立たない。
わしがフンバリャーウンコ・ヨーデルである！

**名無しさん＠お腹いっぱい。** · 2005/12/27(火) 04:10:14

ヨーデルさんってるび○ち？

**名無しさん＠お腹いっぱい。** · 2005/12/27(火) 04:13:45

せっかく全員でスルーしてるのに空気の読めない奴だ

**名無しさん＠お腹いっぱい。** · 2005/12/27(火) 16:48:48

>>176
firefox使える時は使うけどね。
Xプロトコルを中継できない環境ってのもある訳で。

2005/12/27(火) 17:37:26

>>202 違う。
>>204 つまり非X環境か。ならば他のテキストブラウザを。それでもだめなら諦めろ。

**179** · 2005/12/28(水) 00:36:18

>>181
|GC使ったのは単にメモリ管理がメンドかったからだそうです。
|そのような丸投げが最適解だとは思えません。

つまり根拠があるわけではないのね。ではそれを前提に話をするけど
GCを使うメリットは、Cでバッファ管理をする時の手間を減らすという
以外にもあるんだ。たとえばC++を使って文字列処理のバッファ解放を
自動化すればいいじゃん、という考えかたも可能だけど、GCを使うと
この手の処理にありがちな、小さいバッファを確保→解放→……を
繰り返すというオーバーヘッドを簡略化できる可能性があるんだ。
変数の生存期間だけを見て機械的に確保/解放をするだけだと達成できない
ことだよね。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 01:53:15

>>206
小さいバッファを確保->開放を繰り返すオーバーヘッドより
メモリ使用量肥大の方が問題なんだけど。
確保をフリーリストから取得、開放をフリーリストに追加
に変えるのがそんなに難しいことですか?

>たとえばC++を使って文字列処理のバッファ解放を
>自動化すればいいじゃん、という考えかたも可能だけど、
この時点でGCを分かってないと思われ。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 02:06:06

問題なのは「どの時点で開放すべきか」なんだよね。
キャッシュに落さないのでこの部分の実装に失敗すれば致命的。
勿論GC非依存は前提で。
w3mの性能に関わる部分をGC丸投げで済ますなんて論外もいいところだ。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 02:07:10

207がいとも簡単に脱BoehmGCパッチを書いてくださるそうです、拍手！

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 02:13:03

パッチだけじゃ無理だろ。
フルスクラッチ所望。

# どうせ開発停滞していることなんだし

2005/12/28(水) 03:13:54

性能がイマイチなのは読み込みながらレンダリングしないからだと思われる
GCがどーたらこーたらよりも先にそれから始めよ

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 08:48:26

>>208
大抵のOSでは、一度確保したメモリは他のプロセスから要求があるまで
そのプロセスに割り当てられたままになるようになってると思うんだけど。
ガベージコレクションと関係なく、OSで決まってる部分。

**206** · 2005/12/28(水) 08:53:00

>>207
|小さいバッファを確保->開放を繰り返すオーバーヘッドより
|メモリ使用量肥大の方が問題なんだけど。
メモリ使用量が増え続けるのは脱GC化しても解決しないよ(過去スレ参照)。

フリーリストに関していうと、malloc/free自身がそういうしくみに
なっているので、特にそういう処理は必要ないかな(確保/確保の傾向を
知るには都合いいかもしれないけど)。

|>たとえばC++を使って文字列処理のバッファ解放を
|>自動化すればいいじゃん、という考えかたも可能だけど、
|この時点でGCを分かってないと思われ。

ここの部分は、GCを使わないように書換える場合に、現状存在しない
解放処理をどうするかということの一例を出しただけだよ。そんなに
必死に「分かってない」とかいって噛みつかなくても :)

**213** · 2005/12/28(水) 08:54:36

>>211 asyncパッチって、そのあたりの面倒は見てくれないんだっけ。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 09:18:22

>>208
>問題なのは「どの時点で開放すべきか」なんだよね。
>キャッシュに落さないのでこの部分の実装に失敗すれば致命的。

意味がわからないなあ。逆じゃないの？キャッシュファイルに落とさないから、
ユーザーがバッファを閉じない限りメモリ使用量は増え続けるだけ。
w3m側で使用中なわけだから、GC側では解放のしようがない。
本気でメモリ使用量を抑える改造をしたいんだったら、GCなんかいじるより
キャッシュファイルを使うようにする方向で考えた方がいいと思うぞ。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 10:01:08

またこの流れか。一スレに一度は儀式のように繰り返すな。
もうFAQとしてテンプレに書いとけよ。

[Q]w3mメモリ食いすぎ。BoehmGCが悪いのでは？
[A]ページバッファの開きすぎのせいなのでGCを変えても解決できません。
CLOSE_TABとBACKとDELETE_PREVBUFを使ってこまめにバッファを消しましょう。
ただし多くの環境ではバッファを消した瞬間に目に見えて使用メモリが
減るわけではありません。C-FAQ 7.24参照。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 10:16:20

[Q]C-FAQ 7.24はどこにあるの？

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 12:13:33

[A]おそらくここではないだろうか
http://www.kouno.jp/home/c_faq/c7.html

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 12:23:34

それだとすると、なんか微妙にズレてない?

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 12:48:22

7.25だな

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 13:12:37

バッファ管理の問題なんだから、BoehmGCをやめたって別に変わらないんだよな。
ちょっと前のスレに自動で古いバッファを消していくパッチがあったけど、
不満な人はとりあえずあれ使えばいいんじゃないの？

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 13:38:29

バッファ消すのはヤダな。
キャッシュに逃がしてくれ。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 13:42:24

メモリ使用量が気になるって言ってる人は、たぶんBACKの代わりに
PREV使ってる人なんじゃないかな。
他のブラウザだと戻って新しいリンクを踏んだら前に見たページは
破棄されるけど、w3mの場合割り込み式で新しいバッファが加わるから
何もせずにいると無限に使用メモリが増えていく。
その分便利なんで俺は気に入ってるけど、嫌なら>>221みたいな改造が
手っ取り早くて実効的だと思う。

って、過去スレで何度か既出の話なんだけどログ読めないのが辛いな。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 13:47:54

> 他のブラウザだと戻って新しいリンクを踏んだら前に見たページは
> 破棄されるけど
これはメモリ的に?
それともそのブラウザが扱えるなんらかのリソースという意味で?

2005/12/28(水) 13:53:31

だからさ、戻るをBACKにしてキャッシュサーバ立てろよ

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 13:56:23

>>224
まあ想像なんだけど、キャッシュファイルだけ残しておいて
メモリへの割り当てはその時点で解放してるだろうなと。
進む/戻るボタンですぐ見られるページの分だけ掴んでおけば十分だから。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 14:04:25

>>223 つ ttp://makimo.to/2ch/search.html

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 14:09:55

るびきてぃウゼー

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 14:11:19

>227
その3とその5が見れないんだよな。バッファ自動消去パッチもその中っぽい。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 14:27:02

>>213
>メモリ使用量が増え続けるのは脱GC化しても解決しないよ(過去スレ参照)。
確かにそうだね(脱GCじゃなくて脱BoehmGCね)。
いらない領域を指すポインタがいつまでもスタック、静的領域にあることが問題だ。すまん

>フリーリストに関していうと、malloc/free自身がそういうしくみに
>なっているので、特にそういう処理は必要ないかな(確保/確保の傾向を
>知るには都合いいかもしれないけど)。
じゃああんたが 206で言ってることはなんなんだ。

C++ってデストラクタのこと言ってるんだったら GCの代わりになるわけないし
スマートポインタのことを言ってるんだったら C++はあんまり関係ない。

個人的にメモリ肥大より NetBSDで勝手に落ちることの方が問題なので
BoehmGCが憎くなっていた様だ。暇になったら独自GC使うように改造してみるよ。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 15:34:25

>229
自己レスだが、ttp://www.bookshelf.jp/2ch/unix/ で読めるみたいだ

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 18:08:19

タブ保存機能を採用してほしいな。あれがあれば開きっぱにする必要はかなり減る。
パッチはもうあったよね？

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 18:28:24

現在開いてる全てのurlを任意のファイルに書き出せれば俺的には万々歳。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 18:40:13

後はどうにでもできるよね

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 19:21:46

あ、「現在開いているURLを一括してブックマークに加える」
という形にするといいかもしれない。カテゴリ名も指定できればなお良し。
これだと既存の機能と整合性も取りやすいのでは。

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 19:25:38

そのためには「現在開いている全てのURL」を保存する環境変数が必要だな

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 20:36:19

ん、なぜに環境変数?

**213** · 2005/12/28(水) 21:28:43

>>230
|C++ってデストラクタのこと言ってるんだったら GCの代わりになるわけないし
|スマートポインタのことを言ってるんだったら C++はあんまり関係ない。
いや、俺は君が(boehmGCに限らず)GC全否定なんだと思っていたので、
じゃあその替わりをどう実装するんだろうと思いついたことを書いてみただけ。
(って書かなかったっけ?)

|個人的にメモリ肥大より NetBSDで勝手に落ちることの方が問題なので
|BoehmGCが憎くなっていた様だ。暇になったら独自GC使うように改造してみるよ。
いっそboehmGC on NetBSDを直してくれたら……

**236** · 2005/12/28(水) 21:34:16

bookmarkはLocal CGIで実装されてるから
べつに環境変数じゃなくても ~/.w3m 以下のファイルでも桶
ファイルに保存する場合はPIDで別々に保存しないと他のw3mに上書きされる

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 21:40:48

URLのリストを出力するパッチ
http://homepage3.nifty.com/clavelito/screen_w3m/

**名無しさん＠お腹いっぱい。** · 2005/12/28(水) 22:08:49

local-cgiに移譲する気だったらfxのextensionのようにpkg化してみろよ糞コテ

**名無しさん＠お腹いっぱい。** · 2005/12/29(木) 00:50:59

パッチで解決しろと言っても、散ったパッチを本家に一本化することが必要になる予感。
FreeWnnやらLaTeXやらのように。
(local_cgiはどうか知らん)

**名無しさん＠お腹いっぱい。** · 2005/12/29(木) 01:13:17

NetPBMならぬNetW3M？

2005/12/31(土) 18:39:41

>>241
flashはLocal CGIがいいという話をしているのにどこからpkg化の話がでてくるんだよ

【だん吉】【1093円】 · 2006/01/01(日) 08:07:10

>>240
リストを上書きする時にバックアップを残す方がいいな。
あと出力順は逆の方がいいな。そのまま開くとタブが逆順になっちまう。

2006/01/01(日) 18:27:58

あけましておめでとうございます
w3mに幸あれ

**clavelito@Vim%Chalice** · 2006/01/02(月) 15:53:42

>>245
>>240 さんに紹介して頂いた patch を作ったものです。

バックアップと、出力順、仕様変更したものを作りました。
また、任意のファイルへの出力を出来るようにしました。

試してみて下さい。(ペコリ)
ttp://homepage3.nifty.com/clavelito/screen_w3m/

**名無しさん＠お腹いっぱい。** · 2006/01/02(月) 19:27:25

タブクローズのアンドゥを手を抜いて1回だけできるようにしているけど、
これだけでも結構便利だ。まあ時折もっと戻りたいときがあるが。
バッファリストの構造のまま戻るので、これが役に立つこともある。

w3mを終了させる場合は、現在開いているURLを復活させるだけで
大抵事足りるかな。完全なセッション保存は重そうだ。

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 23:04:29

タブ機能言ってる人はscreenじゃダメですか

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 23:05:32

>>249
全然ダメ

2006/01/05(木) 00:05:07

わしはscreenとタブを併用してますが何か？

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 00:30:46

別に？

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 21:20:26

どっちもどっちなんだよね。
screenで代用しようとすると、各種ヒストリ・cookieの共有ができない
w3m単体だと各タブが読み込み中の時に別のタブは操作できない
(async-patchってそのあたりはちゃんと動くんだっけ)

2006/01/05(木) 22:23:08

URLヒストリならプロキシでどうにかなるけど、cookieは無理ぽ
検索文字列のヒストリの共有は不可能ではないが要改造
asyncは不安定

**名無しさん＠お腹いっぱい。** · 2006/01/06(金) 01:36:33

そこでemacs-w3mですよ

2006/01/06(金) 01:54:00

レンダリングが遅すぎて話にならない
firefoxのほうがずっとまし

**名無しさん＠お腹いっぱい。** · 2006/01/06(金) 02:32:34

低速コンピュータでfirefoxは事実上仕様不可能だからなあ
いまどき起動で5分とか

2006/01/06(金) 03:45:48

まさか486DX2とか!？

**名無しさん＠お腹いっぱい。** · 2006/01/06(金) 06:47:45

>>257
リソースは無限じゃないんだから機能を増やせば低速コンピュータで
動かなくなるのは当たり前。ショボい機能で満足するべし。