[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 05/09 13:56 / Filesize : 174 KB / Number-of Response : 756
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

「コンパイラ・スクリプトエンジン」相談室14



1 名前:デフォルトの名無しさん mailto:sage [2009/11/17(火) 13:12:25 ]
禁止事項【臨時】
・前スレの911自身の書き込み、またそれに関連した書き込みを禁止致します。
 (スレが荒れる原因となります)

プログラミング言語処理系の開発に興味のある人達のスレッドです。
字句解析・構文解析から,データフロー解析,ループ並列化,データ分散,SSA変換,
CPS変換,レジスタ割付,命令スケジューリング,ソフトウェアパイプライン,
SIMD命令生成,VLIW向けクラスタリング,スクラッチメモリ向け最適化,リンク時最適化,
JIT,動的バイナリ変換等の各種最適化,それにVM,GC,低消費電力化などなど。
意味論に関する話題も歓迎です。

過去スレ
1 pc.2ch.net/tech/kako/981/981672957.html
2 pc2.2ch.net/test/read.cgi/tech/1021136715/
3 pc5.2ch.net/test/read.cgi/tech/1070089173/
4 pc5.2ch.net/test/read.cgi/tech/1100097050/
5 pc8.2ch.net/test/read.cgi/tech/1106129164/
6 pc8.2ch.net/test/read.cgi/tech/1115335709/
7 pc8.2ch.net/test/read.cgi/tech/1129287390/
8 pc8.2ch.net/test/read.cgi/tech/1131273918/
9 pc8.2ch.net/test/read.cgi/tech/1135082582/
10 pc8.2ch.net/test/read.cgi/tech/1146844753/
11 pc11.2ch.net/test/read.cgi/tech/1160879890/
12 pc11.2ch.net/test/read.cgi/tech/1188688416/
前スレ 13 pc12.2ch.net/test/read.cgi/tech/1233143342/
関連リンクは多分 >>2-10 あたり

321 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 10:22:57 ]
古い論文だとFortranをfunctional languageと呼ぶことがあるんだけど懼ヲ
まあ、聞いたことないのが当たり前だと思う。
自分も最初に聞いたとき訳が分からなかったし。

あと、その訳語として「関数型言語」が主流だったどうかは知らない。
ごめん。

322 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 10:32:12 ]
>>321
具体的にその論文名を。

323 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 10:52:26 ]
threaded interpretive language とか書名聞いて
何ぞと思って調べてみたら forth と z80 の解説書だった

俺もどこで見たか忘れたけど、Cを関数言語と呼んでた
記憶が・・・まぁ文脈というか時代背景によるよね > 用語の定義

324 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 10:58:59 ]
技評の「新ANSI C言語辞典」を持ってる人がいたら、それの
「関数型言語」の項を見てもらいたいのだが...

325 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 11:08:31 ]
>>322
論文は手元にないんで無理。
Webならwww.liv.ac.uk/HPC/HTMLF90Course/HTMLF90CourseNotesnode52.htmlが近いかな。

むしろちょっと疑問なんだけど、
"functional language"に同綴り異義語があった
というのってそんなに興味深いのか。

326 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 11:19:10 ]
>>324
通りすがりの漏れが引用しますよ
p.294 関数型言語 の項より

「関数型言語(functional language) 関数型のプログラミング言語。
LISP、LOGO、APL、BCPL、B、Cなどがある」

327 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 11:22:51 ]
そのころの基準で関数型じゃない言語って何だ?
FORTRAN、COBOLは違うのか?
BASIC? 関数を言語仕様に入れただけで、分類が型が変わるのか?
アセンブラ?

328 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 11:58:43 ]
どうでもいいからブログでやってろ

329 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 12:27:44 ]
>>326
たぶんそれが日本でデマが流行ってる元凶。
時代によって変わったりなどしない。B も C も関数型じゃない。

>>325 も HPC の専門家らしいので、言語屋じゃない。
言語屋が C を functional などと言った例はないはず。



330 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 12:52:56 ]
素直にこの辺りを参照した方が良いと思う。
ttp://ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0_%28%E6%95%B0%E5%AD%A6%29

俺解釈だと「処理が関数の変数と値に依存する言語」「独立して書かれている処理は独立している」だな。

331 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 13:02:29 ]
「Cを関数型と呼ぶ人が一部にいたのかどうか」
「その事実は万人が知っていてしかるべきか」という話になってしまっているが
なんにせよCもFortranも関数型言語ではないし
LISPにしても、延々とこんな話を続ける理由になるほど手続き型言語っぽくはない

332 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 13:03:14 ]
>>330
バカ

333 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 15:53:39 ]
LISPとCに根本的な違いが無いのに
「LISPは関数言語」というデマがいつからか
流行ったのが酷いと思うけど。

334 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 16:11:15 ]
> 根本的な違い
根本的というのが曖昧すぎて、何とも言えないな。つまりどういう要素が根本的なのか。

335 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 16:24:30 ]
LISPとCでどこが違うのか言ってみてよ。

336 名前:227 mailto:sage [2010/01/30(土) 17:59:10 ]
Haskellも副作用(モナド)あるから関数型じゃないよね、とか燃料投下してみる。

337 名前:デフォルトの名無しさん mailto:sage [2010/01/30(土) 18:22:26 ]
OCamlはもっと微妙。

338 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 08:20:21 ]
関数型言語と呼べるための必要条件は何だろう?
素朴には、すべてのプログラムが数学的な関数だけで構成されていること、だが、
これだとほとんどの言語が失格だな。

339 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 08:29:30 ]
>>338 それは十分条件じゃないか?
下手するとHaskellぐらいしか満たせないw



340 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 10:14:20 ]
トランスレータって何時頃からあるんだろう
A言語をC言語に変換する

コンパイラ・スクリプトエンジンというよりは
テキスト処理の範疇なような気がするけれども

でも欠点があるから、技法として主流足りえない

あれか出力先の言語・ビルド環境による影響大
適用できる範囲が、自然と絞られざるを得ないとか

toy program というような捕らえ方が一般に正しい
反応なような気もする…

341 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 10:19:47 ]
toy rograam じゃなくて toy language だった
なれない言葉使おうとするじぶんかっこ悪いorz

342 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 10:27:21 ]
有名なものでは "Software Tools" (「ソフトウェア作法」) の Ratfor が 1974 年。

初期の C++ は、C 言語へのトランスレータだった。テキスト処理で済むような
内容ではなかったけどね。

343 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 11:39:44 ]
Cにうまく変換すれば、可搬性でも速度でも申し分ないはず
でもCの再解釈分だけオーバーヘッドがある
D&Eを読むと、初期のC++処理系(Cfront)がトランスレータだったいせいで
生成コードの品質が悪いとか、本格的な言語ではないとか誤解されたと書いてあるが

>toy language というような捕らえ方が一般に正しい
真実どうなのかはともかく、多数の認識は今でもそうなのかも?

344 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 11:45:36 ]
OOSC初版の頃のEiffelもCへのトランスレータだったはず
今でもそうなのかは知らないが

345 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 11:48:35 ]
コンパイラ入門―構文解析の原理とlex/yacc、C言語による実装

糞本だった。お前ら責任取れよ


346 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 11:55:57 ]
>>345
どの辺が糞なのか書いてないから責任とってあげない

347 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 13:25:00 ]
馬鹿には有効活用できない本を馬鹿に薦めた責任とかそういうこと?

348 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 13:41:31 ]
良書だった記憶があるけどなあ
薄い割に説明はかなり噛み砕いてあるし、
かといって理論的な部分を無視してるわけでもない

もっとも、内容としては構文解析・yacc/lexの最低限の使い方で終わってるから
詳細は別途ドラゴンブックとかを頼らないといけない
その辺も含めて、巻末に関連書籍の紹介が載ってたはず

349 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 17:47:18 ]
でもこの本高校生か大学1年程度の
レベルの本だから意味なくね?



350 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 18:42:04 ]
>>349
この本はそのレベルの人には非常に良い本だし、その良き本を糞本扱いできる程高度な知識を持つものなら手にとって数ページ眺めるだけで自分に必要ないことを理解するハズだよね?
それがわからないという事、つまり>>345の中の人は……(以下自粛


351 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 19:00:19 ]
よっぽどデカい本屋じゃないと、置いてなくない?

352 名前:デフォルトの名無しさん mailto:sage [2010/01/31(日) 22:09:25 ]
関数型言語をラムダ算法を元に解説するのはもう古いの?
真っ先に出てくると思ったのに。

353 名前:デフォルトの名無しさん mailto:sage [2010/02/01(月) 03:45:35 ]
理論背景って研究者にしか意味無いからな…

354 名前:デフォルトの名無しさん mailto:sage [2010/02/01(月) 13:01:04 ]
でもそういう基礎理論があれば関数型は動作を類推できるじゃないか
コンパイラの設計法にも関わる事だと思うけどな
そういうのを知らないとRubyみたいに仕様が破綻することになる

355 名前:デフォルトの名無しさん mailto:sage [2010/02/01(月) 13:06:45 ]
>>352
破壊的リスト操作をラムダ算法で解説できるんですかあなたは?

356 名前:デフォルトの名無しさん mailto:sage [2010/02/02(火) 11:59:29 ]
>>352
C#はラムダ式があるから関数型言語だ、ということにしたくないんだろうな。
無名関数はPerlにもある。
もう「値を返すサブルーチン」と同じくらい当たり前になってしまった。

357 名前:デフォルトの名無しさん mailto:sage [2010/02/02(火) 12:17:13 ]
ラムダがありゃ関数型言語、という新説が登場しますた

358 名前:デフォルトの名無しさん mailto:sage [2010/02/02(火) 13:26:55 ]
文法のlambdaとラムダ計算は別物だよね

359 名前:デフォルトの名無しさん mailto:sage [2010/02/02(火) 13:42:28 ]
>>358
それはlambdaのない言語が言い訳するときのセリフ



360 名前:デフォルトの名無しさん mailto:sage [2010/02/02(火) 17:10:19 ]
大事なのはクロージャ

361 名前:デフォルトの名無しさん mailto:sage [2010/02/02(火) 22:19:21 ]
Objective-Cの勝利。

362 名前:デフォルトの名無しさん mailto:sage [2010/02/02(火) 23:29:26 ]
>>352
ほとんどの言語はチューリング完全
チューリング完全ということはチューリングマシンと同じ計算能力を持つ
チューリングマシンとラムダ計算は等価
よってほとんどの言語は関数型である
なんてことになって不都合とか

363 名前:デフォルトの名無しさん mailto:sage [2010/02/02(火) 23:31:47 ]
SQLいいよSQL

364 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 00:14:36 ]
上向き構文解析って遅いし
意味の無い概念じゃないですか

還元とか意味が全くないし

365 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 08:34:34 ]
オマエが意味を理解できなくても、LALR(1) パーサは現実に働いているわけだが

366 名前:デフォルトの名無しさん mailto:sage [2010/02/03(水) 17:06:29 ]
>>364
上向き構文解析って下向きより遅いの?

367 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 06:44:51 ]
俺のは左向き

368 名前:デフォルトの名無しさん mailto:sage [2010/02/04(木) 06:56:20 ]
誰もお前のつむじの向きなんか聞いてない

369 名前:デフォルトの名無しさん mailto:sage [2010/02/05(金) 22:54:42 ]
つむじの向きとか何馬鹿言ってんの?ちんこの向きだろ。




370 名前:デフォルトの名無しさん mailto:sage [2010/02/07(日) 15:21:49 ]
野暮がすべてを台無しにする

371 名前:デフォルトの名無しさん [2010/02/09(火) 00:39:14 ]
遅い

372 名前:デフォルトの名無しさん [2010/02/10(水) 16:53:19 ]
ゴスロリ言語

373 名前:デフォルトの名無しさん mailto:sage [2010/02/11(木) 19:45:00 ]
おい、Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages (Pragmatic Programmers)
これ良書かおしえろ

374 名前:デフォルトの名無しさん mailto:sage [2010/02/11(木) 20:43:05 ]
やだ

375 名前:デフォルトの名無しさん mailto:sage [2010/02/13(土) 09:02:14 ]
>>373
良書です

376 名前:デフォルトの名無しさん mailto:sage [2010/02/13(土) 09:24:04 ]
>>375
嘘つくんじゃねーよ
ANTLR使い方書いてあるだけの
糞本じゃねーかよ

377 名前:デフォルトの名無しさん mailto:sage [2010/02/14(日) 09:29:24 ]
上付きとか下付きとか、マンコの形なんかどうだっていい

378 名前:デフォルトの名無しさん mailto:sage [2010/02/14(日) 09:36:02 ]
リンクの冒険の話はスレ違いだ

379 名前:デフォルトの名無しさん mailto:sage [2010/02/15(月) 18:41:31 ]
>>343
> でもCの再解釈分だけオーバーヘッドがある

そんな一般論は言えない。



380 名前:デフォルトの名無しさん mailto:sage [2010/02/16(火) 13:36:59 ]
>>376
たまたまCanalが悪かっただけさ。
つかANTLRで生成されたコード読めばいいだけじゃないか。
それにコードはdmozなりsf.netなり探せばあるだろ。まったく。

Nils M Holm氏による著書
ttp://www.bcl.hamilton.ie/~nmh/t3x.org/zzz/

Parsing Techniquesで知られるDick Grune氏のサイト
ttp://www.cs.vu.nl/~dick/
ダウンロード先 : ftp://ftp.cs.vu.nl/pub/dick/

これでもbomb!と抜かすなら自分の力量が足りないか考えることだな。

381 名前:デフォルトの名無しさん [2010/02/22(月) 17:10:32 ]
Aanal ねぇ

382 名前:デフォルトの名無しさん mailto:sage [2010/02/26(金) 15:25:43 ]
しつもん
Pythonみたいなインデント指向の言語を字句解析・構文解析するアプローチを教えてください

383 名前:デフォルトの名無しさん mailto:sage [2010/02/26(金) 15:36:09 ]
>>382
lexierでインデントを見て、begin、end的なダミーのスコープ限定子を出力すればいいんじゃね

384 名前:デフォルトの名無しさん mailto:sage [2010/02/26(金) 15:52:22 ]
>>382
どの言語だか忘れたが、
一旦、インデント数をひとつのパラメータ付き構文要素として、構文木に埋め込み、
これをもう一度構文解析して、構文木を再構成する実装を見たことがある。

実際はステートとして、現在のインデント数を持っておき、
>>383のように、ソースには現れない隠れ構文要素を構文木に構成しながら、
解析するのが簡単だと思う。


385 名前:デフォルトの名無しさん mailto:sage [2010/02/26(金) 21:41:22 ]
CPythonの実装は>>383みたいな感じのようだね。INDENT, DEDENTっていうトークンが用意されてる。

386 名前:デフォルトの名無しさん mailto:sage [2010/02/26(金) 23:34:26 ]
indentの逆はででーんとdedentなのか
明日会社で自慢しよう

387 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 00:08:22 ]
インデントでブロック構造なんて信じられない。バグは大丈夫なのか?

388 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 00:11:28 ]
あと、いくらCPUパワーが上がっても、コンパイルスピードと実行スピードが言語仕様のせいで全く上がらない。
Cにキャリー機能を追加してライブラリと最適化を強化する方が良いのでは?

389 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 02:00:25 ]
>>387
だれでも最初はそう思うんだよね

でも実際やってみるとほとんど問題ないってわかる



390 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 02:05:56 ]
>>387
ちょっと長めのコードをコピペすると…

391 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 02:07:51 ]
コピペ防止効果もあるのか、いいじゃないか

392 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 02:16:34 ]
コードの移動に支障が出るんだから良い訳無いだろw

393 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 02:28:29 ]
インデントブロック構造はネストしたブロックから抜ける構造の表現に難があるよな。
ネストが深くなるだけの構造だとキレイだけど。

394 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 04:21:33 ]
例外処理を作るときに、いちいちインデントを気にし、
少しでも気楽にコピペで作るときにインデントを気にし、
良いこと少ないね

395 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 04:53:40 ]
>>389
pretty printできないから嫌い


396 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 05:25:30 ]
>>390-392
pythonはモジュール化が簡単だからそこは問題にならない

>>393
try: except: else: finaly: で問題なし

>>394
お前の能力が低いことはわかった


397 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 07:09:58 ]
人間の目には錯覚がある。例外処理もいっぱいある。
さあ、何から議論しようか。坊や。
人間工学か?
それとも実行スピードを無視した方法か?

398 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 07:16:58 ]
おれは388だ。Cにキャリーをいれるのが最適のアセンブラに成ると思っている。

399 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 07:18:06 ]
インデントでブロック構造なんて、tab2かw



400 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 07:22:30 ]
時々このスレがわからなくなる

401 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 07:27:11 ]
言語を作ることがスレの本分だったな。
ちんこの前のエロゲの言語が本分だったな。

402 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 07:28:56 ]
しかし、9??の言うとおりのコンパイラが発売されたときは、
このスレ、もしかして馬鹿の集まりじゃないかっておもったよw

403 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 08:46:14 ]
しかしコンパイラスレのエロゲコンパイラが発想も実装も凄いよな。本当なら。

404 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 08:57:06 ]
>>398
アーキテクチャによっては無いんじゃなかったっけ?
移植性を落とさないのだろうか

405 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 13:02:17 ]
>>396
コードの字面上の話だから、モジュールは関係無いよ。
コードを書いていて、一つのブロックの行数が多く、ネストも深くなってしまった時に、
処理を別の関数に外出ししようとすれば必ずコピペは発生する物だし、そういう時に
インデントの修正は避けられない。

技術の良い面だけじゃなく、悪い面も認められないとね。

406 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 13:41:54 ]
>396
try: except: else: finaly: で回避できるの?
ネストしたブロックから抜けるときは依然としてインデントを合わせなきゃいけない気がするけど?


407 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:04:33 ]
プログラミング言語の文法には認知科学的な視点も必要さ。
そういう意味ではHaskellとかPerlは基地外。

408 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:06:31 ]
PerlはまだかしくもHaskellは問題ない

409 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:08:30 ]
まあ何でGoogleがPythonマンセーなのか考えればいい



410 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:11:15 ]
pythonはもうちょっとライブラリを整理して欲しい。
せめてリスト操作に副作用ありとなしの関数を両方用意して欲しいな。

411 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:17:14 ]
副作用あり:list.sort 副作用なし: sorted
副作用あり:list.reverse 副作用なし: reversed
これでは駄目なのか?

412 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:17:44 ]
>>409
全然マンセーじゃないみたいだが…

groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e

413 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:26:38 ]
simple common sense is going to limit Python's applicability
when operating at Google's scale

414 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:44:34 ]
>>412
読んだけど、元々速度が要求される場面ではPythonは用いてないと思うし、そもそもそれは憶測の域を出ないよね。

415 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:51:12 ]
つ コリンは中の人

416 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 16:54:05 ]
その Google Groups も Python でなかったか?

417 名前:デフォルトの名無しさん mailto:sage [2010/02/27(土) 22:20:22 ]
>>398
>Cにキャリーをいれるのが最適のアセンブラに成ると思っている。

64bit版TL/1まだ〜?


418 名前:デフォルトの名無しさん mailto:sage [2010/02/28(日) 00:29:23 ]
> Cにキャリーをいれるのが最適のアセンブラに成る

Cには関数GOTOがないんでいまいち

419 名前:デフォルトの名無しさん [2010/02/28(日) 09:00:27 ]
Multi-entry も無いな



420 名前:デフォルトの名無しさん mailto:sage [2010/02/28(日) 09:05:50 ]
>>418
関数GOTOってなんだ? setjump, longjump?

421 名前:デフォルトの名無しさん mailto:sage [2010/02/28(日) 09:08:03 ]
ああ、CALLとかBSRとかGOSUBのことか。いらんな。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<174KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef